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

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.

13 Responses

  1. Matthew Cornell

    I'm just now learning about Wicket. I don't know Maven, and I found  the quickstart a turnoff. I would like to set up Wicket from scratch, say using Jetty, but I can find how to do this nowhere. I'd like to try the Wicket examples, but I'm stuck. Drat!

    Reply
  2. Arthur Hupka

    Hey Matthew, 
    thanks for your comment! I' using maven myself and I think dropping maven on your machine and using the maven quickstart archetype is the most convenient way to create a Wicket  project. However I could zip the quickstart example as Eclipse-ready project (including required dependencies) and provide it to you. 
    Just let me know if that would help.
     

    Reply
  3. Per

    "One needs a lot of know-how to create fancy, user friendly stuff."
    Thanks for the nice article, and while Wicket has some drawbacks, I have to disagree with this line. In my opinion, it's really pretty easy to create fancy and good-looking stuff. The built in Javascript support is great for most use cases, and you can always use pure jQuery if you need more advanced UI. And to make it look fancy — well you just use proper CSS and ask a friend with a sense of "what is pretty". 
     
    The main risk with Wicket is really that you need staff that are capable of reading code. I find myself frequently adding functionality to the core classes when I need to solve specific problems. It's great that this is possible, and I have never gotten stuck so far, the Wicket code is really extensible, as you said. But while it's always good to have the best developers — in Wicket it's a *must-have* to have the best developers. 
    But if you do have great developers, I think you can relax the requirement about well-documented components a bit. It's not *that* hard to write reusable components, in my opinion.
    Oh, and thanks for the link!
    Per

    Reply
  4. Arthur Hupka

    Thx for your nice comment Per!
    You are right, it is not that hard to create neat components at least if you have the know how to do it.
    Without extensive web development skills including HTML, CSS and JavaScript you won't be able to create fancy, modern and user friendly components. My personal experience is that Java Developers do not have enough web development experience in most of the cases. It's common that JavaScript is considered as work-of-the-devil technology, for example ;-)
    So you really need the web development and design know-how AND you need to know Java AND the framework very well. Otherwise it's very likely that your view code turns into a mess. That's what I've meant by "a lot of know-how to create…". 
    Thx again for your comment!

    Reply
  5. 192709

    @ Mathew: Maybe you will find the following helpfull
    http://agileskills2.org/EWDW/Chapters1-2.pdf
    @ Arthur: Thank you for sharing your experience. Well done.
    I agree with your point that you better create your own Components in Wicket , but:
    – working in a team of 6 Developers we found that it  is not sooo dificult (but you are right – one should not underestimate it)
    – this gave a much better understanding of wicket from the very begining  and
    – isn't that a good approach in principle? For example in Swing/SWT I would reocommend  same … .
    W.r.t. modern GUI – we learnded that there is no "modern GUI" – modern is alsways depending to the one you ask – we did that at least with 8 Requesters – representating four countries,  and made roughly 12 proposals. The preferences of the requesters (who partially forwarded the proposals to there key users in their country) draw a picture of equal distribution … . Furhter take a look on Linux : Gnome, Kde, Unity are only the most popular window managers  – and each of them has a number of popular Themes … .
    Best Regards, Marcus
    PS: We decided to combine wicket with SCALA – and we are delighted :-)

    Reply
  6. Arthur Hupka

    Thanks for the valuable link! I haven't known this E-Book book before. Looks very promising!

    I agree that this might be the best approach for GUI code in general. However I do not have much experience with Swing/SWT. But I know that Wickets programming model is similar to Swings.
    However, like already pointed out,  I think developing good web based UI components using Wicket is a bit harder compared to using a rich client framework like Swing, because of the required additional web skills.
    You are right that there is "no modern GUI". It always depends on the user base you serve. If you develop components for customers all over the world, like you said, theming becomes also an important topic and needs to be considered.
    I haven't used Scala myself so far. Just read about it and wrote a couple of lines of code. Can you show a couple of lines of code or do you know a blog article about Wicket and Scala?
     

    Reply
  7. Hussain Savani

    Hey Arthur,

    Nice article. Have you worked on frameworks like Lift and Play? Can you please provide some comparative analysis between Lift, Play and Wicket if you have ideas on these. Thanks.

    Best Regards,
    Hussain Savani

    Reply
  8. Arthur Hupka

    Hi Hussain,

    thanks for your compliment and interest in this post! Apologize the late response. I was busy at client site. I was curious about the Play framework and had a brief look into it. Play 2.0 was recently released and a lot of new stuff has been introduced (i.e. new build system). My problem was that the 2.0 documentation wasn’t too mature at that time.

    Wicket and Play follow substantially different approaches. Wicket is a real web component framework, whereas Play is more like a web dev platform, because it brings its build system, modules, persistence, defines project structure etc. So its harder to integrate into existing applications. You’d rather use it for new web projects.
    Take this comment with caution. As I only had a very brief look and never seriously used Play! I’d rather not trust me too much ;-) Therefore I unfortunately can’t come up with a comparative analysis due to lack of knowledge in Play.

    Kind Regards,
    Arthur

    Reply
  9. christi parks

    Hello, sir i would like to ask that what is the scope of java training, what all topics should be covered and it is kinda bothering me … and has anyone studies from this course http://www.wiziq.com/course/1779-core-and-advance-java-concepts of core and advance java online ?? or tell me any other guidance…
    would really appreciate help… and Also i would like to thank for all the information you are providing on java concepts.

    Reply
  10. Henning

    I totally agree with your experiences. A good and succesful Wicket project needs at least one person knowing GUI development. Knowing when to make or refactor a component. Knowing Wicket,Swing,SWT or other component based frameworks and take care of the frontend part providing the components which are needed. That really makes the difference in quality.

    You also need web-developer/designer to make the Frontend nice, actually this is a base concept of Wicket to provide this, cause it’s a disadvantage of JSF. In practise, Schemes are not used. They are nice for a “Hello World” or a cheap intranet portal. But for public web-apps(also JSF/…-Faces, any other Web-Framework) customized and detailed L&f’s are used (I guess 80% market).

    I experienced a big advantage for the (web-)project in having a selenium-tester. You can forget about the sonar 25% test-coverage testing stupid crud or transformations, or if enough money is involved and there is hard logic perhaps some more important things. The effort to benefit ratio is unbeatable and i would always use selenium as main quality ensurance tool.

    Kind Regards,

    Henning.

    Reply
  11. Arthur Hupka

    Thx for your comment Henning! Nice to see this post still gets some attraction and also that people tend to gain similar experience with Wicket :)
    Quality assurance-wise we use both: a WicketTester based approach testing pure functional UI logic and Selenium for automated use case integration testing. However, we’re facing some problems keeping the Selenium tests stable and up to date. Especially when javascript and Ajax is involved (timeouts…). Do you have any experience or links you’d like to share?

    Regards,
    Arthur

    Reply
  12. Henning

    I know the timeout problem in long running processes using ajax and no :) i don’t know a solution for this. In some cases we just increased the timeout to a value which we thought will fit the appropriate response time.For long running processes the appropriate time is much longer when on simple html-rendering with few backing objects. So i would just say, that an ajax request and the tested timout-time depends on the process itself and if there are performance issues, one would have to improve or respec the requirements or doability.

    Perhaps you could share some more details about your experience with the stuff you do.
    The first paragraph describes how we reacted and didnt face the problem anymore. So perhaps theres some information missing for me.
    You say you use wicket tester and selenium tester for assurance. How does it work or benefits? And why did you decided to use both?

    Reply

Leave a Reply

Your email address will not be published.