What is Wicket?

Wicket is one of the most recent in a long line of Java web development frameworks and stands on the shoulders of many that have come before it. Wicket is a component-based framework, which puts it in stark contrast to some of the earlier solutions to the sometimes monotonous task of web programming. Like other frameworks, Wicket builds on top of Sun's servlet API; however, unlike frameworks like Struts or Spring MVC, the developer using Wicket is mostly removed from the request/response nature that is inherent with the web and Servlets. Instead of building controllers that must service many users and threads simultaneously, taking in requests, returning responses, and never storing any state, the Wicket developer thinks in terms of stateful components. Instead of creating a controller or action class, he or she creates a page, places components on it, and defines how each component reacts to user input.

This may all sound familiar to those with desktop GUI experience; Microsoft's Visual Studio line, Sun's Swing API, and Borland's Delphi are all popular desktop GUI development tools that use component models. Using components allows the developer to spend less time on the visual tier of his or her app and more time implementing the core functionality. Even more important is how extensible this makes component-based GUIs. Adding additional functionality is simply a matter of adding one more component, which can act independently or in cooperation with other components in the view. These advantages have not been lost on web developers. In fact, many web framework projects have attempted to leverage the productivity and scalability of desktop applications. Apache Jakarta's Tapestry and Microsoft's own ASP.NET as well as Sun's Java Server Faces specification all present solutions to component-based development over the web and bring new ideas to the table. All of these technologies separate the page layout into a template file. JSF uses Sun's JSPs, ASP.NET uses ASP, and Tapestry use's it's own templating system based on standard HTML markup. These pages are rendered on each request, and as they are rendering, they make calls into a backing class to support dynamic content. As much as the word "template" would seem to suggest otherwise, this makes the page template king. Backing classes tends to be a series of listener methods, at the total mercy of the page template that is supposed to be merely defining the placement of components.

This works fine, and it is definitely a step up from a model 2 controller singleton class. Instead of a giant if block, we have well defined methods. Instead of being stateless, we can have instance variables. But now our Java code is a second-class citizen, existing merely to provide the page with the information it needs while it renders itself. Also, this backing class is always aware of the request-response cycle. It knows that getMember() is going to be called on every request, and reacts accordingly by getting a fresh copy from the database. Sure, the developer needs to deal with these details, but does it really have to be dealt with at the very top level of the application? Wicket allows the developer to build a page in Java (you remember Java right? It's like OGNL, but with even more cool features) that uses and manipulates an HTML file, not the other way around. This page exists across requests, and does not even need to be aware of the request/response cycle. But something needs to know when a new request is starting and when the last one has finished rendering, right? All kinds of problems crop up when an object/relational mapper tries to work with an object from the last request, or the user is looking at an object that no longer represents what's actually in the database, or when you merely try to store all that data in the session. The solution here is to not make the page aware of all the request details, but the data itself. That's what Wicket tries to do.