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 <[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
>
