On 3/20/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > In all three cases, the concept is to map the Portlet API "processAction()" > method to the Restore View through Invoke Application phases of the JSF > ifecycle, and to map the "render" method to the Render Response phase. The > interesting part of programming portlets is that the render phase will get > called for *all* JSF-based portlets on the page, while the action stuff is > only called on the portlet to which the form submit was directed. In > practice, that means you need to ensure that you have access to whatever > state you need to rerender yourself at all times, even if you didn't receive > the submit.
Yeah, route a request to a component for processing, then render the whole page. Been there, trying to do better ;-) JSR-168 API has benefits, it provides common grounds to inter-portlet communication. Still, a single entry point makes JSR-168 Portal look like an obese version of Struts. Well yes, it provides the additional services too, but I would prefer to have services without having the limitations. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
