2008 has started with a bang... Wicket 1.3 has been released. In his blog , Martijn Dashorst (pictured right), chairman of the project and a senior software developer at Web application development firm Topicus, has announced and outlined the features of the new release. (The Wicket Homepage also lists all the new 1.3 features.) The 1.3 release sees Wicket moving from SourceForge to Apache, together with a host of new features and improvements. To introduce them to us, we talk to Martijn himself.

Martijn, first, can you quickly tell us what Wicket is?

Apache Wicket is an open source web framework. Wicket aims to simplify developing web applications in Java by providing a first class component-oriented programming model, similar to JSF and .Net. Wicket components consist of just Java and HTML.

Wicket's HTML templates are devoid of template logic: all markup manipulation is performed in Java code. This enforces a strong separation of concerns: HTML can be crafted by designers, the backing logic by Java developers.

But Apache Wicket is more than just a framework. Adopting Wicket will not only give you a compelling web framework, but also one of the most supportive and active Java communities. We are very fortunate that such a positive community has surrounded our framework.

Why and how did you become an Apache project in the first place? What are the gains for the end user? And for you and the other project owners?

We were looking for a new home in 2006 after several outages on the SourceForge infrastructure and excessive spam on the mailing lists. When we started discussing our future, Apache Member Alex Karasulu asked us whether we wanted to join Apache and, after some initial fears, we became convinced it would be in the best interest of both Wicket and Apache that we should join forces.

Wicket would be joining one of the best and most friendly open source communities around, and Apache would gain yet another, but very fast growing, Java web framework. The Wicket community was already open and meritocracy-based, so the match in culture already existed.

For Wicket users, the move to Apache will mean more continuity in the development and support of Wicket. The Apache foundation is very good at fostering sustainable, diverse and open communities.

Another benefit is that the Apache license is very business friendly. We have cleaned up our code base to remove non-Apache compatible code. So it is safe to build your business on, if you care about licensing.

The biggest difference between Apache and SourceForge, though, is that Apache is a community, while SourceForge is a hosting provider with no community aspects (apart from the annual awards ceremony). I never gave that much thought, but attending ApacheCon really opened my eyes as to what "Community" actually means.

Another thing that struck me is that since we became part of Apache, the number of job listings increased dramatically. So the Apache brand is really helpful for adoption of the framework, and I expect to see considerable growth going forward.

There are also some downsides to becoming part of Apache. We were almost a top 10 project at SourceForge, and we had pretty good insight in the number of downloads, though with the increased usage of Maven, that was already a skewed statistic. Due to the nature of Apache's mirroring system we can't reliably count downloads at the moment.

Being part of Apache also gave the advantage of sharing infrastructure. Running your own infrastructure is no picnic and we are glad that the infra team at Apache is taking good care of that. To me, one of the biggest advantages of the Apache infrastructure is that the amount of spam messages has gone down to 0 on our lists (though we have to moderate some of it).

Now, Wicket 1.3 has just been released. Can you give us a rundown of the highlights?

Now that we are an official Apache project, we have sifted through the code and removed all of it that isn't compatible with the Apache License. The code base is now fully Apache License compatible. For instance, we replaced the old JavaScript date picker component (which was LGPL licensed) with the YUI calendar (which is BSD licensed).

Moving to Apache also required us to rename our packages to "org.apache.wicket", so start your auto-import refactoring tool to update the Wicket imports!

Plus, we switched our logging implementation from commons-logging to slf4j.

There have been simplifications in several areas. The models API (the glue between Wicket components and domain objects) has been simplified and is now considered stable (though we will be applying generics in the next release). The converter API (for converting between request parameters and domain values) has been simplified and is now considered stable. The validators API (for validating form input) has been simplified, and decoupled from form components to make them usable outside Wicket.

