Apache Wicket is a java-based web development framework. I feel it doesn’t get as much attention as it deserves. I’ve been using Wicket professionally for real-world projects for the past 6 years and love it!
In this post, let’s look at five reasons why you should consider using it.
1. Simple state management
The development experience writing Wicket apps is very similar to desktop development. At times you can almost forget about the stateless nature of HTTP. This is because in Wicket the web page and all of it’s components (buttons, text fields, etc) are Java objects that maintain their own state. The state of the components gets serialized into the user’s session, and deserialized at the appropriate times.
In simpler terms, suppose you have a form with fields that a user would fill out and submit. In a Wicket app, this form, it’s fields, and the submit button are all components(Java objects) that are created and added to the web page. When the submit button is clicked:
- We automatically have access to the user input, usually as fields of a POJO.
- We don’t have to connect the HTTP POST request to the GET request.
- We also do not need to think about populating the form fields with the submitted values. This is done through Models which are a core Wicket concept.
2. Standard HTML integration
HTML in Wicket doesn’t require any special tags unlike some other frameworks. In fact you can take any existing HTML and integrate it with your Wicket app with almost no changes. There is only one attribute that is needed to connect HTML tags to Wicket components: wicket:id Let’s look at an example:
<div wicket:id="userName">Roman</div>
add(new Label("userName", getUsername()));
The wicket:id “userName” is used to connect the HTML element with the Wicket component. The Wicket Label component will get the user name and render a div tag. It’s okay if this doesn’t totally make sense right now. It becomes second nature and intuitive when you start playing around with it.
Wicket components are first-class citizens and can encapsulate their own HTML markup/CSS/JS just like in some popular frameworks such as React. This allows us to create highly-reusable code.
3. No Javascript needed (mostly)
Okay obviously, you will end up writing JS code at some point. However the AJAX support provided by Wicket means you don’t need to write your own JS code for most common tasks. Behind the scenes, Wicket uses JQuery and automatically generates the JS code into the web page.
Let’s take a simple example of a page with a dropdown and various other components that depend on the selection of that dropdown. When the selection changes, we need to update these various other components on the page. This actually doesn’t require any Javascript code.
This makes Wicket ideal for building complex interfaces with convoluted business logic.
4. Event/messaging system
Wicket events are a way for components and pages to communicate with each other. Using this feature we can create very complex, yet decoupled, component structures. A component can broadcast a message without needing to know who will receive the message. When a component is interested in a particular type of message, it can simply register to be notified when that message is broadcast.
A component might broadcast a critical update event with payload to all other components on the page in this manner:
send(getPage(), Broadcast.BREADTH, new CriticalUpdate(target, payload));
And if some component is interested in receiving CriticalUpdate’s, it would register like this:
public void onEvent(IEvent<?> event) {
if (event.getPayload() instanceof CriticalUpdate) {
String msg = ((CriticalUpdate)event.getPayload());
//do something with the msg
}
}
5. Unit testing
The component/stateful nature of Wicket means that we can write unit tests for the front-end just like we would write them for the service layer, or our data access layer. Wicket provides helpful utilities to make writing unit tests simple.
Let’s take an example of a simple scenario that might not be so straight forward to test in other frameworks. We have a web page with a CRUD interface: a table with baby names and delete buttons. A form with a text field and button for adding new rows to the table.
We can write a test that will render the page, simulate a user filling out and submitting the form, ensuring the table is updated correctly, simulate the user pressing the delete button, and so on. This can all be accomplished using pure Java code and JUnit without resorting to Selenium, Puppeteer or similar libraries.
6. Fully open source
Ok I did say five reasons, but here’s a bonus: Wicket is fully open source and the code is designed to be easily extendable/customizable. Whenever you run into a scenario where the default behavior or functionality doesn’t quite meet your needs, it’s as simple as overriding a few methods, or extending a class to make it work exactly as you need!
Conclusion
I hope you’ve heard enough to give Wicket a try. If you’re curious to learn more:
- Head over to the official site which contains great documentation
- Take a look the example code which provides code for many common web dev scenarios.
