May 6, 2007 § 4 Comments
Recently I’ve been a on Java web app project, using the framework Tapestry. I see this as a good fortune; I’ve been wanting to add it to the list of Java frameworks I had used in anger (Webwork 1 & 2, Spring MVC, Struts 1.x, Turbine).
So what does a new end-user think of this tool? Well rocking into the team I could immediatley see there were pained faces of exasperation. I should point out I try not to condemn a tool/technology based on the opinions of the majority. I find that developers as a collective are often too quick to attack tools before investing an appropiate amount of effort into learning how to use them properly.
However, these faces were very pained. There seemed to be a consensus that Tapestry had a very steep learning curve, and once you tried to do something a little more challenging (for example editable / sortable / paging tables), things got tricky, and Tapestry, God bless its cotton socks would hinder rather than help. To be fair I should point out that none of us knew Tapestry inside out (although strangely people admitted to having 1-2 years experience with it).
Interestingly, Tapestry has a large community, some books out about it, and is still under development (unlike the peculiar framework Turbine, which some people actually think was an academic experiment). Tapestry even had a solitary advocate amongst our fairly large dev team (although to be fair I suspect he employs this role out of a good natured humour). Reading a blog such as this, you can clearly see the divide this framework can induce.
I will mention now I’m using Tapestry 4.0, and it’s moved on to Tapestry 5.x which I believe is heavily annotation based (a good thing IMO, if it reduces the amount of needed XML).
So, I’ll mentioned the niggles I experienced first. The first thing I noticed whilst at the foot of the learning curve, was ‘Wow, you have to modify a Java class, XML file, and a HTML-with-Tapestry-syntax file just to add something to the page?’ I found it odd that to see what’s going on you constantly had to switch between these three files. Then the Java Page and Component classes were all abstract, which had led to a lack of testing and more head scratching.
Later, I discovered that Page objects (the perhaps nearest equivalent of Struts, Webwork actions and Spring’s controllers), are pooled, and don’t get cleaned up by Tapestry when they are re-used for each request. A developer unknowing this put state in the page class, causing a bug where two people interfered with each others search results in production. Personally I think this is an accident waiting to happen with Tapestry. I appreciate the feature (or lack of) the other frameworks have where you get a nice new clean action-object to play around with each time.
Another problem I had was with the component libraries. Being a component based framework, the community has chucked in additional components than from what you get out the box (In Tapestry it’s called the Contrib library). There’s a fair bit of deprecated stuff, and you get a feel for the less restricted evolution of this contributed library. In our case we used these contrib components in order to add checkboxes to a table. This was a difficult feat in itself with Tapestry, with quite a few twists and turns, but made worse when there are two classes with almost the same name – IPrimaryKeyConverter and IPrimaryKeyConvertor. Unknowing this I spent a while trying to get the wrong one to work. Even the book and current codebase disagree on the spelling of ‘converter’. Strewth.
So there are a few problems, what about the benefits? Well, Tapestry’s big draw would be through its use of components. You could if you wanted not use components, and have the Page class (mixed with a heinous amount of XML) work with the view pages on a one-to-one basis. However this is an obvious antipattern, as quite simply everything gets quickly cluttered and difficult to understand, much more quickly that with the other frameworks. If you spend time coming up with a well-considered design for your components and pages, one can experience moments positivity. You may feel that the world is not such a bad place after all. In fact the book we have is called ‘Enjoying Web Development with Tapestry’ – but I think this may be a step too far.
I do suspect there is an elegance to be achieved. Tapestry forces you to think in terms of breaking your pages up into components, and provides the means of explicit wiring and state-passing. The trouble is that the learning curve is steep, having someone on the team with experience of the framework is crucial, and there are lots of quirks that can trip you up.