The number of callback methods for the request processing has been reduced: a lot of cluttered internal methods (onInternalAttach, onInternalBeforeRender) and the odd callback method have been removed (e.g. Component#onAttach).

We have added support for Google Guice, the alternative dependency injection framework.

We now provide a filter implementation for Wicket applications to improve serving non-Wicket content, and have Wicket applications run from the root of the web application context. The old servlet is still supported though (and necessary for some application servers that won't work with the filter).

Wicket's portlet support now provides a way to use your Wicket pages directly in portal containers as portlets, without having to write additional code, or maintain a separate hierarchy. Ate Douma has presented this (much) improved support on the Wicket community meetup in Amsterdam and demonstrated Wicket's examples running in a JetSpeed portal.

Wicket's URL mounting (used to create REST-like URL's to pages) received a great addition with the HybridUrlCodingStrategy. The mount point is preserved even after invoking listener interfaces (thus you don't lose bookmarkability after clicking links) and that for AJAX only pages the state is preserved on refresh. This enables links like these:

http://example.com/mount/path/param1/value1

http://example.com/mount/path/param1/value1.3

If you want to learn more about the changes for migrating your existing application, we have a migration guide .

Can you share some code snippets to highlight how things were done before and how they're done now?

As an example of the model API changes, let's implement a link that performs some action on a person:

add(new Link("save", new Model(person)) {
    public void onClick() {
        Person p = (Person)getModel().getObject(null);
        p.save();
    }
});

The getModel().getObject(null) will retrieve the person from the link component. The null parameter is typed as a Component and confused a lot of beginning Wicket programmers as to its purpose. Therefore we removed that parameter, and the code becomes as follows:

add(new Link("save", new Model(person)) {
    public void onClick() {
        Person p = (Person)getModel().getObject();
        p.save();
    }
});

In doing so, we also pruned the model hierarchy from rarely used classes.

Injecting your components with Spring services is achieved by annotating your service with @SpringBean at the location where you want it to be injected:

public class SpringApplication extends Application
{
	@Override
	protected void init()
	{
		addComponentInstantiationListener(new SpringComponentInjector(this));
	}
 
	/**
	 * @see org.apache.wicket.Application#getHomePage()
	 */
	public Class getHomePage()
	{
		return HomePage.class;
	}
}
 
public class HomePage extends WebPage {
    @SpringBean IMyService service;
 
    public MyPage() {
        Person p = service.getPerson(123);
        add(new Label("name", p.getName()))
    }
}

The guice integration is strikingly similar:

public class GuiceApplication extends Application
{
	@Override
	protected void init()
	{
		addComponentInstantiationListener(new GuiceComponentInjector(this));
	}
 
	/**
	 * @see org.apache.wicket.Application#getHomePage()
	 */
	public Class getHomePage()
	{
		return HomePage.class;
	}
}
 
public class HomePage extends WebPage {
    @Inject IMyService service;
 
    public MyPage() {
        Person p = service.getPerson(123);
        add(new Label("name", p.getName()))
    }
}

What are your two personal favorite enhancements/changes in this release?

The simplifications done to the API's. They make developing Wicket applications much simpler. I also like the fact that those API's are now pretty much stable (the models, converter and validation API's). I don't see much that can be improved in those interfaces, apart from adopting Java 5 generics.

The hybrid URL encoding in Wicket 1.3 is really great. thoof.com , for instance, uses it on their site.

Wicket has seen a rapidly growing level of adoption. Can you give us some statistics to illustrate this?

Since we joined Apache, job listings for Wicket have gone up exponentially (though in absolute terms it is still low), and actually go against the trend where demand for Java and .Net developers is languishing (last quarter of 2007 shows a serious decline in demand for Java/JSF developers ).

E-mail traffic on our mailing list is also one of the highest in the Java landscape. According to the archives at Nabble ( here and here ), we are ranked above all other web frameworks, are the top project at Apache, and only have NetBeans and java.net (two very large umbrella projects) above us.

Our IRC channel is constantly populated with ~60 folks.

And finally there are a lot of community efforts erupting across the world. San Francisco enjoyed a Wicket community meeting, London has an event each month and last November we had a very well attended Wicket meeting in Amsterdam, attended by >80 people from the Netherlands, Belgium and Germany.

You also have a book coming out. But there are also other books about Wicket, right? How does yours differ to those?

Wicket in Action is written by two core members (Eelco and myself) who have been involved with Wicket from the start, so you get the knowledge straight from the source. Wicket in Action targets Wicket 1.3, whereas the currently available book ( Pro Wicket ) targets Wicket 1.2.

Wicket in Action is published by Manning, a publisher that is known for authoritative and high quality books enabling developers to become highly productive. The editing process Eelco and I have to endure is tough, but ultimately will benefit our readers... and it shows. Early reviews coming from the Early Access program are very positive.

By the way, there is another book being written by Kent Tong, author of "Enjoying Web Development with Tapestry", which is aptly named "Enjoying Web Development with Wicket". I haven't read it, but from the snippets I have seen, it is the same as his Tapestry book, but then implemented using Wicket.

What can we expect from Wicket, going forward?

The next version of Wicket will break away from JDK 1.4 and be based completely on Java 5. We will introduce type-safe models by generifying them. This makes, for instance, constructing a DropDownChoice component easier. Currently the constructor reads as follows:

DropDownChoice(String, IModel model, IModel choices)

This confuses developers because you can't see what needs to go into those models (especially when you don't have the source or Javadoc attached to your project.) However, using generics will make it clearer, even without Javadoc and source:

DropDownChoice(String id, IModel<T> model, IModel<List<T>> choices)

Here it is much clearer what needs to go where.

Probably one of the bigger API breaks will be the change of IDataProvider's size() return type: it will align with the JPA standard of returning a long instead of an integer.

One other thing that will receive some attention is the testing side of Wicket. We currently have a very capable framework to test your Wicket components in isolation and exercise your pages. But with Java 5, we can really make the API work nicely. We are looking at utilizing a JUnit 4/Hamcrest type of assertions. We're also keeping an eye on JDave (a Behavioral Driven Development test framework) and might steal some ideas from that framework as well.

Other ideas that we might adopt are a security sub project (integrating Wicket Swarm/Wasp, currently hosted at sourceforge), possibly integrate a JavaScript animation framework into the core (or extensions) to make rich application development with basic Wicket components much easier. The full list of wishes for 1.4 can be found here .

If anyone wants to suggest new avenues of development, they are welcome to discuss them on our development list, or propose them on our Wicket 1.4 wish list.

public class MySuperclass
{
  private void method1()
  {
    superMethod();
    subMethod();
  }
 
  private void superMethod()
  {
    // cannot be overriden
  }
 
  protected void subMethod()
  {
    // subclasses can override this
  }
}