incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: Re: [PORTAL] Getting rid of filters
Date Sat, 04 Nov 2006 02:32:55 GMT
On 11/3/06, Scott O'Bryan <darkarena@gmail.com> 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 <darkarena@gmail.com> 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
> >
>
>

Mime
View raw message