My experience with Wicket

Today I found out that I’m not a Java programmer. The more I look at programming languages in general, the more I find Java to be clumsy and short-sighted. For a project at my work I tried Wicket.

A lot of web frameworks in Java have the “I’m scared by the web”-syndrome, in which they try to get rid of CSS and mostly JavaScript, and replace it all with Java. Wicket is no different in that respect. In my opinion, if you’re scared of the web, don’t build a web interface.

As an aside, a colleague pointed me to the Play framework. It appears to be very much like Django, but then for Java and Scala. I’ve given it a go, and it looks very nice!

Back to Wicket: my dislikes, in no particular order:

Bad examples & documentation

The few examples that they provide on their page don’t compile. You have to tweak them yourself in order to get things running, and then there are still warnings left. For example, they use:

Form form = new Form("form");

but that gives me a warning that the Form class actually requires a type parameter, like Form<Object>. The example doesn’t tell me anything about what this parameter should be, and more importantly gives me no links to more information.

The documentation also leaves a lot of things undocumented. You’re referred to the source code to see if there are any more examples in there. This is fine for new projects where they haven’t had the time to write proper documentation. However, this project has existed since 2004, so they’ve had 7 years to get this right.

No clear request-response cycle

You can do a lot with the HTTP headers: authentication, content type negotiation, language negotiation, status codes, and more. But to use those, you need access to the request and response objects. With Wicket, these are hidden away somewhere.

When wicket was initially developed it was seen as advantageous that the HTTP model was hidden. SOAP was all the rage, which was designed to be transport layer transparent (you could do soap-over-SMTP if you wanted to).

Nowadays we tend to look at more lean protocols, such as JSON over HTTP in REST-style, and Wicket doesn’t appear to be suitable for that.

Template language is (X)HTML and very thin

The Wicket template language works by extending the HTML DTD with more tags. This limits you to templating HTML. What about JavaScript? I want to do something like this, but it obviously doesn’t work:

alert("Page title: <wicket:message key='page.title'></wicket:message>");

I’m much more in favour of the Django template engine, where you could write:

alert("Page title: {{ page.title }}");

With “very thin” I mean that all you have in your HTML is some element with a wicket:id attribute:

<div wicket:id='somepanel'>placeholder content</div>

The only thing you can do now to figure out what’s going to happen when that’s rendered, is to dive into the Java code. I’d like the ability to add custom templates, so that the template HTML is more descriptive, such as:

<mytags:slideshow>
  <img src='/image1.jpg' />
  <img src='/image2.jpg' />
</mytags:slideshow>

There also doesn’t seem any way to template anything that’s not an element, such as part of a string or an HTML attribute. In Django you could do:

<link rel='stylesheet' href='{{ base_path}}/style.css' type='text/css' />

without having to move the entire element to your Java code.

Multiple URLs for the same resource

If you don’t create an explicit “BookmarkablePage” object for each page, they’ll get the URL /page_you_were_before?wicket:bookmarkablePage=:java.classname (I leave out the https://hostname part).

The result is that pages can have multiple URLs. These are two URLs that lead to the same page:

• /page1?wicket:bookmarkablePage=:javapackage.Page3
• /page2?wicket:bookmarkablePage=:javapackage.Page3

The URL that’s used by Wicket will depend on whatever page you were on previously, breaking the “visited” colour for links and the simple idea that a resource should have one URL.

Overly complex

Some things are just too complex. Look at this example on how to create a link:

add(new PageLink("pageLink", new IPageLink() {
    public Page getPage() {
        return new NonBookmarkablePage(PageLinkPage.this);
    }
    public Class getPageIdentity() {
        return NonBookmarkablePage.class;
    }
}));

Granted, the result is that a link to the current page is not clickable, which increases usability, and that’s a Good Thing. Still, from a coding point of view it’s ridiculously complex, compared to something like <a href='/somepage.html'>link text</a>.

The good stuff

Sure, Wicket also has its good sides. The page inheritance model works quite well. And the links - once you get to implement them - are good too. As I wrote earlier, they don’t link to the page you’re actually on. The back button also keeps working, which is a rare thing in Java webapp land. And if Java is the only thing you’ll ever be interested in, but you still feel the need to write a web app, it may be very suitable for you.