If you follow anything about Wicket, you know that they just released Wicket 1.4 which offers some very nice improvements and structural changes that make it even more awesome of a framework to work with. Back in March of this year we brought you 5 Days of Wicket, so in today’s post we upgrade the sample application which is available online at MysticPaste.com to 1.4.

Dependency Changes

First thing’s first, use Maven, it’s just going to make life a whole lot easier to deal with. Since the sample application utilized Spring, I’ll also include the changes you should make in your pom.xml file for 1.4:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<dependency>
     <groupId>org.apache.wicket</groupId>
     <artifactId>wicket</artifactId>
     <version>1.4.0</version>
</dependency>
<dependency>
     <groupId>org.apache.wicket</groupId>
     <artifactId>wicket-ioc</artifactId>
     <version>1.4.0</version>
</dependency>
<dependency>
     <groupId>org.apache.wicket</groupId>
     <artifactId>wicket-spring</artifactId>
     <version>1.4.0</version>
</dependency>

The library wicket-spring-annot has been deprecated in favor of wicket-ioc and wicket-spring, and simply modifying the version to 1.4.0 for all wicket-core artifacts should do the trick.

Configuration

While this may not cover every case, the only configuration item that was required for us was to change the context-param defining the development/deployment mode:

1
2
3
4
<context-param>
   <param-name>configuration</param-name>
   <param-value>DEPLOYMENT</param-value>
</context-param>

becomes

1
2
3
4
<context-param>
   <param-name>wicket.configuration</param-name>
   <param-value>DEPLOYMENT</param-value>
</context-param>

Deprecations ... fare thee well old friends

In the examples, we use HeaderContributor to references a few CSS files and this has been deprecated in favor of:

1
2
3
   add(JavascriptPackageResource.getHeaderContribution(MYPAGE_JS));

   add(CSSPackageResource.getHeaderContribution(MYPAGE_CSS));

We also utilized the simple DefaultDataProvider for our DataView on the history page, and this too has been axed. Our solution for this was to just implement IDataProvider ourselves:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class HistoryDataProvider implements IDataProvider<PasteItem> {
    ...

    public Iterator<PasteItem> iterator(int first, int count) {
        try {
            return pasteService.getLatestItems("web", count, first, false).iterator();
        } catch (InvalidClientException e) {
            e.printStackTrace();
        }
        return null;
    }

    public IModel<PasteItem> model(PasteItem pasteItem) {
        return new Model<PasteItem>(pasteItem);
    }

    /**
     * @see org.apache.wicket.model.IDetachable#detach()
     */
    public void detach() {
    }
}

As with a lot of the framework in 1.4, things have been generified, so instead of casting everywhere, you just generify everywhere =).

Component Changes

With Link, you can pass in a Model, and BookmarkablePageLink extends from Link, so if you want your code nice and clean, since it doesn’t need it:

1
BookmarkablePageLink<Void> myLink = new BookmarkablePageLink<Void>("myWicketId", MyWicketPage.class);

Component has also changed, and they have removed the .setModel and .getModel methods in favor of .getDefaultModel and .setDefaultModel. My understanding is that because IModel was generified, suddenly all components had to be generified, and that would have sucked. For more info on this Wicket’s wiki page on Migrating to Wicket 1.4. Here are a few examples of blocks from the sample app that we modified to support generics:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
   add(new CheckBox("twitter", new PropertyModel<Boolean>(PasteForm.this, "twitter")));

   ...

   add(new TextField<String>("email", new PropertyModel<String>(PasteItemPage.this, "spamEmail")));

   ...

   markAbuseLabel.setDefaultModel(new Model<String>("Marked As Spam"));

   ...

   CommentListModel commentListModel = new CommentListModel(pasteModel.getObject().getId());
   final ListView<PasteComment> commentList = new ListView<PasteComment>("commentList", commentListModel) {
       @Override
       protected void populateItem(final ListItem<PasteComment> item) {         

    ...

    RequiredTextField<String> commentEmail = new RequiredTextField<String>("email");

Overall and throughout the code, things seem a bit cleaner, and more pleasant to work with. If you’d like to take a more in-depth look at the code, you can browse it on our Kenai project page. As always we welcome any comments, and if we’ve made a boo-boo in our conversion, please let us know. All told it took about 30 minutes to convert the codebase, and since it’s small, that makes sense. If you need more details, please check the ever evolving Wicket migration to 1.4 on the Wiki.

Happy coding!

The Wicket folks have released the latest incarnation of the framework in Apache Wicket 1.4. Notable improvements are:

• Generified IModel interface and implementations increasing type safety in your Wicket applications
• Component#getModel() and Component#setModel() have been renamed to getDefaultModel() and setDefaultModel() to better support generified models
• The Spring modules have been merged (wicket-spring-annot is now obsolete, all you need is wicket-spring)
• Many API's have been altered to better work with Java 5's idioms
• Wicket jars are now packaged with metadata that makes them OSGI bundles

What are you waiting for? Go get it!

In Java land, we’ve become very familiar with jarhell, and the associated pain of trying to find every jar required for let’s say Hibernate. The pain involved in this process is greatly reduced by the use of something like Maven, and while the initial learning curve sucks, you get into a groove with it. What about Wicket?

Here’s the dependencies you would need to fulfill, all two of them:

1
2
3
4
5
6
7
8
9
10
        <dependency>
            <groupId>org.apache.wicket</groupId>
            <artifactId>wicket</artifactId>
            <version>1.3.6</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-jcl</artifactId>
            <version>1.4.2</version>
        </dependency>