myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <>
Subject Re: JSR 168 Portlet and ExtensionsFilter
Date Wed, 19 Oct 2005 13:43:28 GMT
Dave Brondsema wrote:
> Ryan Wynn wrote:
>> I am trying to get the inputCalendar to work inside a Portlet.  It seems
>> to me that although I have the myfaces ExtensionsFilter mapped in my
>> web.xml the appropriate javascript is not being included in the response.
>> I get DateFormatSymbols is undefined which looks like it is declared in
>> date.js.
>> I subclassed ExtensionsFilter and it looks like the doFilter method is
>> not being called at all for the page that contains the inputCalendar,
>> even though I have the filter mapped to /*
>> Has anyone had success with the ExtensionsFilter inside a portlet?
>>  Everything else is working fine in the portlet environment.
> Filters do not apply to portlets.  The portlet spec recognized this and
> chose not to address the issue in the 1.0 specification.  Future
> versions of the specification will probably address portlet filters.
> some patches & files
> which will allow <head> elements to be written into a portal's final
> html page.  An integration class for Jetspeed2 has been written, you'll
> have to write one for any other portal.  I tried to write one for
> uPortal but it seemed too difficult (so I'm sorta fixing it via a
> different method; ask me if anyone wants details).

I should add that it is important to continue to have the filter in
web.xml.  The filter still needs to be used for serving additional
resources (like the .js and .css files).  The requests for these
resources come via the servlet interface not the portlet.

And if a component uses addJavaScriptHere() instead of
addJavaScriptToHeader() then that will work in portlets.  Unfortunately,
there is no way to add CSS "here", <link> tags must always be in the <head>.

Dave Brondsema
Software Developer
Cornerstone University

View raw message