Blog de ZedroS

Un article de joseph_p    21 Commentaires

Why Wicket ?

Let’s speak more about my choice of Wicket.

All started with an envy to find a web framework in Java suitable to my needs. At the time, these needs were quite shallow, but mainly focused around the following points:
– simplicity: I had no envy to dig in an over complex architecture, for a quite basic website idea,
– efficiency: simple things should be easy to do, and complicated/specific things should be doable as well, without too much burden,
– Open Source : as I did it on my free time, I didn’t want to have to pay or to make benefit some closed source vendors.

So other ideas were also around, but not precisely expressed. We’ll see how they came up during my “quest”.

So I started to look around. Having bought a book on JSF, I started digging into it. However, quickly, I realised that the various xml files, the quite complex life cycle and so on would be too much for my free time, especially since I was going to do specific stuff which weren’t already available. The IDE part of it was also lacking. Furthermore, at the time, I didn’t know Netbeans Visual Web Pack which seems quite interesting.

So I rejected JSF.

Struts wasn’t too much of an option: it was said to be “almost dead” and overcome by many other stuff. JSP didn’t had my liking as well : these pages full of tags and quite often even business code were simply not attracting.

Then I started to look at Tapestry, buying the book Enjoying Web Development with Tapestry, from Ka Iok ‘Kent’ Tong. This excellent book gave me a very good insight of the framework, and I happily started to use it.

But I quickly started wondering.

Tapestry 4 was the… 4th version of it, but is quite different from the 3rd version, as such many people were kind of stuck to the 3rd version. So the mailing list was divided between two versions, quite annoying.

Furthermore, Tapestry 4.1 came, with its amount of change requiring quite some changes in my Tap 4th version app. The developers being Tapestry didn’t seem to mind a lot about users stuck to a particular version, so were already eager to work on Tapestry 5 even if all the work on Tapestry 4 was to be lost. Quite annoying when one considers the lifespan of a web application.

Even if Ka Iok ‘Kent’ Tong provided an updated version of his pdf, I was now quite cautious.

Then I started to realise some stuff I didn’t like in Tapestry 4 :
– the html template could be encumbered by a large amount of Tapestry specific tags, quite like JSP or the like
– the components in Tapestry 4 are not really inheritable. Not that good for reuse.
– I found the framework not DRY (Don’t Repeat Yourself) enough for me, as I was writing quite a lot of stuff to define a page

All in all, I ended to conclude Tapestry wasn’t for me.

So I looked around once again. I had a quick look at Wicket, but then grails was gaining much advertising and so I decided to give it a look. It was a pretty interesting journey, from groovy to the web framework. Quickly put, I decided not to go for it for the following reasons :
– I didn’t manage to get well with groovy, even if the stuff was impressive
– Grails is really interesting as well, but the integration with others frameworks I wasn’t really in touch with was worrying me. Furthermore, even if simple things were… simple to do, I was more sceptical for the complex ones. Had I been more trained in Java (especially in Spring/Hibernate), it would have been different, but I wanted to be familiar with the frameworks behind before having yet another above layer on them.
– Grails has once again a JSP/ASP like approach to web page, with a quite large array of things being put in the page

Once again, I started looking around.

I had a quick glance at GWT, but I found it way to ajax heavy. I wanted to do a quite light weight website, which I think is quite incompatible with heavily ajax oriented framework.

Then I fall on this article : http://www.oreillynet.com/onjava/blog/2007/01/wicket_another_java_web_framew.html
It sounded quite interesting and so I decided to have a closer look.

As I was still remembering Kent Tong book, I went for Pro Wicket, by Karthik Gurumurthy. I found this book helpful but not as much as Kent Tong’s one: it isn’t such a top down approach as I really appreciate. Whatever, I was easily able to discover the framework, and it looked really nice.

Deciding to push it a little bit further, I started doing one of these specific/complex stuff I was requiring. And there came the revelation: the mailing list is really amazing. Igor Vaynberg, who appears to be the project leader (at least on Apache where Wicket is currently incubating), responds to all mails without answer and even complete others’ answers. Really helpful and impressive. And even better, the core developers aren’t zealots: they quite often advise “frameworks explorers” on the mailing list to go look at some others frameworks if it seems better suited for them.

EDIT : I did a mistake, Igor isn’t the leader, « just » one of the commiters. Thanks Igor for pointing this out to me.

That’s what quite a point for wicket, furthermore the architecture of the framework was pleasing me a lot:
– possibility to make or reuse “components” at will, integrating or not, as needed, their html part
– wicket mark-up in the html is really limited to the essential. There is no way a developer will start to put all the business logic in the html page.
– Simple and efficient: for each html page, you have a Java class. It’s really straightforward, but powerful as well : with components reuse or heritage, heritage and so on you can really multiple the possibilities
– A lot of very nice ideas: from “inheritable properties files” (more on it later) to easy ajax. The way to present data, through the Model interface, is particularly useful, especially for list and the like.

All in all, I started digging in and… I’m still in love a few months later. Will it go on? Time will tell!
Oh, some last words. Since my start with Wicket, the community has chosen to stop the development of Wicket 2.0 (which would have introduced a lot of API changes) and rather to back port its feature to Wicket 1.3. Why ? Simply because the gain of the API changes wouldn’t be enough compared to the cost of having everyone migrating. And, as well, because most of the improvements could be “back ported” to 1.3. Impressive isn’t it?

Since some of the features looked very promising, I’m since last week using Wicket 1.3 and… it works well. So my future articles will be focused on it.

I hope this long lecture has interested you. Anyway, I feel better now and … I can start some more technical stuff to introduce Wicket !

All feedbacks are welcome !

ZedroS