Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

After the 5 Days of Wicket: Upgrading to Wicket 1.4

DZone's Guide to

After the 5 Days of Wicket: Upgrading to Wicket 1.4

· Java Zone ·
Free Resource

Verify, standardize, and correct the Big 4 + more– name, email, phone and global addresses – try our Data Quality APIs now at Melissa Developer Portal!

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:

<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:

<context-param>
<param-name>configuration</param-name>
<param-value>DEPLOYMENT</param-value>
</context-param>

becomes

<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:

   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: 

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:

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:

   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! 

From http://www.mysticcoders.com/blog

Developers! Quickly and easily gain access to the tools and information you need! Explore, test and combine our data quality APIs at Melissa Developer Portal – home to tools that save time and boost revenue. Our APIs verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – to ensure accurate delivery, prevent blacklisting and identify risks in real-time.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}