Java Web Development the Wicket Way

he web application frameworks available today offer a wealth of development styles. Well-known web development technologies such as JavaServer Faces, ASP.NET, and the Google Web Toolkit use event-driven, component-oriented designs that resemble traditional GUI programming. This approach makes sense as web applications become more like desktop applications in sophistication and functionality all the time. However, many of these frameworks can be unwieldy, requiring heavy tool support and having steep learning curves. Also, the mingling of code and markup often challenges testability, refactoring, and separation of concerns. A Java web application framework called Wicket takes a lightweight approach to the component-oriented model to overcome these and other challenges.

At its core, Wicket is a Java framework for processing markup. It represents web applications, each page in them, and each component on each page as classes. Wicket then uses a simple naming convention to associate the classes responsible for dynamically manipulating markup with HTML files via the classpath. These files are truly just plain HTML—validating documents devoid of JavaServer Pages (JSP)-style "tag soup," and freely editable by designers. (Sidebar 1 explains how Wicket completely avoids control structures in markup.)

With markup processing as its base, Wicket extends to support all aspects of modern web application development by heavily and effectively using the composite and visitor patterns, as well as well-conceived inheritance hierarchies and interfaces.

Using test-driven design to develop a FileDropoff application example, this article illustrates Wicket's approach to testability, authentication and authorization, form handling, page nesting, file uploads with progress feedback, and the classic back-button problem. Throughout the development steps, the example highlights noteworthy pieces of code and describes what's going on behind the scenes. For all the details, download the source code and read along.

The FileDropoff use case reads as follows (see Figure 1 for a user workflow):

1. The user logs in.
2. The user enters some meta information about a file on page one.
3. The user uploads the file on page two.
4. The user may use the back button to make corrections to the meta information.

Figure 1. UML State Diagram for FileDropoff Application Example: This diagram shows user workflow for the FileDropoff application.