The point of this reply is that you'd want to ensure that your setup
command gets called as part of the render() lifecycle, so that you can
do the setup stuff even if your portlet wasn't the one that processed
this request's form values. It might even mean some thought should be
put into separatin
If working in portlets is still an item of interest for a chained
request processor, there's an interesting synergy with the way that
JSR168 defines its request processing lifecycle as well.
When a portlet request comes in, the container passes the request to
the processAction() method of the one-
At 11:03 AM -0600 1/6/05, Hubert Rabago wrote:
Hi Joe,
I've also been interested in these discussions, though our earlier
discussions revolved around the old RequestProcessor. I haven't had a
chance to try out the shiny new chain (or is it still rusty and needs
some polishing?), so lately I've bee
Hi Joe,
I've also been interested in these discussions, though our earlier
discussions revolved around the old RequestProcessor. I haven't had a
chance to try out the shiny new chain (or is it still rusty and needs
some polishing?), so lately I've been limited to lurking.
That said, I too believ
At 7:30 AM + 1/6/05, [EMAIL PROTECTED] wrote:
Ted once suggested to add a 'FrontController'.
That class could be optionally plugged into the action mapping, and
would do the view preparation.
This is an idea I've been poking at and talking about for quite some
time, but I am getting the feelin
