Mystic Coders, LLC has been coding web magic since 2000. Mystic is a full-service Development Agency specializing in Enterprise development with Java. They are usually involved in developing enterprise-grade software for companies large and small, and have experience working in diverse industries, including b2b, b2c, and government-based projects. Mystic has done work with large companies such as LeapFrog, Nestlé, Harrah's Entertainment and the Los Angeles Conventions & Visitor's Bureau, among others. Andrew Lombardi, CTO of Mystic, is available for speaking engagements. Andrew has posted 2 posts at DZone. View Full User Profile

After the 5 Days of Wicket: Upgrading to Wicket 1.4

08.03.2009
| 6183 views |
  • submit to reddit
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

Published at DZone with permission of its author, Andrew Lombardi.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Frank Silbermann replied on Tue, 2009/08/04 - 10:10am

I didn't see anything about the loss of DefaultDataProvider in the migration guide (http://cwiki.apache.org/WICKET/migrate-14.html).  What else are they not telling us?

 

Also, with regard to your component changes, could you show us what you had before so we don't have to search through the old article to compare with your  new code?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.