The title means “Wicket is Wicked!” in German (I know, lame, still kinda funny though :P). 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:

Pros:

• 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.
• A lot of thought has gone into packaging new components, complete with their own resources such as CSS files, images, and Javascript. This extensibility does allow a lot of reuse of components easily, very much in line with OO principles.
• 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.

Cons/Gotchas:

• 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.

— Kamal