incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <>
Subject Re: [PORTAL] Getting rid of filters
Date Sat, 04 Nov 2006 01:06:45 GMT
Then I guess the final question is, is it important if these don't run 
in the portal.

I mean if we can't change the API to be container agnostic and ordering 
is important, I'm forced to use the Lifecycle/ExternalContext approach 
for Portlets and the filter approach for servlets.  Not only is this 
painful and somewhat dirty, but a large chunk of functionality simply 
won't be available on the portal that, quite possibly, needs to be.

I mean I've managed to wrap Request and Response objects in the 
FacesContext for both the portal and the servlet.  Anything that is 
dependant on a ServletRequest will automatically not work in a portal.

So help me out here.


Adam Winer wrote:
> On 11/3/06, Scott O'Bryan <> wrote:
>> Two questions then:
>> 1) Being that these won't work in a portal environment, should we move
>> these to be executed elsewhere (like my custom lifecycle object) and
>> change the API to be more container agnostic (ie. using the
>> ExternalContext)?
> Changing the API is a painful way to go, and given that I've
> used it to wrap ServletResponse objects, a purely container agnostic
> approach isn't gonna cut it, I assume.
>> 2) If we do need to leave these in the filters, is it okay to move all
>> the other initialization logic (like setting up the skinning and
>> whatnot) to execute after these services or does it need to continue to
>> execute in the same order?
> Ordering is very important - one thing I've seen these filters
> used for is programatically registering additional skins.  And
> that had better happen after the original execution logic!
> -- Adam

View raw message