Subscribe Find out first about new and important news
  • Share via email
  • Subscribe to blog alert

Apache Wicket – three years of lessons learned

18 3 min

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 initial, 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."

Here´s 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

What are the disadvantages of Apache Wicket? Read the article on Stack Overflow.

Wicket is awesome. But... 10 Things I wish I had known about Apache Wicket.

Wicket in Action - a comprehensive guide for Java developers building Wicket-based web applications

18 Comments

comments

Leave a Reply

  • 10. April 2018 at 14:14

    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.

    Reply
  • 15. September 2015 at 0:37

    I had relatively bad experience with Wicket, in fact. Basic things, especially on multilanguage resources, are done with complex coding. When I want form in HTML UI, for instance, I need JSON definition of form fields and JS form generator that will create all UI, handle all user activity up to reaction on keyboard events and perform all validations. It is huge effort to implement it with Wicket.

    I would advice using Wicket for person who is familiar with component frameworks and “thinks in Java”, but nothing else. Basically, Java engineer who has no idea about web browsers and modern JS.

    And you see, in order to create something custom/normally looking, you need effort of Wicket engineer, Core engineer (unless you want wicket-driven spaghetti-style code) and Web engineer – anyway. But normally Core engineer would create optimal back-end with REST API and experienced Web engineer will create JS/HTML5 front-end, which is much, much more compact and cost-effective.

    This is IMHO, of course. I don’t see any benefit of using Wicket. This is just a set of constraints develpment team should follow.

    Reply
    • 30. September 2015 at 9:09

      Thanks for your comment ULRF.
      Wow, this post soon celebrates its 4th birthday and still seems to generate interest 🙂 A lot of things have changed in the web development world since I wrote this article. It has been written for Wicket 1.4. With the rapid pace things move on in the world of web frameworks this article is a dinosaur, in fact.
      I don’t use Wicket on a daily basis any more and cannot tell much about what changed in recent versions of the framework.
      You are right, that the “old” coding style of Wicket (1.4,1.5) in Java tends to be very cumbersome to achieve easy functionality nowadays.

      I moved on to Angular JS for frontend development to not miss the trend for single page apps. For now I am pretty happy with it. Even though I still didn’t fully understood all aspects of directives 🙂
      However, with Angular JS it is not easy to create re-usable components like it is with Wicket. I am using aspects of the this excellent article to create re-usable self-contained components: https://leanpub.com/web-component-development-with-angularjs/read
      Ironically Wicket solves a lot of the problems described in the article.
      The Angular Team noticed that drawback and Angular 2.0 is going to ease development of re-usable UI components using Web Components.

      Regards,
      Arthur

      Reply
  • 17. April 2015 at 9:34

    nice article ..may i know did you work on it..actually it says how we need to react on it.

    Reply
  • 13. May 2014 at 8:19

    pls share apache wicket crud operation example

    Reply
  • 6. February 2013 at 0:29

    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
  • 5. February 2013 at 10:54

    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
  • 4. February 2013 at 23:04

    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
  • 30. January 2013 at 11:13

    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
  • 22. October 2012 at 9:36

    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
  • 15. October 2012 at 12:00

    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
  • 12. December 2011 at 10:28

    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
  • 3. December 2011 at 14:50

    @ 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
  • 28. November 2011 at 10:27

    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
  • 25. November 2011 at 2:01

    "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
  • 23. November 2011 at 11:55

    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
  • 23. November 2011 at 2:10

    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
Cookie Information

This website uses cookies for reasons of functionality, comfort, and statistics. If you consent to this use of cookies, please click ”Ok“. If you like to disable the cookies for webtracking, please click here. For more information see our Privacy Policy