I've been meaning to write about my experiences with
Apache Wicket after having it used extensively for my latest project.
So for this project we needed to write a web app with as few screens as possible, preferably a single document interface, keeping it very simple for the end user. The main target audience was the accountancy department, so it had to be keyboard driven. On top of that coming from an MS Access app, the users were expecting autocompletion and immediate validation-feedback.
Given these facts as a Java developer I was immediately thinking: Swing or Flex.
No JavaFX still wasn't released at the time we started prototyping.
Unfortunately our client was unwilling to start with a new client technology involving browser plugins and the possible sideeffects of this on the already overworked helpdesk.
So on we went looking for the best matching web technology...
- SpringMVC - the current standard web technology at that client. Although not a terrible web framework, the single document interface requirement, doesn't quite fit the SpringMVC Action based model. Secondly there aren't any AJAX components, unless you'd integrate third party JS libraries, something we wanted to avoid as much as possible.
- JSF - being the new Java web standard for a while now has gained quite some traction on the job market. Being component based was one of the main reasons why we considered JSF, but with all the complexities that JSF development brings and all extra frameworks built around it like Facelets, RichFaces, Seam and even Spring to getting JSF to be productive and developer friendly didn't reassured my team we could deliver an approriate solution in time. Unfortunately we didn't have experience with JSF and from the experiences on the web we were quite sceptical.
- GWT - Having used GWT for a proof of concept at a past client I was well aware of it's capabilities, but also it's weaknesses. GWT has undergone some major changes since it was released a few years ago. With that a lot of component libraries built around it have come and gone as well. Although in the early days the standard GWT components were pretty basic, the recent 1.6 release shows a big improvement in this area. So today it might have been a valid solution for our problem, but at the time of the project we were still facing the questionable components problem. Because GWT also involves a different development strategy and still has a poor Maven integration (also a standard at the client) we chose to go with option nr 4.
- Wicket - a component based web framework that has been around since 2004 and since long has most of the features JSF 2.0 will maybe have by the end of this year. Given the history of the project, the many positive experiences mentioned in blogs and a team with 2 experienced Swing developers made us decide to go with Wicket.
So what makes Wicket so great.
- Component based - a lot of the UI in our app could be disected into reusable components, really made our life easier in the long run.
- Swing like - event listener and form composition approach used by Wicket is very similar to how you'd compose your UI in Swing. It's not very surprising given the founders of Wicket were Swing developers in a past life. So was 60% of our team.
- XHTML templates - No messing around with JSPs and taglibs. Just plain old annotated HTML templates to describe your layout and components and then accompanying Java classes to define the behavior of your UI. This allowed for some very flexible components, processing and user-feedback.
- Authentication / Authorization - support for plugging in your own authentication and authorization strategy at the component construction and rendering level. This allowed us to have @annotation-based declarative role-based authorization in our UIs.
- AJAX framework - AJAX has been built into the core of Wicket, supporting AJAX events and behaviors and tight integration in the rendering lifecycle allowing the developer to think about the real business issue at hand, Wicket takes care of the rest.
- Form Validation - form and component level validation is built into the core of Wicket and available as part of the lifecycle, even integrated with AJAX behaviors and partial rendering so you don't have to worry about that as a developer.
- Binding - Forms and datatables have strong support for binding to your POJO's or models, based on reflection. You can even go several object hierarchies deep. This also works on the datatable with out of the box sorting and filtering based on such nested paths.
- Statefull - the pages and components you define contain their state as member variables, so you don't have to mess with the HTTPSession, Wicket takes care of this as well.
Having developed for the web in JSP scriptlets/Servlets/Taglibs, Struts and SpringMVC always seemed like too much effort for what you get in return. It's also very confusing what is to happen next, every time I switch between one of those technologies I have to grab the manual again to understand the lifecycle. In Wicket it's straightforward, you instanciate your page class and add components to it, who have listeners and behaviors that you implement. These callback methods get called on the subsequent events... plain and simple!
Working with Wicket has been a pleasure, we started off with just building our prototype screens with XHTML and a little bit of Wicket magic to bring them to life. We soon realized that we could continue to build upon that prototype without having to rewrite all our screens in JSPs like we would have in the other technologies. Our client was very pleased with the non-static prototype and the fact that we didn't had to redo the screens for the real app, this is usually where it goes wrong when developers have to work with a webdesigner for the UI.
We were able to advance so quickly and managed to build some reusable components that can be packaged as JARs to be included in new applications, giving them a head-start.
For a small team without knowledge of the framework it took us just a few days to grasp the basic concepts and worked our way through the rest while working out the different parts of the application, it's just so straightforward and there is a great sample
Although Wicket is an excellent approach to web development in Java, there are a few things you should know...
As you are building a lot of view-logic in your Java code, with a lot of listeners and inner classes for callbacks etc, you really need to think '
components'.
All too often you start the next screen by copy-pasting from the last one. When if you think about it you realize it has about 50% of the same logic, which you should extract from both screens into an abstract component. If you fail to do this you get a messy codebase with a lot of code duplication and each developer tends to have it's own style so it can get messy if you don't work together and refactor in time.
But if you do this like we did, we ended up with a few handy base classes like AbstractFormTablePanel that we needed to give a few parameters and in about 20 lines of code we had a new master-detail CRUD screen for a new entity, with complete sorting, filtering and validation.
Another weak point is that although Wicket has AJAX built-in the core framework that handles JavaScript events and partial page refreshes perfectly a lot of the AJAX components (datepicker, tree, ...) are third party (wicket-extensions project for example) and they are not of the same quality as the core framework. We noticed some JavaScript compatibility issues with some browsers, mostely IE as you would expect. Unfortunately that was our target browser, as is the case in most large organizations.This was also because the Wicket team focussed more on getting Wicket 1.4 out of the door instead of fixing bugs in the old stable branch. Later we noticed that a 1.3.6 version had been silently released where some of our issues were addressed. At least there is still an active community supporting Wicket after so many years and that for a relatively small userbase. On a sidenote Wicket is still slowly gaining job-marketshare:
*note: GWT is 'off the charts' with about 175% growth... worth another look!
All in all I would definately choose Wicket again, it just makes sense and I've never had more fun developing for the web in Java!
