> The page is being rendered fine but the problem is: the javascript file
> is not found.
Have you tried accessing it directly, i.e. replace "home.html" with
"abc.js" (or the real equivalents)? Are you running from a
case-sensitive system and use the wrong case?
> Is there any specific way to refer to static data within portlet
> context?
That's the clue right there: The browser (which loads the JS when it's
encountered in the page) will use the URL context - which, for a
portlet container will be something entirely different than the
directory structure the portlet finds home.html in.
priyom - 01 Nov 2006 07:06 GMT
Hi,
Thanks for your prompt reply.
The js file, if accessible directly if it is fetched with
PortletRequestDispatcher.
But since it lacks markup fragments, the entire file contents are
displayed as is-which doesn't serve any purpose... but yes...the system
is able to find the js file.
Regarding your second point, could you please specify the way in which
static content is to be accessed in portlet context?
For that matter, even images are not being displayed via the snippet :
<img src="a.jpg"></img>
as probably the Portlet is not able to find it.
Awaiting your response.
Priyom
Tor Iver Wilhelmsen - 01 Nov 2006 19:28 GMT
> Regarding your second point, could you please specify the way in which
> static content is to be accessed in portlet context?
> For that matter, even images are not being displayed via the snippet :
> <img src="a.jpg"></img>
> as probably the Portlet is not able to find it.
That's because it's not the portlet that's trying.
Basically you need to realize that the browser is doing two trips to
the server: One to produce the portlet-containing page, then a second
to get at referenced content - <img src...>, <script src...> and
<iframe...> elements mainly. This second request, if using relative
paths, will use the page location (i.e. the portlet renderer URL), and
for any normal portal that would be a Front Controller pattern servlet
like "/Portalname/CCS" or something. So the path attempted for the
relative path "abc.js" would be "Portalname/abc.js".
Therefore, static content delivered in such secondary requests - like
images and JS files - should be put in the portal web application's
WAR file at a place where it's directly available, like the root or a
folder suitably named to categorize it. Or you could have a servlet
deliver the content from the portal location somehow.
In the worst case, you can inline the JS either using <jsp:include> or
<%@include %> syntax. Inlining images is harder since not all browsers
support it.