Monthly Archives: June 2007

Bought a new phone

I bought a new phone yesterday. Until then, I had still been using my Nokia 9300 with a Dutch subscription, but I finally decided it was time to get a phone in the US. And yeah, you guessed that right, it’s an iPhone. I was a little bit scared of what might be the waiting lines at first, as the media did an excellent job in hyping the hype. But after standing in line for about 50 minutes (I arrived at 5:40) I walked out with one. No problem.

It’s a very sweet toy. The screen is amazingly bright and sharp, and the touch screen works very well. And everything works very inituitive and fast. My expectations are by far exceeded – and they were high from the outset!

The key pad of my Nokia 9300 *does* work a bit faster; if you intend to use your PDA for word processing this might be a consideration for you. That said, the iPhone’s keypad works well enough for me (better than most phones I’ve tried), and I’m glad that the pad is out of the way when I don’t need it.

Here are two pictures comparing the Nokia 9300 and the iPhone.

photo-35.jpgNokia 9300 next to the iPhone - side

Wicket integrates with Guice

Al added a new project for integrating Wicket with Guice. Guice (pronounced as ‘juice’) is a very elegant, focussed Dependency Injection framework. Al beat me to it; it had been on my radar for while to build such an integration project, but I didn’t want to start before I had a good idea how to re-write the phonebook example.

Jean Baptiste seems to like Guice as well, as a couple of hours after Al’s commits, I saw than he and his collegue, Vincent Demay, were already working at converting their latest pet-project, PickWick, to use Guice. Btw, JBQ and Vincent, if you ever have big plans with that project, you might want to consider a name that is different from the largest tea brand of The Netherlands :)

Wicket is now a top level Apache project

We are now officially graduated! Soon you can find as at

I’d like to parrot Martijn, thanking the board, our mentors and ourselves for getting there. Hieperdepiep… hoera!

It’s all coming nicely together now: graduating, releasing 1.3 and entering MEAP with Wicket In Action all this summer.

We sometimes wonder how many people have installations with Wicket by now. Though there are a number of public ones we know of, like Thoof, Eventful, Vegas, Meetmoi, Zoomf, Sell@Market, Genietown, B-Side, Voicetribe, Datawink, Trackdetective, and a couple of sites with difficult names :), and we know of a couple of open source projects that use or build on Wicket, like Pax Wicket, Webical, Artifactory, JTrac, Tally-ho, Irrigator, Burgerweeshuis and Papernapkin’s pastebin, I expect most sites using Wicket to be intranet sites. That is just because it is my uneducated guess that about 80% of the webapps produced today are internal systems rather than public facing. I also expect that we only learn of a fraction of the web applications built with Wicket. I base that on the fact that I’ve been using many open source projects over the years, and rarely have signed up for their mailing lists or otherwise let people know I was using their project, and also because I have spoken to quite a few people during the last year who did not list their projects on the Wiki, but told me they were already doing their 3rd or 4rd project with Wicket.

Anyway, even if we don’t really know how well our real ‘penetration’ is, it is great to see that since the start, downloads and subscribers only have been growing, and that there is hardly any negative publicity on the framework. And that actually surprises me. There are so many choices to make in software development, that you’ll always have loads of people who think you’re doing it all wrong.

Another thing that is great is that even Wicket 1.2, our current stable release, works well for so many people. Our next release, Wicket 1.3, of which we hope to release the second beta this weekend, is a lot better than it’s predecessor in almost every aspect. I won’t go into detail here, but please, this weekend: download it and try it for yourself! Or download a snapshot from our repository of course.

How to locate where Wicket markup comes from your browser’s source view

Sometimes, Wicket’s dynamic component structures makes it a bit hard to figure out what on your page comes from where. Not anymore. Matej recently implemented a little but very helpful debugging aid for this in Wicket. You can turn this feature on by putting this:

