On 10/23/06, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
We discussed this in 10.1.3 about how there is no guarantee that the "cleanup" will happen if the life cycle is short-circuited.plus we would need a bunch of touch-points. We would need listeners on the following:
There's definitely no guarantee in 1.1 even that afterPhase() gets called . In 1.2, afterPhase() will be called, but you can get tricked if a phase listener after yours calls responseComplete().
1. Initialize before Restore Component Tree 2. Cleanup after Process Events only when Response Complete or Render Response is the next phase 3. Cleanup after Process Events only when Response Complete or Render Response is the next phase. 4. Cleanup after Process Events only when Response Complete or Render Response is the next phase 5. Cleanup after Process Events 2 6. Initialize before Reader Response 7. Cleanup after Reader Response
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.
It would be far easier to run the execution code at the beginning and end of the LifeCycle's "execute" method and at the beginning and end of the lifecycle's "render" method just to make sure we hit all the touch points. Also, some of the cleanup above (ie. cleaning up before Render Response and then reinitializing could be optimized, but do remember that in the portal, each portlet can recieve multiple render-requests for each action request. So the TrinidadFacesContext object should be the same between those calls to render-request. I've just added some code in 10.1.3 that was causing issues with this and process scope. Of course when dealing with servlets, this all becomes trivial. Now that being said, if you still think LifeCycle listeners are the way to go, I would be happy to explore that option. I know this is the type of stuff that LifeCycle listeners were designed for, but I also know there was a reason that Trinidad used filters instead of lifecycle listeners before. Eliminating the need for filters altogether would be a good thing.
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. -- 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 >