Tapestry Portlet Progress

Whether we call it 3.1 or 4.0, the new version of Tapestry (supporting JSR-168 Portlets) is coming along. Basic forms and links are now working. The portlet namespace is used to extend the name generated by Tapestry (so instead of "Form0" you might see "Form0Pf0403f0dc0a8fe0201a826c5ae430341I"). That goes most of the way towards ensuring that JavaScript variables and method names are unique ... just a little extra tweaking will virtually ensure it.

The hardest part, besides cleaving Tapestry away from the Servlet API, has been the division between the action request and the render request. This causes a few problems ... not least of which is what to do with an error during the action request? We can't just render the response immediately ... I'm going to experiment with a solution where we render the response into a buffer that will be available in later requests.

Some similar problems exist for handling stale link and stale session exceptions. Nothing insurmountable.

The asset service is a bit of a pain; it will be necessary to map an ApplicationServlet, just to handle the asset service. The Portlet API doesn't include any concept similar to a servlet that renders a dynamic image. This is problematic for assets ... its even worse for getting Portlets to support Ajax-style operations. The worst part is that the servlet will need its own HiveMind Registry ... as will each Portlet.

Still, I'm pretty pleased with the progress and how its shaping up. Servlet Tapestry is improved as well. Of course, I'm brimming over for ideas for the next generation of Tapestry (5.0) where we get rid of abstract classes, inheritance (from Tapestry base classes) and XML specifications (in favor of annotations). But 3.1/4.0 (whatever we call it) will be quite extraordinary in its own right.