[Question] Trinidad Filter Services [was: Re: [PORTAL] Getting rid of filters]

[Scott O'Bryan <da...@gmail.com>]

Fair enough.  I can certainly make it so that the filter is an 
"optional" component and we can keep the filter code in there.

That being said, are there some specific circumstances today where these 
filter services perform some logic that are needed in portal 
environments.  I do agree that right not the Portlet API does not yet 
allow us the flexibility of the Servlet container so simply eliminating 
the filter may be a bit premature.

For instance:

One of the requirements I heard from Adam was that of setting up skins 
in these filter services.  Perhaps it would be prudent to have a special 
skinning setup api that could reduce our reliance on the filter 
framework and allow for handing of this in a portal environment.

Does anyone else have requirements for these filters that they would 
want addressed in a more generic fashion?

Adam Winer wrote:
> On 11/3/06, Scott O'Bryan <da...@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 <da...@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
>> >
>>
>>
>