Tapestry Portlet Support Finished

I think we're there ... Tapestry 4.0 Portlet Support is finished. Things appear to be working correctly in both eXo and Jetspeed 2.

A last minute nightmare was something I missed in the Portlet spec ... that render parameters (set during an action request) are absolutely maintained when the user clicks a portlet command decoration (view, edit, maximimize, etc.). I had previously thought that there would be no query parameters on such render requests.

This affected my approach, since I had code that would see if there were query parameters and, if not, use a system of confiugrations and services to figure out what page to render. Basically, an extensible system whereby clicking the edit button would activate a page named "Edit", the help button would activate "Help" ... and you can even do tricks based on portlet mode and/or window type to determine the correct Tapestry page.

I had to do a little trickery to get this to work; during action requests, I figure out the page to render, and set the render parameters (service=render, page=XYZ). I also set two additional parameters, portlet-mode and window-state. The render engine service compares the portlet-mode and window-state in the request to the values tored as query parameters ... a mismatch means the user clicked one of those command buttons, so we ignore page and uses the configuration to figure out the page to display. Thus you see Help when the help button is clicked.

I'm not fully happy with it ... you tend to get dumped back out to the View page after help or edit, even if you were on another page. It's a little inconsistent.

From what I can read between the lines, the Portlet spec authors didn't really think this stuff through ... I think they expect Portlets to be brain-dead simple, and for there to be a very easy mapping from portlet mode to JSP, with maybe some conditionals in place for handling window state. I think any realistic Tapestry portlet will consist of several view pages.

This could have been handled more elegantly as a form of event notification ... or even a flag on the RenderRequest indicating that it was a "special" request caused by a change in portlet mode or view state.

Well, what's important is that it's working. You can have multiple Tapestry portlets of the same or different types. You can package multiple Tapestry portlets in a single WAR. Each gets its own HiveMind Registry. I've written documentation.

Now is the time is to get everything left in 4.0 wrapped up and finalized. Time for a beta, and then a goodly amount of bug fixing and documentation ... and a very tight schedule for 4.1.