Web development with Wicket, Part 1: The state of Wicket

Stateful? Stateless? Wicket accommodates both kinds of applications

Wicket is a lightweight, component-oriented framework that does much to bring the easy, intuitive interfaces found in desktop applications to Java Web development. In this series Nathan Hamblen introduces key aspects of Wicket that differentiate it from other Web application frameworks. If you're new to Wicket, this series will serve as an accessible and engaging introduction; if you're already using the framework you'll have fun with the well-crafted, hands-on exercises. This first article investigates Wicket's virtual state, demonstrating the many ways Wicket accommodates both stateless and stateful Web application development.

Wicket is a Java Web framework with an ambitious mission: supporting desktop-style application development for the Web. This goal has a two separate implications: not only should Wicket Web applications work as much like desktop apps as possible, but writing a Web app with Wicket should feel like writing a desktop app as well. Conceived and written by Jonathan Locke in 2004, the open source framework quickly attracted a cadre of contributors, steered itself towards Apache membership, and in 2007 became a top-level Apache project. Along the way, Wicket's feature set grew in two directions: better integration with the traditional Web of static resources and locators, and support for the dynamic new Web emerging in Ajax technologies. Wicket's judicious use of abstraction has allowed it to take on these divergent ends without entangling users in complexity.

This series is written for those starting out in Wicket -- or thinking about starting out -- with insights for experienced users as well. I'll explore the features that differentiate Wicket from other Java Web application frameworks, beginning in this article with the virtual application state that makes it all possible. How is stateful Wicket programming different from traditional Web programming? What are the advantages and disadvantages of stateful development, how is it best leveraged in an application, and how can it be eliminated if necessary? To answer these questions, we will walk through the creation of a stateful Wicket application, then mercilessly eliminate the application's server-side state, to see what we're left with.

Overview of the Wicket engine

In typical desktop GUI programming, visual components of interfaces are modeled by software components that have individual state. To mimic this style, a Web framework must maintain a virtual application state for every user of the application. Extensive server-side state of any kind runs contrary to some trends in Web programming -- those bound up in REST particularly -- but Wicket supports virtual state in such a way that the costs are minimized, the benefits are maximized, and the degree of server-side state maintained is entirely up to the programmer. While it may not be right for every Web app, it is certainly better than extensive ad hoc use of the Web session in applications that require it.

Because Wicket has always supported virtualized state and has been optimizing it over the course of several years, state management in version 1.3 of the framework is slightly more cryptic than in earlier versions, but also more efficient. When a user interacts with a stateful Wicket page, that page is retained in the server's memory as an instance of a WebPage subclass. The objects for previous pages that the user has visited have been serialized to disk (under the default configuration) and can be reloaded should the user request them. This is separate from page versioning, the mechanism that maintains state within a page, which is activated by logging changes made to the page's state. Don't worry if these points seem a bit dense; they will all take shape in the example application.

The page template

Sketching out the interface is a good place to start. Because this is a Wicket application you'll also be able to leverage all of the HTML from the sketch for the final runtime.

This article's sample application (you can download the source code from the Resources section) is a calculator that resembles those shipping with most operating systems, which in turn resemble those sitting on many physical desktops. The calculator will support basic operations through addition, subtraction, multiplication, and division buttons, as well as equals and clear buttons that operate in the traditional way. A text field will serve as the numeric input between operations, with a separate block for the display. Listing 1 shows the basic HTML, Figure 1 the rendering.

Listing 1. Calculator markup

<form>
  <div>
    0
  </div>
  <div>
    <input value="0" type="text" />
    <input value="=" type="submit" />
    <input value="c" type="submit" />
  </div><div>
    <input value="÷" type="submit" />
    <input value="×" type="submit" />
    <input value="-" type="submit" />
    <input value="+" type="submit" />
  </div>
</form>
Calculator rendering preview.
Figure 1. Calculator rendering preview (click to enlarge)

Notice that the code includes non-ASCII characters for some of the buttons. Modern Web browsers will have no problems displaying these labels. Furthermore, as long as the Wicket template begins with a correct encoding in the leading XML tag, these symbols will be read in and translated to whatever the request's output encoding is.

Now that you've laid out the interface the next step is to start binding it to executable code.

1 2 3 4 5 6 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more