Raible Designs

My Tapestry Experience

I've finished migrating the sample app I'm working on from WebWork to Tapestry. You can also read about my WebWork experience. WebWork took me 2 full days to complete and the Tapestry version took me about 4. I had a bit of an advantage with WebWork as I've read a lot about it before working with it. I'm probably a bit biases against Tapestry because everyone thinks it's the bees knees - I don't mean to be harsh - I'm just reporting through the eyes of a developer. I'm sure I'll have similar gripes with JSF. Below is a list of things I discovered:

• There's something wrong with a project when its documentation is outdated and folks tell you to "Buy the book" rather than "read the documentation". On that same note, most of the documentation that does exist seems to be targeted at the advanced user.
• Like WebWork, there was no simple CRUD example I could look at. Then, like a ray of light from the sky - Warner published one yesterday! This tutorial vastly improved my productivity - thanks Warner! The only things I saw that I'd change in this tutorial is the use of individual setters vs. a domain object. Also, an ICallback is in the code, but never really used.
• The recommended way to name templates (.html) and page specification (.page) files is starting with an Uppercase letter. So rather than home.html (which most web developers are used to), it's recommended you use Home.html. Of course, this is easy to change - just seems like a weird recommendation, almost Apple-ish or Microsoft-ish.
• By default, all templates and pages are cached. Sure this is good because Tapestry is production-ready, but when you're developing - this needs to be off so you can get deploy+reload functionality. If you're using Tomcat, you can turn caching off by setting a $CATALINA_OPTS environment variable with value "-Dorg.apache.tapestry.disable-caching=true" (no quotes).
• Tapestry integrates with Spring very nicely. So easy it's almost silly. When I first created my list screen, it actually had only one line: public abstract UserManager getUserManager(); - and then I used OGNL to get my list of users: userManager.users. It doesn't get much easier than that.
• While setting success messages is fairly easy - I couldn't find a good way to prevent duplicate postings. With most frameworks, I stuff messages in the session and then retrieve them on the next page. With Tapestry, you have to throw a RedirectException if you want a true redirect (which requires a lot to calculate the URL of a page). I ended up using a PageRedirectException in hopes of simplifying this - but this seems to just do a forward instead of a redirect. In the few hours I spent on it, I couldn't find a way to save success messages and have them persist through a redirect. The reason I want to use a redirect is so a refresh of the page doesn't submit everything again. I know it's trivial, but is is an issue that most frameworks don't handle cleanly (except for Struts).
• There's no way to test Tapestry classes - since they're abstract, you can't just invoke them and test. Granted the classes are simple - but as long as other frameworks allow you to test their .java files and Tapestry doesn't - this will be an issue.
• When you first enter a blank form (i.e. to add a new user), the cursor's focus is put on the first required field. As a developer and user, I'd like to control this a little more (for example, by putting it on the first field). Furthermore, I'd like to control it easily - without having to subclass ValidationDelegate. On that same note, it'd be cool if required fields had an asterisk by default. WebWork does this and Spring/Struts can do this using Hatcher's LabelTag.
• There's no easy way to get the URL of a page - for example, to use in a <button>'s onclick handler to do location.href. I ended up having to implement a method in my page class, and a @Block in my template, setting the button's value with OGNL, and then using JavaScript to do onclick="location.href=this.value". The default components that ship with Tapestry only produce links and submit buttons (that must be in a form).

When developing this sample app, I often felt like I was banging my head against the wall. This is likely because I didn't want to take the time to truly understand how Tapestry works - I just wanted to get my app done. I did end up buying Tapestry in Action, but I probably won't read it until I have time or decide to use Tapestry on a project. I agree that Tapestry is cool, but it's certainly not intuitive for a Struts guy like me. I do look forward to working with it in the future and I'm sure I'll grow to like it more as I gain more experience.

Many thanks to Erik for his tech support and knowledge and to Warner for his nice kickstart tutorial.