These are very good points. How does JSF handle the multiple renders? Do you
have to ensure your backing bean is session scoped? Wouldn't a request scope
mean the data would be lost at the end of the processAction()? How would you
expect a portlet lifecycle to be supported with a stateless Action-based framework?
Don
Craig McClanahan wrote:
If support for a portlet environment is a goal for SAF2, remember that
there
is more to it than just papering over the differences between the portlet
and servlet APIs. You also have to deal at the functional level with the
differences in the request processing lifecycle of the underlying
container.
In particular, consider the scenario where there are six portlets on the
same page. One (and only one) of them will be the destination of an
incoming GET or POST request (the "processAction()" part of the portlet
lifecycle), followed by all six of them doing the "render()" portion of the
lifecycle -- potentially simultaneously on multiple threads. Also, request
attributes from the portlet that performed the processAction() are *not*
carried forward to the render() call on that same portlet.
JSF dealt with this by formally dividing the request processing
lifecycle in
two, along the same lines. (In a web application, it just calls the them
serially for the one-and-only request.) That, plus the abstraction of
ExternalContext, made supporting JSF in portlets pretty
straightforward. It
would seem that now (when API design is being discussed) would be a good
time to decide if portlet support matters, and (if it does) to take the
lifecycle differences into consideration in the design.
Don
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
