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? ) – 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:
- I marked the source and target to be 1.6 in the POM, hah!
- 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 awesome
- 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
- 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!
 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!
The title means “Wicket is Wicked!” in German (I know, lame, still kinda funny though ). More seriously I just finished Parts 1 and 2 of Wicket in Action. I found the book to be very well-written with one exception: the analogies to the lasagna preparation made me very hungry – I am currently fasting, ahem. Apart from that, it certainly explained the framework well enough to enable to me to write this post, so kudos to the authors and Manning. Here’s my ‘review’ (if I may be so bold) of the book/framework (note that this is based on fairly limited usage writing toy apps, so caveat emptor):
I fully read and tried out examples in parts 1 and 2. I love the framework, it truly brings an OO component-driven model to web programming. As the authors aptly pointed out, Wicket solves the impedance mismatch problem between the stateless nature of HTTP and stateful object model, and Wicket solves it well! The impedance mismatch issue is analogous to the one we have between OOP and RDBMSes which of course ORM solutions like Hibernate solve. Some pros and cons:
- Familiar OO UI programming model, especially for people who’ve written thick client apps in toolkits like Java Swing.
- Encourages typesafe – almost transparent – state maintenance using objects rather than direct manipulation of the Servlet HttpSession.
- Excellent abstractions make learning logical and intuitive, for example a Page represents a top-level container, similar to a Frame object, to which you can add child components.
- Minimal configuration gets you started. Pretty much just web.xml to configure your wicket app, the other plumbing can be done using Maven 2, definitely check out the bonus chapter 15 online very early on to configure your IDE so you can play with the examples.
- Makes wizard creation – a fairly common and very tedious task in web programming, God the pain… – a breeze, not because it has specialised classes or declarative ways of doing it, but because state maintenance is easy, passing one page instance to the next page instance is straightforward (Page1.java: page1 = this; … setResponsePage(new Page2(page1, …)).
- Previewability – allows HTML pages to be viewed with dummy data that will be removed at runtime. The authors admit however, if a page has a lot of components, it makes it more tedious to preview.
- I did not mess with this a lot – but Wicket seems to have decent Ajax support, including transparent fallback to non-Ajax behaviour if it is disabled on the browser. The authors point out that Wicket takes the view that Ajax is optional, and assuming you use the correct Ajax+Fallback component, no code changes are needed to accomodate both Ajax and non-Ajax behaviour. Chapter 10 of the book which I hardly read (part 3) goes in more depth about using Ajax.
- Due to the stateful nature – makes checkbox and multi-selection handling a breeze, woohoo!!
- A lot of built-in validators for common validations – having said that, these days I tend to prefer having validations (== business rules) done via my models, so this doesn’t buy me a lot – in fact it would make me put business rules in the web tier. Ideally we could annotate models and use some form of code generation (I hear screeches of pain…) for both the models and the client side for better responsiveness, of course some validations just can’t be done on the client side, so still thinking on this.
- There’s a lot of reliance on Java object serialization – to achieve transparent state maintenance, Wicket serializes the manipulated markup and code at the end of each request. This means any models you have used in the session must also be serializable. The good news is the authors spend time talking about this, and ways to get around it, using detachable models (I’d rather call them model wrappers for they wrap your actual model object) for example. This is also something to take note of when considering performance issues.
- For people used to request-response based frameworks like Struts, the programming model will take a little bit of getting around – although I got around it pretty quickly, it seriously is way easier and more logical, especially to back-end programmers. As with any framework, there are new concepts to pick up here and there.
- To bind models to web forms, strings are used in the form of property expressions (e.g. foo.getAddress().getStreet() -> “foo.address.street”), this obviously will not be picked up when your models get refactored. Hopefully smarter or Wicket-aware IDE plugins will help in this area. This plague is common to many frameworks… (e.g. in Hibernate: HQL and even when using the Criteria API).
- In spite of adherence to the DRY principle, it does not generate HTML for you, and markup (which are tagged with “wicket:id” attributes referenced in the code) and code must remain in synch or Wicket will throw an error when accessing that page. This is good and bad, the nice bit is it does allow web designers to maintain the look and feel for you. Wicket IDs, Code Hierarchy, and Markup Hierarchy synchronisation is another place where Wicket-aware IDE plugins would be useful.
I only skimmed through Part 4, but it definitely has a lot of useful advice on integrating Wicket with with other toolkits and middleware such as Spring and Hibernate, and on internationalization (i18n) and localization (l10n) (still trying to figure what the latter’s scope is exactly…), something that’s missing in many books – while it’s not strictly necessary thoeretically, practically no framework works in isolation these days except perhaps if you get full-stack frameworks like Grails or JBoss Seam that Ruby on Rails popularised; dunno, I still kinda like cherry picking my parts, but I haven’t explored these so I may change my mind.
Hmm, I wonder how it compares to GWT – something else to try out when I have time, for now, time to check out EJB 3.