Life Codecs @

Ruminations. Reflections. Refractions. Code.

Feb 23, 2009 - software dev

Bloggy: Wicket Demo Blog App!

I pointed out in a previous post that I was learning Wicket. I decided to write something a bit more realistic in it, and since blog applications are all the rage these days (oh wait, are we past Web 2.0 yet? :P) – I figure it was as good an app to write as any, fairly simply domain model if you don’t go crazy, you can find it – Bloggy – in the code section. Due to the huge number of dependencies (uses Spring, Hibernate, and the Hibernate JPA implementation, and of course the Wicket jars as well), I have simply provided the sources – it is a Maven-based project however, so it should be fairly easy to get up and running. I have tested it on Jetty, and you will require Java 6 for 2 reasons:

  1. I marked the source and target to be 1.6 in the POM, hah!
  2. I have used @Override annotations on interface implementations, which is a Java 6 only thing (as I found out from a friend just a few days ago)

As far as Wicket itself goes – I am impressed, thoroughly enjoyed using it. Some points worth noting:

  • The thing I tripped on most often was ensuring that my object and markup hierarchies were in synch – a little annoying (though I’d rather have it disciplined this way than overly forgiving models) – but the error messages turned on in development mode/configuration were awesome1
  • As pointed out in Wicket in Action, you do tend to think a fair bit more about reusing components, so you initially start slow because Wicket encourages you to write your own components (panels being the most reusable components)
  • I found it was necessary to have the sources (recommended just for the heck of it) open in order to see how certain things could be extended, not necessarily a good thing, but the sources are well-written and useful to write your own stuff, or just understand how things are handled underneath, especially dealing with models. Speaking of sources, it is very OO that I learnt a few new ways to use patterns myself. (Sigh, been dealing with crappy UIs far too long)
  • I think with Wicket 1.4+ where Java 5 is the minimum requirement, using models will be much clearer, I admit to having been spoilt by Java 5+ generics thoroughly, and I created a couple of base parameterised models
  • Serialization – wasn’t as big a deal as I thought it would be – in fact in a 3-tier app where we generally use DTOs, this won’t even be an issue, granted however, it’s still something to look out for, you don’t wish to be serialising huge stuff into the session, and it is easier to do that than in something like struts because of the very stateful nature of Wicket
  • Wicket’s spring integration layer is quite nice, it allows you to inject stuff, but since it does not have explicit bean definitions of your components, I don’t think (and I may be wrong) it allows you to do funkier things like AOP, in UI code, I generally don’t find this to be a problem, the injection is far more crucial for me. I think the point as justified by the authors is that Wicket is by default an unmanaged framework
  • Ooh the Ajaxy stuff – I am no front-end Javascript guy – this made it a breeze to use, you obviously must understand basic Ajax concepts, but you don’t actually need to write Javascript, fascinating, I used editable labels, and link-submittable forms mostly (which were POST-ed, no nasty GETs for side-effect producing actions). I did not venture far enough as to write my own Javascript components however :-).
  • The default URL generation scheme’s not pretty – but Wicket provides additional schemes (packaged as URL codec classes) which are much prettier, and you can write your own – I found the provided ones to be quite sufficient though. I love the way they’ve designed the hook into the URL generation. Well, I hope someone finds this useful, if google ever gets you here!

1 If you’ve worked with the Struts tag lib (Struts 1 anyway), you will see what I mean – Wicket’s UI handling is certainly no hack of a solution tacked on with inconsistent conventions and uber-crappy error messages (anyone like “bean ” not found in scope” or something to that effect – gee thanks, or that there’s no select-EL version or one of those damned controls). I dread going back to the work force having to use that piece of unholiness again. Note that my harsh criticism is directed at solely the taglib, the rest of Struts is something to be respected for having achieved what it did way back!