Hey everyone,
I'm going to be starting the portlet work on this starting next week.
Yes, they are actually paying me to fix this stuff :)... So I was
going over some of my strategies for doing some of this work. One of
the major problems with using Trinidad with a portal environment are
filters. In Trinidad our filters do several things, among them are:
* Creation of the TrinidadFacesContext object
* Handling of File Uploads
* Some other junk that I don't remember :)
So, FileUploads and things that need request/response wrappers we're
looking at handling those through extending our FacesContext. Tomahawk
has some code to do this and I'm either going to try to leverage that or
come up with something similar. So that badness is out of the way.
For the other stuff, essentially what we need is something that executes
before and after the "execute" and "render" methods on the lifecycle.
In ADFFaces 10.1.3.1 (Trinidad's Portalized Predicessor) this was done
by adding an enhancement to the Faces Bridge Portlet which was,
essentially, a lifecycle listener that called our initialization code
before and after the call to the Lifecycle methods. 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.
Scott
