You know you can do that all in one phase listener, right? It's
really not much code at all to implement an algorithm like this.
Yes, but even the code in 10.1.3.2 which doesn't take phases into
account is somewhat scary. :) Adding logic to figure out what phase is
next is a lot more scary. And as you said, in 1.1, there is no
guarantee that the endPhaseListener gets called.
Hrm, I'm confused - I thought you were talking about implementing
a custom Lifecycle object. Do you mean a custom Lifecycle, or just
a custom Filter? A Filter + a PhaseListener is fine. It's just
implementing Lifecycle itself that is a bit scary.
I'm trying to eliminate the filter all together. I can put code in the
bridge which calls a particular "listener" before/after the execute and
render methods are executed in the bridge, or I can make a custom
lifecycle which requires NO changes to the bridge and executes the
initialization code at the beginning and end of the lifecycle itself.
The object itself wouldn't be too scary as it would do it's
initialization and then deligate to the underlying lifecycle object.
Code wise, it allows us to take advantage of the JSF ExternalContext
abstractions much easier and eliminates the need for special handling of
the "Portal" usecases.
-- Adam
Scott
Adam Winer wrote:
> On 10/20/06, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
>>
>> My question is
>> this, is there any reason we can't provide our own custom lifecycle
>> object that decorates the default one and allows us to run our
>> initialization code on the execute and render? If so, the code to
>> manage things like the TrinidadFacesContext becomes a LOT easier
and we
>> can rely on some of the stuff already build in to the Bridge
Portlets.
>
>
>
> What's the advantage of a custom lifecycle over using
> a phase listener?
>
> --Adam
>
