Developing with Apache Wicket

Home » Blog » Software » Enterprise Software » Developing with Apache Wicket

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.
  • Use LoadableDetachableModels right from the start. It will save you a lot from trouble later on. LoadableDetachableModels are 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 hides most JavaScript and specifically AJAX code from developer, that is the required behaviour is added to a component and Wicket automatically generates the corresponding JavaScript code. While many Java developers seem to like this because they only have to deal with Java code and don’t have to touch JavaScript, I’m not particularly fond of this approach. I like JavaScript very much and coding in JavaScript for me feels so much faster and natural than tinkering with Java code. That said, Wicket’s approach is certainly much better than the one of Google Web Toolkit, which is horribly complex, to say the least.
  • The previous point also implies that Wicket isn’t exactly suitable for working with front end MVC frameworks such as Backbone.js or AngularJS. You’ve to be very careful when extending or modifying Wicket components with your own JavaScript code since you might mess up Wicket’s own behaviours. Once again, it can be done but you’ll most likely be better off with frameworks like Rails or node.js in that case.
  • 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.

About the author: Bjoern
Independent IT consultant, entrepreneur
  1. RSWRCRSRSdfs January 28, 2013 at 11:22 pm

    Well, coming from an PHP background i work now for 8 months in Wicket and my feeling are very mixed. The learning curve is immense. Simple things like implementing RadioGroups are extremly complicated. Why do we have to explicitly set wantOnSelectionChangedNotifications set to true? Why there is no AjaxRadio? We often end up googling, trying, looking into Ctrl+Space to see if there is a method we could use. Often you use a class like for example FormComponentUpdatingBehavior and add 4 of them to one Component only to find out two days later that there is something like OnChangeAjaxBehavior. You need an checkbox – you use the checkbox class. You need Ajax Behavior – you add a behavior. Only to find out 2 weeks later that there is an AjaxCheckBox. You want to render some Javascipt on every panel render – what to u use? target.appendJavascript? You override renderHead() in the panel only to add a JavaScriptContentHeaderItem, JavaScriptHeaderItem, JavaScriptReferenceHeaderItem, JavaScriptResourceReference or JavaScriptUrlReferenceHeaderItem?
    Models? You have to use models, pass them to panel, cascade them. They are essentials, use models everywhere or you run in trouble. The best you can do is use everwhere LoadableDetachableModels. Problem is: you dont have to use models. You write your constructor, you pass POJOs and i works. No one cares. Half of our app works like this. By works i mean works. So are models mandatory or not? And if yes why arent we are forced to use Models?
    In wicket you can almost forget writing your own JavaScript. You have to write JavaScript through Wicket if you want to avoid trouble.
    I love behaviors and IEvent. Add 3 behaviors to a component , send 3 events to getPage() and try to understand what your app is doing.

    Dont get me wrong: i like Wicket. It is often fun to work with it. It is powerful – no question. Out of the box AJAX is great. But it is inconsistent, often simple things which you would do in PHP or similar languages just and they work, you cant do here. You must do them complicated. You end up with slow development speed. If you have time Wicket is ok. If you want to do something fast – forget about Wicket unless you are on of the few chosen One’s.

    • Bjoern January 29, 2013 at 1:50 am

      While I agree with some of your points there are a few aspects worth noting. If I wanted to create a new web application I’d most likely not choose Wicket over Rails (or some PHP framework for that matter). In fact, I’d most likely not even consider any Java framework as an option.
      However, if you have to rewrite or build upon an existing Java application – especially if this application interfaces with a lot of other systems – Wicket most likely is among the best choices you have. It also allows to deal with growing complexity pretty easily. Refactoring with Wicket is a breeze.

      Wicket can become quite complex when you need to digress from the default behaviour, this is mostly due to its component-based design, it’s not inherently bad but it takes some time getting used to. Additionally, Java isn’t exactly known for being the most concise language.

      As for writing your own JavaScript, like I said it can be done but you have to be careful. Using class selectors with jQuery for instance is a great way for extending Wicket components without getting in their way.

      Finally, Wicket can indeed be quite inconsistent at times and lacks more complete documentation. However, I think the Wicket team is aware of this and has tried to improve on that matter with the latest release.

  2. Rich Livingstone March 31, 2015 at 6:36 pm

    I’ve been developing with Wicket for quite a few years so I’m perhaps a bit biased but I’ve found it a nice platform for reuse and refactoring and can be adapted to do pretty complex AJAX/JS activities. However, I’d agree that the learning curve is pretty steep; I’m still finding out about new stuff after 10 years which I’ve just found a need for. One big plus for Wicket is the number of third party products it can integrate with – I use JQuery, Highcharts, Logback, EJBs, Hibernate, Jamon, Paypal, BouncyCastle, OAuth and more.

    Having said that, syntax aside, complex stuff in a large scale system is never going to be easy – I’d be amazed if my latest project was any easier in node.js than Wicket.

    My conclusion after about 30 years in software development is that there is no silver bullet, folks – small scale solutions can always be hacked out quickly but large scale, maintainable systems need structure, reusability and performance applied at the crucial points, plus obviously, providing the functionality for the development in question. The choice of framework or platform to use is a function of these.

Leave a Comment