Does Wicket need Ajax annotations?

The answer is no. At least not at this time. I am posting this because a user mentioned the new annotation support Tapestry has for Ajax and asked whether we have plans to support something similar.

Annotations are getting to be the next knee-jerk reaction for Java frameworks. Until recently, many framework authors used XML to save their poor users from writing actual code. Predictable, but it seems that annotations are being used in a similar fashion and steadily replace XML for doing the same things. With the difference that annotations are in your Java code, so you can still say you work with POJOs :).

For their particular problem Tapestry’s annotations are probably a good idea. After all, Tapestry works very different than Wicket does. But in general it seems that people are so used to program ‘declaratively’ that they forget that many problems can be solved by applying ‘just Java programming’. I remember the horrified exclamation two years ago from a director of Clockwork when I explained that Wicket was more like Swing than Struts+JSP: ‘what, no declarative programming?!’. Yeah, why use something simple that just works?

Back to the topic for something tangible, here is an example of Tapestry’s ajax annotation:

@EventListener(elements = "myFavoriteDiv", events = "onMouseOver")
public void watchText() {
  // do something

And here is Wicket’s variant:

myFavoriteDiv.add(new AjaxEventBehavior("onmouseover") {
  protected void onEvent(final AjaxRequestTarget target) {
    // do something

That annotation code doesn’t look bad at all, and neither does Wicket’s code. But Wicket code is better for a couple of reasons:

  • It doesn’t require Java 5.
  • It is easy to extend and customize. You can extend behaviors like any old class. It has nice baked in but overridable features like header contributions, attaching to the tags they are coupled to, a hook for exeption handing, state, etc. Whereas annotations have to be interpreted somewhere, are quite limited in the kind of parameters they can handle, can hold no state, etc, etc.
  • Wicket’s behaviors can easily be reused and even be shared accross components. Hide your customization in custom class, and all you have to do is something like myFavoriteDiv.add(new WatchText());
  • Classes generally refactor better than (string based) annotations and using classes it is easier to avoid the kind of code duplication you’ll likely end up with when using annotations.

Morale of this story? While annotations are a great new feature in Java, think twice whether you really need them. If you can solve something in a simpler, more traditional fashion, just go for that.

Update: not everyone agrees it seems, and we have an interesting discussion going on on the list.

Update 2: We played around with a prototype for attach/ detach/ beforeRender/ afterRender annotations. We ditched the idea again because it just wasn’t as straightforward as having overridable methods for that (onAttach/ onDetach/ onBeforeRender/ onAfterRender). Keeping things simple is usually the best idea!

About these ads

2 thoughts on “Does Wicket need Ajax annotations?

  1. Tim O'Brien says:

    OK, OK, I think that this argument has merit for the specific problem mentioned (ajax interaction), but I will have to say that @SpringBean has been very useful of late in my own work with Wicket.

  2. Yeah, I like the @SpringBean annotation too. But even this annotation has an underlying plain API so that the annotation is optional. For instance, there is an implementation that uses Jakarta Commons Attributes (written by Pro Wicket’s author Karthik Gurumurthy) but the spring mechanism could be implemented in any way you like really. That was kind of the point I was trying to make with this article. :)

Comments are closed.


Get every new post delivered to your Inbox.

%d bloggers like this: