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) {

super(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 {  @Override

  protected void respond(AjaxRequestTarget target) {

    // prevent wicket changing focus

    target.focusComponent(null);

  }  @Override

public void renderHead(IHeaderResponse response) {

    super.renderHead(response);

    response.renderOnLoadJavascript(

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

[update]
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() {
    super(Duration.minutes(10));
  }

  @Override
  protected void onTimer(AjaxRequestTarget target) {
    // prevent wicket changing focus
    target.focusComponent(null);
  }
}

Wicket In Action early access started

Yes, that’s right, you can finally start reading Wicket In Action! The first chapter can be downloaded for free. The third chapter is available when you sign up for the Manning Early Access Program (MEAP), and other chapters will follow shortly (chapter 2 and 4 hopefully next week).

It’s been quite a ride. We didn’t expect writing a book would be this hard/ take so much time. We hope it will help Wicket and it’s users. That’s ultimately the reason why we started this crazy adventure.

Wicket is now a top level Apache project

We are now officially graduated! Soon you can find as at http://wicket.apache.org.

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.

YUI’s datepicker from wicket-datetime localized

For anyone using the YUI date picker from wicket-datetime: in trunk (soon beta 3) it now uses localized months and days (of week). Support is as good as the JVM allows for (the code depends on DateFormatSymbols which seems to support many locales, but not nearly all available), but if you need, you can provide your own support (override the localize method and set the appropriate properties). To test and illustrate the localized datepicker, I added a separate example in wicket-examples (/dates, package ‘org.apache.wicket.examples.dates’).

There were two locales that didn’t look quite right to me. Hindi (India) rendered question marks all over the place, and Han Chinese looked like the days were all the same. Help with would be greatly appreciated!

Btw, I renamed ‘configureWidgetProperties’ to ‘configure’ and made the old method signature final. Sorry if that broke any of you, but as long as we’re in beta I like to break rather then deprecate .

Thanks to Gerolf Seitz for thinking with me and keeping on top of the datepicker and Al for fixing another potential render issue this week!