Why I’d choose Apache Wicket as a web application framework- part 4

Framework minus points
To be fair I have to say something about what I think are the current weakness of the framework:
Remember that Wicket has been developed for state-full applications. But there are a number of reasons why you’d want to opt for a stateless application.
Because if your application is stateless it means that requests can be processed by any of the web servers in your cluster, because all the parameters a page needs to reproduce a certain state are provided in the url. In a state-full application you either have to turn on session replication for the cluster(and infer a performance penalty on memory and network usage to keep sessions replicated on all machines) or more simply turn on sticky sessions to make sure that subsequent requests land on the same server where the user’s session was created and contains the data.
Another reason could be that for a state-full application a http session must be created, which is kept in the url as the parameter “jsessionid” when indexed by search engines, and this might not look nice for a user seeing your page url returned as a search result.
But if you insist of keeping your application stateless is not really that hard though, and it may seem hard because you will be doing things that Wicket was doing for you and you took for granted, and practically you’ll just have to face the same thing that developers using stateless frameworks do every day.
The community provides support and replacement stateless components have been developed.
2. Because currently Wicket has its own JS Ajax engine, when changing the DOM structure through Wicket Ajax(replacing a panel for ex), your JQuery selectors have to run again on the new DOM structure. This can easily be bypassed by packaging your selectors in a JS method and call it after doing the ajax operation.
As stated above, using JQuery for doing Wicket ajax is on the roadmap, and this little inconvenience may dissapear on its own.
3. With Wicket, the session size tends to get big if you do not know how to detach your models. So this might hurt you in a way that it’s not evident from the start but when your user base grows. Having to know the framework I suppose it does go without saying and it’s a must for just any framework, but I just wanted to reiterate that I advise you as a new wicketer to take some time to really understand Models as they are an important concept in Wicket, especially DetachableModels.
4. It has a higher learning curve because it’s harder to find good object oriented programmers. Some people even learn to develop more Object Oriented and clean because of Wicket. Even if you are a Java programmer but come from a procedural way of programming JSP, Struts, Stripes you might get frustrated of having to instantiate components with models instead of the quick & dirty way of just throwing in some code in html. Don’t get me wrong, there are situations when the quick and dirty way might be the way to go, as stated for conclusions, Wicket like any framework should be used where it brings value, not as the proverbial hammer with everything looking as nails.
5. Performance testing done with tools which do not simulate real clicking on web components, but rather build URLs with parameters, much like JMeter does, requires an analysis of how Wicket generates the urls and how to match them, by the people doing the performance testing (because Wicket is state-full a page version parameter is encoded in the url, and also study the url on how to target specific Ajax Behaviours in the page).
As the closing statement I think and let me point out that I’m also a true believer of using the right tool for the right job and that in some cases Wicket might prove overkill. For example if I’d want a read-only site like say a blog, then I’d probably go for a light PHP CMS solution like WordPress.
Or if you have a desktop like application and you require out of the box heavy JS components that look good and don’t need customisation then maybe I’d use Vaadin. Whatever the case I’d say if you are looking for a component based and you like you should at least give Wicket a try and so to set you on the right path just use the following Maven Wicket Quickstart archetype to generate and run yourself a very simple Wicket project:
mvn archetype:generate -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=1.5-SNAPSHOT -DgroupId=com.mycompany -DartifactId=myproject -DarchetypeRepository=https://repository.apache.org/content/repositories/snapshots/ -DinteractiveMode=false

Category: Technology & Development
2 comments2

Your comment

  1. December 9, 2011 at 09:07 | by TH Lim

    Good summary. And I have something to say to “Another reason could be that for a state-full application a http session must be created, which is kept in the url as the parameter “jsessionid” when indexed by search engines, and this might not look nice for a user seeing your page url returned as a search result.”

    You bookmark your Wicket page to have a neat URL. You don’ t have to do it with every page but the key pages.

  2. December 13, 2011 at 14:20 | by SerbanB

    Hi Lim,
    Bookmarkable URLs dont help with stateful pages. Sure If you have a bookmarkable url you can bind your page to something like /products, but still while google crawles the site it will append a jsessionid to the url something like /products;jsessionid=3255265432?id=2

    I’m not sure if today Google is not smart enough to ignore a jsessionid part in the url in it’s ranking algorithm, but aside from the fear that this might cause lower rankings, it also a chance it might “scare away” some users from clicking on links that have a big random generated in their name.