On 5/5/06, Don Brown <[EMAIL PROTECTED]> wrote:
It isn't about using Cocoon or "building another version of it", but rather learning from others design choices and consequences. I see Struts Action 2 as a chance to quit "competing" and start "collaborating". Merging with WebWork was the first important step, but equally important was Tim from Stripes joining the design discussion, and IMO, finding a way to leverage other project's experiences including Cocoon. The point isn't that we should do whatever Cocoon did, but there is value in learning from how they tackled a similar problem. In the end, we may go with a new abstraction layer, but it is still important to make that decision fully informed.
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
