Wednesday, July 11, 2007

Tapestry5 vs Wicket: 1 - 0

Getting started with Tapestry 5 is easier than with Wicket 1.3. Some readers will complain that it is again the view of someone who has no deep knowledge of either Tapestry or Wicket. But I think it is important for projects to be easily accessible to developers. Wicket seems to have more buzz around these days, and has a detailed wiki with plenty of useful information in it. But that's the problem I see with Wicket, it is not simple to do simple things, that is why there is so much information to do simple things in the Wicket wiki.

Granted my test was based on a specific case for component frameworks, I was not so much interested into statefulness, I wanted to display a bookmarkable "user page" with content coming from hibernate.This kind of behaviour is quite general in web applications, especially in web 2.0.

It was relatively easy to have the page working with Wicket, although I was disappointed at their hibernate integration. Hibernate integration in wicket means either using the full databinder project, or creating your own solution. I chose the later based on source code from databinder, but I actually rewrote everything in the end. I was disappointed that databinder, a specific Hibernate oriented framework did not really handle Hibernate sessions the simplest way possible. Tapestry5 got that right. To manage Hibernate sessions right, I had to dwelve into Wicket code as no documentation offers insight about inner workings of wicket. The code was too complex for my taste. In my short experience, I saw it seemed the developers are changing it to the better, removing some unnecessary abstractions.

In the end I got frustrated many times with Wicket, and did not manage to have a bookmarkable page the way I wanted. You can have a bookmarkable page, but after some action on the page, it would become unbookmarkable. Furthermore, the structure of the URL is not very flexible without yourself rewriting completely the bookmarkable page feature of Wicket.

With Tapestry5, I was at first worried about the small amount of documentation on the site, the use of maven in the tutorial. I was wrong, documentation proved to be exactly what I needed, and detailed enough. It is much easier to understand how Tapestry5 works after reading the doc than Wicket. Concepts in Tapestry5 are simpler and more powerful. Maven use is in the end not that big of a deal, I am still not as comfortable with it but I am productive enough that it is not an issue, much more productive than with Wicket. The standard tutorial setup is a very good one.

Doing a bookmarkable page was trivial, it also was easy to have the format i wanted, and it was kept after action in the location bar. Hibernate integration was trivial, since Tapestry5 provides the tapestry-hibernate module, a few classes that helps managing the session and transactions for you. The only drawback is maybe the yet another inversion control system to learn. Tapestry5 IoC is very near from Guice in its philosophy. I wish Guice was made the default for IoC in Tapestry5.

To conclude, there is no doubt about it, Tapestry5 is the winner.

5 comments :

  1. Hi, thanks for your post. It would be nice to see some code comparisons if you have that.

    ReplyDelete
  2. I followed the links in your post and saw that T5 uses a session per request. Wicket has always taken the position that you can just use Hibernate's (or Spring's) opensessioninview filter for that. Is there any reason why you would prefer T5's module over a filter? Using a filter has the advantage - besides not reinventing the wheel - that you can use it for other request end-points as well. The project I'm working on needs this, as we're mixing some Flex code with our Wicket app.

    ReplyDelete
  3. using the T5 filter instead of a regular Servlet filter allows the use of dependency injection for the hibernate session, which is convenient. Of course, if T5 used a standard DI framework, a standard servlet filter could fit the needs.

    In Wicket, the databinder project does not use a simple servlet filter but writes code around wicket request processing.

    ReplyDelete
  4. "In Wicket, the databinder project does not use a simple servlet filter but writes code around wicket request processing."

    Indeed it does. (And, WHY is my Technorati feed always delayed by a month?) I'm not sure what you're saying is the simplest method though; servlet filters or injected modules? Databinder 1.1 beta1/trunk uses thread-bound sessions, one of the methods described on that Hibernate page you linked to. For me that is "simple," but simplicity is highly subjective!

    ReplyDelete
  5. I totally agree with you comments.
    I decided not to use Wicket because of the things that you mentioned. I am now comparing between Tapestry 5 and Spring MVC. One thing that I don't like about Tapestry is OGNL usage (replaced by prop 90%) and potential no backward compatibility in future.

    ReplyDelete