Apache Wicket is a neat web framework to create web sites and web applications. I’ve been working with Wicket extensively for more than 3 years now, both at work and for my private project. Before I knew Wicket I’ve worked with JSF(1) and JBoss Seam 1. I think it’s time to share some practices and experiences I’ve made during that time!
Compared to JSF, Wicket was a pleasure to learn and use. Nowadays I see Wicket as a kind of two-edged sword: I really like the framework. Properly used it can greatly improve productivity building web-based user interfaces. Used the wrong way it can lead to, well, a great code mess, bloated session sizes, serialization errors, bad performance, side effects and a poor user experience.
I’ll try to explain what, from my personal point of view, ‘properly used’ means: Wickets biggest strength is its focus on components. Everybody who is able to spell Java is able to write Wicket components after one day of learning the framework. Somehow at least. Writing flexible and good components is another story. Wicket does not provide sophisticated, polished components out of the box, like Vaadin or Ext do for example.
Let’s face it: The default wicket components are just plain ugly. Far away from being state of the art and they are pretty low level.
But thats still not enough. If you want to build your own component library with Wicket, you really need someone who has some experience with the framework, who understands all the basic stuff very well. One who has done at least one project with the framework. Writing reusable, flexible and maintainable components prerequisites experience writing components. It’s that easy.
Where Wicket really shines is, when it comes to dynamic rendering of User Interfaces. For example based on meta data or an abstract meta model like we do it in the Dynamic Application Framework.
To make it clear: If you don’t write your own, documented component library at your department or even better, company-wide and spread it, you will have a hard time with Wicket. The framework requires inital, not to be underestimated effort to yield performance.
A good indicator that something went wrong is, if you see developers with semi-knowledge in basic web technologies fighting with Wickets low level components for each and every screen.
Heres my proposal to make it better:
- Get people who have web development experience.
- Let them read Wicket in Action. Make sure they do the example project and improve it by themselves, for example ‘ajaxify’ it.
- Identify components like tables, master-detail-views, dynamic forms, autocomplete widgets, etc.
- Let them implement the components and dogfooding their stuff in an example application, with brief descriptions and various use cases which should act as usage example for users across your company.
- Spread the message across the company.
- Build new components and improve the existing ones.
Wicket was a breeze compared to overcomplicated and bloated JSF(1). Nowadays I would evaluate if there are other web frameworks out there which do fit my needs, before I used Wicket. I still love the framework, because I like Java and Web Development, but it has its gotchas when it comes to modern user interfaces. One needs a lot of know-how to create fancy, user friendly stuff.
In an ideal world you’d have at least one Web Designer and one Java Guru with web development experience (of any kind) working together on one kickass component library for your company or department.
Apparently, this is not my last post about Wicket. There were more lessons learned during the past three years!
Whats your experience with Apache Wicket? I’m happy to share some thoughts in the comments!