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
Scott
Adam Winer wrote:
> On 11/3/06, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
>>
>> Hello everyone,
>>
>> I'm almost done implementing a custom wrapper for the life cycle which
>> should allow us to replace a large part of the functionality of our
>> filter (the other part being handled by FacesContext wrappers). I did
>> have one question regarding "services" which are referred to in the
>> TrinidadFilterImpl object. It appears, basically, that the
>> TrinidadFilterImpl is responsible for kicking off a number of services.
>> These "services" use a FilterChains to execute and, as such, are not
>> compatible with a portal environment. Can anyone tell me what these
>> "services" might be used for and what guarantees, if any, we make as to
>> when they are executed?
>
>
> They can be used for anything that a Filter can be used for. I've used
> them for initialization; also, for wrapping of servlet objects.
>
> -- Adam
>
