On 5/5/06, Craig McClanahan <[EMAIL PROTECTED]> 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.
<Friday>
Obviously this is not the place and time to rant on this, but I never
understood why portlet spec had to invent its own API instead of
leveraging JSP features and extending them. Having portlets as
dynamically included JSP fragments and sending HTTP request directly
to a fragment seems much simpler to me than channeling request through
portal engine and converting it to processAction() or render() or
whatnot.
An included JSP fragment can be used as a request target and can
receive standard HTTP request. Then it can update its state and render
itself. It does not have to know about the container page, neither the
page has to know the details about the component it contains. It is
very simple and it works.
If all J2EE technologies had been carefully built in sequence, we
would have had portlet spec built on JSP, and JSF built on JSP +
portlet spec. There would be no need to do stuff like reinventing EL
in JSP and JSF, and then combining them together. And everyone would
be happy.
I understand that Portal engine provide more than just channeling the
request. It does stuff like preferences, user info, caching, security,
access to persistent storage, packaging, etc. Anyway, these valueadd
features could be added to JSP/servlet spec instead of creating a
totally separate spec.
Therefore, I personally consider JSR-168 a big mistake, and I would
prefer it to die peacefully.
</Friday>
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
