have been reading the buzz about the Apache Wicket
web application framework for a while, but didn't decide to seriously learn Wicket until just a few months ago. I had just finished experimenting with the Java Persistence API
(JPA), and decided to repurpose some of the code into a web application for managing bugs
. Yes, there are many bug-tracking applications out there, Bugzilla, Jira, and all their cousins, but none compared to the thrill of rolling my own.
Just as I finished writing up the basic bug-tracking functionality to my satisfaction, along comes a new version of Wicket, 1.4-M1, a milestone on the way to 1.4. Of course I had to try it. This article walks you through my experience. Follow along to learn how to utilize some useful new features slated for Wicket 1.4.
Move to Java 5
Wicket 1.4 is Java 5 only. So open up your Maven project's pom.xml file, and make sure that the source code is Java 5 compliant. You can add the following compiler customization to the plugins part of the build section in the pom.xml:
Once you recompile successfully with this compiler customization, you have taken the first baby-step to using Wicket 1.4.
Next, fire up Eclipse and make the corresponding changes to your Wicket project to get Eclipse to recognize Java 5 code. This is necessary because you will be using generics and other fun Java 5 stuff, as well as getting rid of ugly casts.
Now, get ready to step out onto the bleeding edge. Instead of using Wicket 1.4-M1, use the nightly snapshots. To do this, use the Apache snapshot repositories by adding the following lines to your pom.xml:
Next, change the version of Wicket in your pom.xml to 1.4-SNAPSHOT and recompile. Knock on wood and hope the build works.
Fire up Eclipse again and get ready to use generics. I have the sonatype plugin installed, because it allows me to use the pom.xml to manage my dependencies from within Eclipse. The sonatype plugin also allows me to download the source code for all the open source projects that I use. Have Wicket's source code handy, in case you need to get into it while debugging.
Make Everything Generic
The most interesting change to Wicket in 1.4 that models use generics. So you do not have to cast to get back your model object. All components are "templated," including panels, links, images, forms, form components such as labels, text boxes, and drop-down choices, and so on. However, it is a good idea to start cautiously. I like to have my code in source code control, in case I do something stupid and need to revert.
Start with the web application and session classes and see if these need any changes. I used AuthenticatedWebSession and noticed that it had a deprecated constructor that I had to change. Next, carefully start updating your models to use templates. The template type should be your model object's class. In my bug-tracking application, this was usually my Bug class. The trick is to make a small change, test it thoroughly, and then check it back into source control.
After updating all your models, move on to forms and form elements. All your textboxes and drop-down lists can be specialized using generics. Forms themselves can be specialized by the model object they represent. My links usually do not have models associated with them, so I specialize them with the Java Void class. As you start using generics, you will notice that your code will become a lot less verbose. This is because most of your casts are redundant. Eclipse will point those out to youand will even remove them if you use the code clean-up feature.
For some reason, the PropertyColumn on a data table is still not generic. A PropertyColumn is really useful when all you want to do is display an object's property in a table. I am sure that the Wicket team will take care of this before 1.4 is released, but until then, you can create your own substitute class that works equally well, or borrow mine: ModelPropertyColumn (see Listing 1).