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!

Monday, August 09, 2004

Groovy and Tapestry: Followup

As a follow up to my earlier post about combining Tapestry and Groovy, the folks involved (Michael Henderson and Richard Hensley) have combined their implementations and set up a SourceForge project.

It looks pretty sweet; you create a script and static methods in the script can be listener methods. Also, by using the correct method names (say, pageBeginRender), you script's static methods will be invoked at the right times. Also, static listener methods.

I think Hani had a diatribe not long about about flexibility. However, one of the core features of Tapestry is how it is divided into subsystems, precisely to provide this kind of flexibility ... such as changing the very nature of the framework! For the vast majority of users, that flexibility is masked as unnecessary complexity (which is probably the root of Hani's blog-arrhea). But often, that complexity is a reflection of a far reaching vision. Tapestry has always supported the notion that some pages or components would not be files in the WAR, but would be located from an external source, or even created dynamically at runtime. The bridge code that allows Groovy scripts to act like pages is one offshoot of that vision.

1 comment:

Richard Hensley said...

I would like to support Howard's comments about flexiblity in Tapestry. However, I did not find the flexibility to be hidden behind a mask of complexity. I've found in working with Tapestry to create the Groovestry module that the flexibility offered by Tapestry was easy to find and use. I think it is a complement to the design and engineering of Tapestry that Michael and I were able to create something like Groovestry and have it run with Tapestry 3.0.

By the way, the methods on a script do not have to be static, however I am promoting using static methods because object state can not become an issue. I believe this promotes the idea of creating a stateless listener and avoids errors that are hard to find. One of my primary goals in creating groovestry was to reduce the number things that can break while creating the content of a web application.