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.
Scott
Adam Winer wrote:
On 11/3/06, Scott O'Bryan <[EMAIL PROTECTED]> 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
