Encountering Tapestry

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.

  • Mike Hogan

    Yeah Jon, I agree. tapestry gets the ‘what’ right, but the ‘how’ is way off. You can achieve the same ‘what’ with a much better ‘how’ using the echo framework. At least in java land that is.

  • http://jimsrandomrant.blogspot.com Jim Kuo

    Like most frameworks, it’s not perfect for everything. I agree that if your site requires a lot of customised parts or behaviours, it’s probably not the best tool to use. Its strength lies in the rich sets of framework/tools available. It allows component based web development and lets you to build your site up quickly by putting these building blocks together, not doing everything by yourself from scratch.

    It also takes cared of the management of the low level stuff and the life cycle of your classes so they can be injected them easily in your pages using annotation when you want.

    I agree that Tapestry has got many pit falls, if you don’t know what you are doing, it’s easy to end up in a mess. However, I would think it should be considered user error.

  • Brian Foger

    Hi Jon, i agree on most of what you said. A team with no prior experience should not try to dig into the unknown, unless more senior devs are really involved. Why did you chose to use it in the first place?
    It is lamentable to rush into a brand or a product without a glimpse of knowledge. I think you will face delivery problems, and you will shorten scope or features of your product. In my experience additional resources will not solve the problem unless they have the necessary skills.

  • jon.pither


    In this case Tapestry was chosen by team members that have since moved on. The devs picking it up do have some limited experience with Tapestry and of a wide range of other frameworks.

    The point I make is that Tapestry has a larger learning curve than most frameworks, and this will impact any large team as people naturally move on/off of the project.

What’s this?

You are currently reading Encountering Tapestry at Pithering About.