Beta eBook Pro Wicket available

18 08 2006

I just bought the beta eBook edition of upcomming ‘Pro Wicket’ from Apress which has recently been made available.

I’m glad we’re having our first real Wicket book available now. And the book looks good. Karthik Gurumurthy has a compact style of writing which basically cuts the crap and let’s you get up to speed with Wicket quickly. But it is more than just a how-to guide; Karthik goes through the effort of explaining alternatives and explains how things are done by Wicket instead of merely giving you the steps to get a task done.

Martijn and I are still working whenever we can on Wicket In Action. It’s hard to have a full time job, be one of the core members of Wicket and write the book. But we’re working on it, and we are steadily progressing towards our 2/3 deadline.





Added Persian to FormInput example

1 08 2006

Thanks to Iman Rahmatizadeh, the Wicket examples project now has it’s FormInput example extended with a Persian (Farsi) language example.

FormInput Persian





Does Wicket need Ajax annotations?

1 08 2006

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!