protected void init() {

in your application class. Or, let it depend on a system setting you pass in your debug environment:

  try {
  } catch (SecurityException e) {
    // nevermind

so that it’s only turned on when you explicitly tell it to be turned on.

If you have this setting turned on, and you look at the sources of pages in your web browser, you’ll see fragments like this:

<!-- MARKUP FOR$3 END -->
  <span><!-- MARKUP FOR BEGIN -->
    <img src="/foo/bar.gif" />
    <table >

Say, you want to locate where that crazy foo/bar image comes from, you now know that it is rendered by, and that you can find that piece of markup in PodBorder.html or the markup associated to a parent higher up in the hierarchy.

Writing a Wicket and Hibernate application in Scala

Java is not doomed—Myths EXPOSED! ;)

Scala looks great. I’m not as disillusioned with Java as some people seem to be, but I do regularly bump my head against it’s limitations, and often wish for being able to express the same things in a more compact fashion. Scala looks like a language to love. Compact, type-safe and fully interoperable with Java.

How to create a text area with a heart beat with Wicket

Say that in general your session time out works fine for you, but you have a couple of screens where you expect that users might hang around a bit longer than that. For instance on a page where people can submit their Resumes.

A good solution is to do what gmail or wordpress do: save drafts for your user and enable them to go on with these drafts at a later stage. If your session gets expired or you lose your browser or something, at least your user won’t have lost everything.

What you can also do, as an alternative or in addition to, is create a component that pings back to the server every once in a while to keep the session alive. Here is how you could do that.

The component we’ll be creating is a custom text area; that’s probably where you will need it for anyway.

public class KeepAliveTextArea extends TextArea {
    public KeepAliveTextArea(String id) {
      add(new KeepAliveBehavior());

    public KeepAliveTextArea(String id, IModel model) {
      super(id, model);
      add(new KeepAliveBehavior());

That’s the start. We just extend TextArea and override it’s two constructors. Those constructors in turn add a behavior that does the real work:

private static class KeepAliveBehavior extends AbstractDefaultAjaxBehavior {

  protected void respond(AjaxRequestTarget target) {
    // prevent wicket changing focus
  }  @Override

  public void renderHead(IHeaderResponse response) {
      "setInterval(function() { " +
      "  wicketAjaxGet('" + getCallbackUrl() + "', null, null, null); " +
      "}, 600000);");

If you are familiar with Wicket, you probably already know that behaviors are a great way to extend the capabilities of components using composition rather than inheritance.

The first purpose of this Ajax behavior is to be a bucket for calls, which are received through the respond event method. Receiving a call will be enough for the application server to reset the session time out counter, which is the thing we’re after here.

Then, the Ajax behavior does a header contribution in the body of overridable method renderHead. It calls renderOnLoadJavascript on the header response, which will make Wicket register a script that is to be executed right after the page is loaded. The script creates a loop that calls wicketAjaxGet every ten minutes (600,000 miliseconds). That wicketAjaxGet function comes from Wicket’s standard Ajax support, which is automatically available for anything that extends AbstractDefaultAjaxBehavior or it’s subclasses.

The last interesting thing to note here is the call:getCallbackUrl()
This gives the URL to the Ajax behavior itself. This is what the loop calls every ten minutes,, and it results in the respond method being called on the behavior.

Al is right, it’s much easier to just extend AbstractAjaxTimerBehavior for this. I ripped the code for this post from a component that was doing much more than this, and in simplifying that, I didn’t think about the last step. Anyway, here it is, and using Duration makes it much nicer as well.

private static class KeepAliveBehavior extends AbstractAjaxTimerBehavior {
  public KeepAliveBehavior() {

  protected void onTimer(AjaxRequestTarget target) {
    // prevent wicket changing focus

Configuring Wicket with Terracotta got even easier

For those of you following Terracotta, it’s old news. But configuring Wicket to be used with Terracotta is as easy as putting this in your Terracotta configuration:

      <module name="clustered-wicket-1.3" version="1.0.0"/>

You’ll have to configure the configuration bits of your own application yourself of course. But here is a tip: if you let classes that your components reference over requests (thus what should be available in the cluster) implement interface org.apache.wicket.IClusterable, those classes should automatically be recognized by Terracotta. For those classes which you don’t want to pollute with the Wicket name space, just configure it like you would normally do with Terracotta.

Mind you that there is currently an open issue with the Wicket module. But it might already be solved by the time you read this.

Grails releases 0.5.5 and adds Wicket support

Grails just released their 0.5.5 release. I have never played with Grails myself, but I hope I get bonus points for having a book about it :)

It is interesting Grails supports Wicket as a plugin. There is a big warning on the plugin page that says it doesn’t work with the Grails URL mapping mechanism. Wicket’s URL resolving mechanism is pretty flexible and much improved in Wicket 1.3. So it must that someone just has to put the effort in it to make it work with Grails, and/ or the plugin should be upgraded to Wicket 1.3 (I think it uses 1.2 now).

It would be interesting to learn who is using Grails + Wicket. Drop me a line if you are!

Thoof’s first steps out in the open

Yesterday I got an email telling me I could start playing around with Thoof, the project Jonathan has been working on the last couple of months. It already got a couple of reviews, of which the one on VentureBeat was imho the most interesting, as it talks about the technology aspects rather then just the business side.

If I understand it correctly, Thoof tries to do news ranking according to your preferences, not someone else’s. It tries to learn what you like by tracking how you use Thoof, recording things like where you came from, what articles you click on and what you search for. This by itself is interesting enough to give it a try and see how it works. But on top of that, Thoof is build using Wicket, which is of course an extra reason to check it out! :)

Getting Wicket In Action ready for MEAP

Pfew, it’s been forever since we started writing Wicket In Action. It has been, well… a bumpy road. Let me not complain too much, but just state that having a demanding full time job, supporting a popular web framework, moving to another country, visiting conferences, preperaring a wedding, having a life AND writing a book is quite the load.

Anyway, we are finally getting up to a point where much of the content is written, and we are about to enter the Manning Early Access Program (MEAP). The first chapters should be available in a matter of weeks now. Exiting but very, very scary!

UPDATE: Wicket In Action is now available here!


Get every new post delivered to your Inbox.