Not long ago, I had to learn some Wicket. What is that? In this case it has nothing to do with cricket – The Wicket I’m talking about is a Java web application framework.
I’ve mostly used PHP and Python to do server-side web application sort of programming. Compared to what I’m used to, Wicket is way different.
Read on to find out about a different way to develop web applications.
My starting point
My starting point with Wicket was basically zero, at least Java-wise: I had never used any Java web app framework, so I didn’t really know what to expect.
Since as I said I’ve mostly used PHP and Python, I assumed the program flow would be something like in them:
- Bootstrap
- Routing etc. handled by framework, goes to a controller
- Controller checks things like whether this is a POST or a GET, maybe decides to load data from models
- View is rendered. PHP or a template language is used to print values from controller in the view
Of course, this was a completely wrong assumption.
Form submit: PHP vs. Wicket
Wicket in my experience has much more in common with traditional desktop application frameworks than with web stuff. Whether this is a pro or a con, I can’t say at this point.
Consider a very typical case of handling a form. What I had done before it was something like this:
- Is this POST? If so, save stuff
- Display form, with values from POST if there was a validation error
In Wicket, it works something like this:
- Display form
Of course, there is a bit more to it than just that.
First, we would create the HTML markup. In PHP, you typically would just put a bunch of echo statements here to display values. Wicket however does things completely differently: You add special attributes to the tags – in the case of a form, we would add wicket ID attributes to the form element and any fields and buttons we might have.
Next, we tell Wicket what components our page has. The reason we put special ID attributes into the markup is so that Wicket knows what elements to associate with which components. So we tell Wicket that we want a form component, input components for input fields, and a button for the submit button. We can also add validators to each component. Also needed is a model, which for sake of simplicity you can assume is a bunch of key-value pairs automatically serialized to some storage (You can actually have something like this pretty easily).
In PHP we would typically tell the view object what values to assign to variables that we echo in the form. We might also test if the method is POST and perform validation and model stuff there.
In Wicket we don’t need to give the form an action and we don’t need to check whether the form was submitted or anything – Wicket does all this for us. The model can even persist things automatically without us having to lift a finger.
So if you compare this explanation (which is not very in depth), it is a lot like a desktop application in Wicket. We don’t tell it anything about the web stuff that happens around it – we just tell it that this is how our document looks and this is how our document behaves. In Windows Forms, you tell the same things. In PHP you need to take care of the logic of the web too, such as handling POST or determining the URL where the form needs to be submitted for it to work.
Conclusion
Wicket is a lot like desktop app development, since you work with components – in desktop apps, you work with controls. Desktop developers don’t need to worry about where stuff goes when the page changes, saving the state, because there are no page changes. Wicket developers don’t need to worry about that either, because Wicket persists things – in a somewhat similar fashion to PHP’s session storage, but automatically and much more extensively.
I was working with Wicket in a portlet environment, so I probably didn’t see all of basic Wicket stuff. Also bear in mind that I only have little experience working with Wicket, so there probably is more than just this.
One case where Wicket’s automatic state persistence and other features might be useful is web applications where you perform actions with multiple steps. Other than this, it does feel somewhat heavy, and occasionally repetitive for the markup and component parts.
Nevertheless, it is an interesting way to do things and if you have the chance, I’d recommend giving it a shot.