I have been doing Tapestry 5 work for about a year now, and I’m definitely still learning, but I think I know my way around fairly well. I really (mostly) like it, and I think it is way easier to use than Tapestry 4, as well as many other frameworks. It also results in a nice clean code base which isn’t too difficult to approach. There are, however, a couple of areas that I really just find confusing. Some of them aren’t too bad once you get to know them, but they are hard to learn. I think it is important for most aspects of the framework to be easy to learn/use, because if people encounter pain during their initial impression stage, they will abandon the framework and use something else.
The first issue I have is with the way that the Select component works when you want to have a dynamic model for the list. I think this is a common requirement for applications, so it is something people will most likely encounter fairly quickly. For complex models, it is usually necessary to implement two interfaces: SelectModel and ValueEncoder. The interfaces make sense once you get to know them, but I think the learning curve is quite steep for such a common task. I’m not sure how this could be solved, but it seems like Tapestry 4 may have had a more simple system (though I’m sure it had some problems which led to it being redone).
The second issue I have is with page context. Often times in standalone web applications, I have created pages which take query string parameters. These can be referenced by external apps or pages, and used to link between pages of an app. Tapestry’s equivalent is the page context, which can be used to pass contextual data between pages. There are two problems that I’ve encountered with page context. First, it is limited in what data it can represent. It is generally just a list of nameless parameters. This makes it difficult to pass only certain parameters or parameters with names. Second, the format for the URL is not a part of the spec (correct me if I’m wrong), so it can only reliably be used via other Tapestry pages. This makes it difficult to pass data in to a Tapestry page from an external place.
So to sum it up, I’d like to reiterate that I really do like Tapestry 5 and hope for its widespread adoption, but it has a few points that are difficult to deal with. If these issues were addressed in a future version, I think it would help ease a new developer’s adoption of the framework.
This just took me a really long time to figure out, so I’m writing it down. Tapestry 5.1 adds support for submit buttons with an image (I think it was added in 5.1). In any case, you just use the normal tag, but you add an image attribute which is an “asset”. I added an Asset property to my page class and used @Inject and @Path to inject the asset. I used that property name in the image attribute, and it didn’t work. It turns out, you don’t need to declare the asset as a property in your page class. You just specify the path in the image attribute just like you would in the @Path annotation. So, it looks something like this:
Much simpler than I was thinking. Sometimes I get really frustrated with these little Tapestry issues…
I ran into a problem today where I was setting the value of a radio button in Tapestry 5 to a long field within a property. I was getting back the value “on” and Tapestry was crashing trying to coerce it into a long type. It turns out the value was null, and the default value for a radio button is “on”. So, if you encounter this, make sure your value fields are not null.
I’m always looking for ways to streamline Java web app development. In case I haven’t spread the word to you, here’s the current set of technologies I’m liking:
- Tapestry 5 – This is the framework I’m using, but I’m not saying it’s better than anything in particular, but I like some of the stuff they are doing.
- Hibernate with annotations – I’ve been a big fan of hibernate for a long time, using the annotations seems to simplify the mapping process quite a bit.
- Spring Hibernate integration – makes transaction/error handling way way easier in Hibernate. I am using HibernateDaoSupport as a base class. Tapestry 5 also has Spring integration, allowing you to inject the DAO’s right into your page classes
- Maven 2 – So much easier than ant and dependency hell, once you get used to the paradigm shift. It might cause issues with your Eclipse tomcat integration, but I always found that to be flaky anyway. Use Jetty instead.
- Maven Jetty plugin – Allows you to build/deploy your app with one command (mvn clean jetty:run). Much easier than dealing with some of the flakiness of tomcat deployment, and allows you to just run one of your apps at a time.
I am also looking into Spring Security, and hoping it will simplify authorization, and I’m doing some IDE evaluations to see if it’s time to ditch Eclipse.
My new group at ASU is loosely standardizing on Tapestry, so I’ve been spending some time learning it. We are officially using 4.1, I think, since it’s the latest official release, but I decided to go all rogue style and switch to 5.0 after spending some time on 4.1. From the noise on the web, it sounds like Tapestry gets completely rewritten for every new version, so 5.0 is pretty different from 4.1. Anyway, it seems much better, but there are still some weird problems. Here are some of the interesting things I’ve run into:
- If you need to call some Tapestry page from an outside app with data, you can simulate Tapestry’s “activation/passivation” by building URL strings which will feed your onActivate method. They look like this: http://localhost:8080/app/page/param1/param2, where param1 and param2 will be passed in a List (not an array, as I found out the hard way) to onActivate. I’m not sure if this is the best way to do it.
- If you loop through a list of items and want to be able to edit those items (like by having a checkbox), you pretty much need to set up a PrimaryKeyEncoder, otherwise it will serialize/deserialize stuff and all your changes will be lost. This was very hard to figure out.
So far I’m only moderately impressed. There seem to be too many assumptions that don’t fit the model of my first app very well, but we’ll see how it goes once I get better at it.