I’ve been working with Apache Wicket on a rather complex client project for quite some time now and I’d like to share my experience.
Apache Wicket is a component-based web app framework for Java. In contrast to MVC frameworks such as Rails (or Play and Grails in the Java world), which map requests to controller actions and views, Wicket is more similar to stateful GUI frameworks like Swing.
Wicket applications are made up of trees of components. Each Wicket page is a root node of a tree, to which an arbitary number of child components can be attached. Each of those components can in turn have child components, too.
Wicket automatically manages the session, current state and scope of the application on the server side, that is a Wicket developer will never directly interact with HTTP sessions. Rather, each component is bound to a Wicket-managed model that contains its current state.
Wicket uses plain XHTML as its templating system. Every Wicket component is bound to a corresponding HTML element with a specific wicket:id attribute. In order to make view code reusable Wicket allows you to create custom components called panels.
Generally, Wicket favours code reuse and convention-over-configuration. There’s not a single Wicket-specific config file, XML or otherwise.
Now, after I gave you an overview of Wicket’s design I’d like to outline my own findings:
- Wicket indeed is a light-weight framework. As far as component-based frameworks go, Wicket is among the easiest and most pleasant-to-use.
- For what kind of apps would you choose Wicket? For websites that mostly display content or only moderately complex web apps Wicket certainly is overkill. Wicket was designed for implementing fairly complex application logic and workflows. If you’re developing web apps on a Java stack for one reason or another I’d say Wicket is among the best choices you have nowadays. While I usually favour MVC frameworks like Play many enterprise environments require integration of multifarious services, interfaces, legacy databases and systems, which often doesn’t fit the clean approach of MVC frameworks too well. In such cases, Wicket is an excellent choice because it’s completely agnostic as to the other frameworks you use. It works well with Spring, Hibernate, EJBs and POJOs alike, for example.
- Given its component-oriented, tree-like structure and stateful nature Wicket isn’t exactly well-suited to RESTful design. It can be done but it’s not fun.
LoadableDetachableModelsright from the start. It will save you a lot from trouble later on.
LoadableDetachableModelsare key for scalability and managing your session size in Wicket
- Wicket’s strict XHTML validation can sometimes lead to problems with invalid HTML code in your templates. If for one reason or another you’re stuck with Wicket before version 6 you also might run into issues with some HTML5 code (all of which can be resolved or worked around, though).
- Wicket’s online documentation can be sketchy at times. The Wicket project has a wiki, which however doesn’t cover everything. The documentation has improved but if you have a very specific problem more often than not you’ll end up searching for a solution on Stack Overflow nonetheless. There are quite a few pretty good and comprehensive books on Wicket, though.
As is the case with most tools Wicket is no one-size-fits-all solution but it certainly is more than apt for many use cases, especially in enterprise environments. I’d very much like to hear your opinion on this.