Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Thursday, June 02, 2005

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.


Anonymous said...

Are there any sample portal sites with the portlets built with Tapestry? Examples/samples are appreciated.

Anonymous said...

Indeed, I haven't seen anywhere any single tapestry portlet application example

Raul said...

We're successfully using Tapestry 4 portlets in our intranet running on liferay. There is a sample tapestry portlet bundled in liferay.

GK said...

Hi guys,
I have started using Liferay and was successfully able to deploy the sample tapestry portlet which comes with liferay, but i am having problems when i am trying to customize the tapestry portlet.
This is what i am trying to do.
I am using a {projname}.application and declared meta parameters like default page and default packages.
and moved the .html and .page into folders under WEB-INF in the WAR.
After doing this when i deployed the Tapestry portlet
I am getting error 'Page View not in the namespace'
Even though i do not have a page with the name View.
Can anybody help ?
I am stuck.