On 11/3/06, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
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.
I'm happy with adding some servlet-agnostic APIs for some
of the purposes served by the existing filter code. I'm just saying
that the goal of 100% no filters, 100% shared code is overly optimistic,
and that we really, really, really shouldn't just nuke the existing filter
API.
ExternalContext isn't 100% sufficient. Ergo, perfect code sharing
and being totally agnostic to the Servlet API isn't gonna happen.
Forget about perfection - let's take steps towards making things better.
-- Adam
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
>
