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.

The good news is, that you can write your own components exactly how you or how your customers need it. The bad thing is that you actually have to have to do it! AND: You need the know how to do it! If your application shouldn’t cause anguish to your users eyes, you need people who are web developers, who really know how to deal with CSS, JavaScript; simply people who understand the meat of modern web design.

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.

So, why do I like Wicket? Because I love the flexibility and I like to be in control over everything I do. I want to define the HTML structure, I want to choose the JavaScript framework I like, I want to define the look & feel of my application. I like to build my set of components that do exactly what I want and I like to reuse them all over the place. Almost everything is possible with Wicket, which is good and bad at a time. Bad, because it’s incredible easy to produce unmaintainable spaghetti bolognaise code and good, well, because almost everything is possible.

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!

Links:

Wicket Best Practices (Very good article, but read also the comments!)
Wicket in Action Blog
Stack Overflow – Wicket Disadvantages
10 Things I wish I had known about Apache Wicket

 

About The Author

Arthur Hupka

Arthur Hupka

I have graduated in Computer Science and I am working for Bosch Software Innovations since 2009 as a Java Developer and Technical Consultant with expertise in web applications and batch processing. The past two years I have been involved in several credit risk rating projects and spent months at different customer sites. Recently, I have joined the product development team. I’m interested in all aspects of software development like (component based) software design, architecture, code quality, tests, scrum, etc. In my spare time I'm also experimenting with my own project based on Apache Wicket, Brix CMS, and Google Guice. I enjoy doing sports like bike cycling, beach volleyball and snowboarding. Lake Constance is a great area for doing that btw! I also like reading and visiting festivals during summer. Sometimes I enjoy cooking but I hate housekeeping.