Wicket Impressions, moving from Spring MVC / WebFlow
March 2, 2007 102 Comments
[update 2008-05-27: A detailed presentation that summarizes this blog post along with visuals and code snippets is now available]
For quite a while, I was trying to ignore the increasing buzz about Wicket, convincing myself that I don’t need yet another MVC framework (there are too many of them anyway), but somewhere between the Javalobby articles, the InfoQ article and the O’ReillyNet article – my resolve cracked and I took a closer look.
It looked interesting and so I decided to try and migrate a selected few JSP screens of an existing Spring MVC + Spring WebFlow application to Wicket. This went much better than I expected and two months later (not full time) – I completed migrating the entire app to Wicket and it is now ready for a new release as a 100% JSP free application. I’m now trying to convince my colleagues to try Wicket and they give me strange looks because I was an outspoken Spring MVC / WebFlow fan not so long ago : )
So is Wicket the one true MVC framework that a lot of us have been hunting for? At the moment, I tend to think so. Of course I have not tried GWT, Tapestry, RIFE, Stripes, JSF, Seam, Echo2 and the other usual suspects. And how is Wicket better than Spring MVC and Spring WebFlow? Having used both, I will attempt to elaborate below.
[update1: I tried JSF, and you can read my comparison of Wicket with JSF]
[update2: I also tried GWT and here is my comparison of Wicket vs GWT]
[update3: Detailed performance & memory usage comparison of Wicket with Seam / JSF]
Lots of information is already available on Wicket and how it compares with other frameworks in general, so here I will try to focus on what I experienced when I moved from JSP + SMVC + SWF to Wicket. The way I had to throw some of my pre-conceived notions about Java web-app development out of the window may be of interest to you. This is not a very structured list, but I’ve been meaning to put down these first-hand Wicket impressions for a while, so here goes:
Pure Java
If you like Java you will really like Wicket. Over the last two months, I was surprised to learn a few Java-isms that I was not aware of – such as some subtleties when using anonymous inner classes etc. To be really productive with Wicket I think that your Java fundamentals do need to be sound. But that is a good thing.
Great component model
The application that I migrated is a reasonably complex one, with a few CRUD screens, forms, search results etc – and Wicket offered almost everything I needed – and more. I was able to easily create a couple of custom components like:
- a date picker (Wicket has one but I really wanted to write my own)
- a variant of a multi-select check box where if there are pre-selected values, they “float” to the top of the list. It was very easy to create this by extending the Wicket multi-select checkbox.
Once you get used to components (even a web page is a component) as opposed to URL mappings and MVC actions, you can develop at a very fast clip. After experiencing the elegance of this kind programming model where you can show or hide components and control all this in pure Java code as opposed to hacking in JSP or JSTL, you really won’t feel like going back.
I used to hold the opinion that people new to Java who need to learn how to create web-applications could probably skip most of the Swing sections in the typical introductory course material and get straight on to Servlets and JSPs. Now I have completely reversed this thinking. Swing-style coding is the future for web-applications, I can feel it :)
In the old app I had written a custom JSP tag for the special multi-select checkbox list and was quite pleased with the result. I used to think that JSP tags were more than sufficient to create re-usable components and using Prototype directly was enough do fancy Ajax things etc. Now I have revised that opinion as well.
*Real* separation of concerns
Because the application I was developing had zero JSP scriptlets and strictly used JSTL, I was under the impression that I had reached nirvana in terms of separation-of-concerns.
Of course I was wrong again. In Wicket, all layout is controlled in good old HTML files. And Wicket has some neat-o ways to do markup-y things in the Java code itself – like for instance how you can color alternate rows when rendering an HTML table.
If you have a separate team doing the presentation look and feel work, they can truly work in isolation and their output can be used as-is. Although I don’t care about this at the moment (in my case, the UI designer and Java developer is the same guy), I’m sure that this is a big deal for most development shops. I am aware that Tapestry promises the same thing.
So this is a key difference from Swing where you have the concept of layout managers. As far as I know this is where frameworks like GWT and Echo2 are different from Wicket because they also have layout controlled in Java code. IMHO the Wicket approach is the right one because you get the separation of concerns advantage. And I personally like complete control of the markup. I mean, with all those silly cross-browser incompatibilities and the need to finely adjust spacing, padding, coloring and the like, this seems to be a good thing.
No JSPs
This is very nice because:
- You can do things much more easily and efficiently in pure Java than in JSP and the limited syntax of JSTL. Ever had that nagging feeling that your JSPs were getting un-maintainable? Try Wicket!
- You can refactor confidently and catch problems at compile time which are not possible with JSP. For example if in JSTL you were referring to a non-existent Javabean property, you may not know until the page renders.
- Pages are no longer slow the first time you access them because there is no more JSP compilation step
- in my case, the app embeds Jetty and now I don’t need the JSP jar dependencies any more. This cuts the Jetty footprint from about 7 MB (including Ant and the Eclipse Java compiler) to about 1.3 MB. I had tried JSP pre-compilation earlier but gave up because of differences in how Tomcat / Jasper does things vs the Glassfish JSP engine. Jetty + the web-app requires only a JRE to run if there are no JSPs.
- A nice side-effect of using wicket is that your pages are guaranteed to be XHTML compliant
The downside is of course that you have to recompile a little more often than if you were using JSPs. Wicket does allow you to change the markup on the fly and refresh in debug mode. Also, Wicket provides out of the box, a very detailed error page with some nice syntax coloring telling you exactly where the problem lies in your markup or otherwise – which is very, very cool.
Re-usability
Ah, again, *really*. Re-usability in the JSP world is a custom tag or a hack-y include file.
I already mentioned how easy it is to extend (yes, extend as in the Java keyword) a Wicket component to customize how it behaves. And once you get the hang of the Wicket way of doing things and how to use anonymous inner classes to your advantage, life is good :)
So compared to doing things in JSP, it is far less work in Wicket to create a component that is truly re-usable, say across all the pages of your application. And unlike JSP tags, you get the full benefit of the Java OO features. Did I mention that the design of the whole Component class hierarchy in Wicket feels very nicely done?
Wicket also has a Panel concept where you can group custom markup + components and re-use the group as a single unit to your hearts content. IMHO you really don’t need any “tiles” kind of framework anymore, just create panels and instantiate them at will.
Templates for web pages
Something I really missed in the JSP world was the ability to have all pages have a consistent header and footer and I really hated having to add includes to all JSPs to achieve this. Not any more. Wicket has a brilliant markup inheritance concept that simply works.
Ajax
I’m guessing that this is the killer feature of Wicket. Control freak that I am, I was at first concerned that Wicket comes along with its own basic Ajax implementation, or in other words it provides a replacement for say Prototype or Dojo out of the box. I initially tried to use Prototype from Wicket and was pleasantly surprised when that proved really easy. Adding on Scriptaculous effects was no problem either.
But after trying the Ajax support in Wicket I was really impressed and soon decided to do away with all those *.js files lying around in my web-app. The very useful Ajax debug popup that automagically appears on your web pages in debug mode is one good reason to rely upon Wicket’s built in Ajax. Now I feel confident that I can implement any kind of fancy Ajax on my screens, so bring it on! One example that I tried and can mention here: it was very, very easy to create a page that runs a long running process in a separate thread and updates a progress indicator through Ajax every few seconds or so.
So using Ajax is as simple as telling Wicket that instead of showing or hiding a component using a full-page refresh, do that using Ajax partial-updates to a page. And it just works on any kind of component. And when you use Wicket’s Ajax features you typically never need to write a single line of Javascript.
I came across this quote that Ajax in Wicket is possibly better and much easier when compared to how you do it in Ruby on Rails, and I wouldn’t be surprised if this is true.
Form Binding and Validation
Spring MVC is extremely good at binding HTML forms to POJOs, (a far cry from Struts 1.X) -so can Wicket be any better? I really think so. Just like Spring MVC, as long as you have POJOs and you bind in terms of OGNL, you are fine. I was able to bind almost all of the POJOs that I was using in the earlier Spring MVC app to Wicket forms without any problem. Some things felt really cleaner – like how to have multiple submit buttons on a form.
When it comes to Form validation and displaying validation errors, there are so many options and great possibilities. By default, you can display errors in a section (feedback panel) at the top of the form. I was also able to create a Wicket “behavior” that would highlight the offending widget on the screen by applying a red CSS border around it. Lurking on the Wicket mailing list, I can see folks trying all kinds of cool things such as Ajax-ified feedback messages etc. The Wicket mailing list is a friendly source of help btw, and I got quick responses to all my newbie questions.
Other Neat Stuff
Wicket has some goodies and some of the ones that I ran into (there must be many more) were these:
- File upload: After using Spring MVC where you have to choose say commons-fileupload and manually include the JAR, I was pleasantly surprised to see that Wicket supports multipart forms / file uploading out of the box.
- File download: Wicket has a special “Link” class specifically for the purpose of downloading files. Wicket takes care of all the low-level details such as setting the right content-type for the browser – so you end up doing the Right Thing. You don’t need to deal directly with the HttpServletRequest or Response objects at all.
- Buffered Image: I use JFreeChart and in the old app I had to hack around a bit to get a server-side created chart streamed into an IMG tag. Wicket has an Image component that works with a buffered image. Perfect!
- URL Mounting: You can get those bookmarkable “friendly URLs” you want with this feature. I liked the support for “REST-ful” URLs out of the box: e.g: /foo/bar/param1/param2 – and how easy it was to use.
Security (Acegi) and Wicket
The old application was using the Acegi security framework. I started out retaining Acegi for authentication and co-existing with Wicket, which was easy. I soon realized that Wicket has a very simple authorization strategy and I was able to plug in custom code to check if a user is not logged in, redirect to a login a page etc. I was also able to easily handle an auto-login using a “remember-me” cookie.
An interesting thing from the security point of view is that the URLs that Wicket generates are inherently secure. In other words it is near-impossible to predict them as they are tightly tied to a user’s session. I came to the conclusion that simply programmatically hiding / unhiding links to secure pages based on the currently logged in user’s role would be sufficient for role-based access-control kind of security.
Acegi is very useful in a URL to MVC-action mapping situation because you can restrict URL patterns to roles – e.g. you can enforce URL wildcard rules like “/admin/**” can be viewed only by ROLE_ADMIN. I will probably continue to use Acegi for a planned remote REST/POX API to the app and for the LDAP and CAS support that it comes with etc. But I’m almost convinced that Acegi is overkill for a basic Wicket app. I am still going back and forth on this – so do let me know what you think.
Integration with Spring
This was easy. I was able to manage without the recommended wicket-spring integration JARs and went with a relatively simpler (and arguably less-elegant) approach – plucking the Spring context out of the ServletContext. In case you were wondering – I have so far used only the core wicket JAR and have not even used wicket-extensions. But I’m sure I’ll start using wicket-extensions soon, I can’t wait to try modal popup windows, the file-upload progress-indicator and the other cool stuff :)
Another example of how well thought out Wicket’s design comes across is that it took only a few lines of code to delegate to the Spring MessageSource instead of using Wicket’s default i18n. So I was able to use my existing resource bundles unchanged.
Integration with Hibernate
I use Spring on top of Hibernate and staying clear of the dreaded LazyInitializationException was as simple as adding the excellent Spring OpenSessionInViewFilter. Regarding GWT, from what I can make out, getting it to work with Hibernate may not be as easy because of the way it works. I would appreciate some comments confirming this, because this could be another key point to consider when you choose an MVC framework.
No Annotations Required
Yep, I’m one of those stubborn types who firmly believes that the only annotation that you should use is @Override. And as mentioned above I did not use the annotations based Spring integration. I bring this point up because from what I have heard – some of the other competing MVC frameworks rely a lot on annotations such as Tapestry, Stripes, RIFE, Seam etc. So if this really matters to you or if your environment is pre-JDK5.0, it could be another differentiating factor. Wicket already is famous for not needing any XML configuration at all. If the Wicket guys are reading this – I really appreciate that you have not forced users to use annotations and I sure hope Wicket stays that way!
WebFlow or Wicket
In the old app, I was using Spring WebFlow and was quite happy with it. So when I started out with Wicket, I was trying to figure out how I could integrate it with WebFlow. But as I understood Wicket more and more and things started to click in my mind, I realized that there is no way you can have them both – you have to choose one or the other.
I found WebFlow great because it allowed me to re-use subflows. So as an example if I had a use-case like “assign task to user” and the user did not exist, I could easily call the “create user” flow and then resume the original calling flow at the point where I branched out, you know – all that continuations stuff. But now my conclusion is that you can easily do all that – and more – with Wicket.
In Spring WebFlow, each view state in a flow is typically a JSP page. Which brings me to now think that it was not really designed to reuse anything more fine-grained than a JSP view – when interacting with a user. I already mentioned that Wicket allows you to reuse sections of HTML and group bunches of components into panels. So when you start trying to build more dynamic pages – I think Wicket wins. Navigating back and forth in Wicket really is child’s play, you just call or instantiate another page at will. You can even do tricks like holding a reference to a previous page, (a page is nothing but a good old Java component) so you can build any kind of complex kind of back-and-forth or wizard kind of navigation easily. I am aware that Wicket has a breadcrumb component and a wizard component but I have not tried them yet.
When it comes to Ajax, I really think Wicket is better than Spring WebFlow. Spring WebFlow is unquestionably a well designed framework, continuations and all, but sometimes I felt that certain things were constraining – for example you have to jump through a few hoops to access flow-scoped variables from outside a web-flow. When you use Ajax, you do need to do that kind of stuff a lot. In addition, in the Ajax world – you are invariably dealing with a section of a page – rather than the page in its entirety – and that is where IMHO the “page centric” nature of Spring WebFlow is a limitation.
A couple of other points, I did not use browser back-button support at all yet, but just from looking at the documentation, Wicket’s back-button support appears to be just as good, if not better. And nit-picking here – I don’t particularly like the huge UUID kind of URLs that SWF generates by default eg: /like?_flowExecutionKey=_c815540C2-03F1-39F8-19E9-D56FC0E377B7_k14D5E331-7B59-EA45-CF06-672C33FA2097
But Wicket is quite the opposite, with a “URL compressor” turned on by default.
End Note
Are there any points I have missed? Please feel free to comment and help me straighten out my thoughts on comparing some of these MVC frameworks. The migration was done on an open source app, so if you want me to pull out some “before and after” code samples, do let me know!
Afterthoughts [update 2007-03-03]
Triggered by the comments and also a few additional things that popped into my mind:
- Unit Testability: I have not used this yet, but if this means a lot to you – Wicket has that covered. And before you look down on my lack of best practice :p let me hastily add that I use Watij, but not as much as I should have.
- Custom Session: You can create a typesafe custom Session class and you never need to deal with the HttpSession at all.
- Refactoring: It is worth repeating that because of no JSPs, no templating (like for e.g. Velocity) and no XML – refactoring of the Java code is simple within your plain old IDE and no special tooling is required. I can vouch for that, I am using NetBeans and have no extra modules (plugins) installed. Debugging, setting break-points and stepping-through plain old Java code is far more easier than trying to do the same thing with e.g. JSPs.
- Simplified Stack: In my case I replaced [HTML + JS + Prototype + JSP/EL + JSTL + Spring MVC + Spring WebFlow] with [HTML + Wicket]. Also note that whether Acegi needs to be there or not is debatable.
- Clean separation from Service Layer: This is somewhat specific to Seam and let me elaborate a little. I attended one of Gavin King’s Seam sessions recently and was a little taken aback (so were quite a few others) by the suggestion that the notion of a re-usable middle tier (service layer) is grossly over-rated, i.e. a) you normally never find yourself swapping out a layer, and b) a change in one layer always impacts the other, no matter how loosely coupled they are. Conclusion: so why bother, and you are better off merging all the layers into one. You know the feeling – like wtf, is this back to the monolithic JSP-directly-accessing-DB days!? Anyway – now I can stand up and testify that I was able to cleanly take out Spring MVC and replace with Wicket with only minimal changes to the service interface (mostly feature adds and minor refactoring). This is worth thinking over, and I also feel that a well defined Service Layer is easier to expose as an XML remote API, which I plan to do soon. Just my 2c, do comment!
About Peter Thomas
Incremental Operations 
Congratulations! You are definitely getting the vision. Still, I think there will be a few nice surprises down the road for you too. When you switch to Wicket’s string resource loading in your next project, that will have some nice effects. Also, check out the contrib-auth-roles package. I don’t like annotations too much either because of the tendency for their abuse, but that package is particularly excellent use of them which may change your mind. Another thing you didn’t mention that seems just painful in most other frameworks is refactoring. Because Wicket is all typesafe Java classes and no XML, refactoring is simple and fast in your favorite IDE and with no tooling support.
I just took a quick peek at the codebase for Voicetribe (a Wicket app). A couple things that stand out to me that you didn’t mention: You can create your own typesafe Session subclass and never access the HttpSession directly again. I’ve got a completely reusable authentication panel to use in future projects. Panels all over the place in Voicetribe (they’re really a big reuse unit for Wicket). Not only do I have some custom validator subclasses (like a UniqueEmailValidator that checks the user registration database), but I also have subclasses TextField to create a lot of reusable components like EmailField, PasswordField, FirstNameField, etc. This gives you a single place to change the validation for a given type of field on your site.
Jonathan: glad you could stop by – and thanks for Wicket!
have you looked at Sturts2 It’s a combined MVC of Struts and WebWork2…
Awesome… MVC… You should try it…
URL Struts2:
http://struts.apache.org/2.x/
No I have not looked at Struts2 and I honestly see no compelling reason to move to it if you are comfortable with Spring MVC (like I am), because they are both basically action-oriented MVC frameworks, and Spring MVC has been around for a while and would obviously integrate better with a Spring service layer. Of course, maybe I need to be enlightened more about Struts2…
My conclusion at the moment is that an action-oriented framework is fine for simple applications but if you need better re-usability, maintainability and lots of Ajax – a component-oriented framework like Wicket is the best bet.
Thanks for that nice Piece Peter. One other thing that you might like in wicket-extensions is the wizard component, e.g. to implement your ‘assign task to user’ flows.
I have also heard of users (and Matej, who is a Wicket committer) that they have been able to integrate jBPM quite well if you would ever need to manage more complex workflows. Though I believe SWF is probably well done and all, I personally always felt that if workflow is key to your application, you should use a decent workflow engine rather than SWF which seems to be primarily concerned about just the user interface. jBPM is my favorite as I found it to be the easiest to use/ program to/ test.
Thanks Eelco and I will take a closer look at your wizard :)
And I will think of jBPM if I need complex workflow, yes.
You have been added to:
http://cwiki.apache.org/WICKET/articles-about-wicket.html
I still use Acegi with Wicket because:
– it protects my services
– it has very good support to get authentication information, for example from a LDAP server.
For Hibernate integration: take a look at DataBinder (http://databinder.net/).
Using Acegi (or whatever makes sense) for authentication probably makes good sense and we were careful to separate authentication from authorization for this reason. However, it seems to me that authorization would still almost certainly be best implemented the Wicket way.
Very good article. I have been trying out a few different frameworks last couple of weeks for a new project that i am starting. I have always been most comfortable with Spring MVC but since it is very low level i am trying out other options. Stripes seems great to me because of its great java 5 features. A major example is in data binding. Spring MVC requires you to pre-instantiate the aggregates of a domain object before you can bind the request, but stripes doesnt. How does wicket take advantage of the java 5 generics, or is there no support in that area?
Wicket 2.0 is generified.
Just added an update at the end of the post based on comments and additional thoughts.
Layering is not only about being able to swap one with another. Its also about separation of concern, which gets more and more important as your team grows. Not everyone in a large team is a jack-of-all-trades. People who dont know the view technology can still happily work in a lower layer and not mess things up as easily. How many times have you had to fix a jsp because a designer went in and screwed something up?
Another point is testing. You can get a higher code coverage easier by testing layers in isolation.
There is this general concern about Wicket that, since all the elements in HTML are components, it eats up a bigger chunk in your heap in comparison to other frameworks. Also the session management mechanism is blamed to be very heavy on the memory. What are your thoughts on the same?
Not all elements are components, just the dynamic ones. Furthermore, being worried about the session size is for most people premature optimization. Though using server side memories decreases your options in how you can cluster – you should use sticky sessions, which is something that most Java web applications seems to do anyway as they are often relying on techs like Hibernate with object caches etc – it’s not as bad as it may sound. My simple laptop here easily handles thousands of sessions already. It is a consideration if you plan to build a public facing web site with big spikes. But even then there are facilities in Wicket such as stateless pages to get around that.
Wicket is a stateful framework and it does use server heap more than many other frameworks.
There are some important mitigating factors (below), but if you know you need to scale to very high numbers of users and you’re unsure about how heap use will affects your COGS efficiency it would be smart right now to do some exploration of server resource usage for your particular application by doing a good mockup and JMeter test of one or more typical pages. This will take time, but you’ll know more or less how many sessions you can serve and therefore how much a session costs.
The mitigating factors include:
– various ways to reduce or eliminate state: wicket 2.0 supports delayed session creation, stateless pages and stateless forms and you can spend time and energy reducing page state once you know which pages are hot. you can also use bookmarkable pages, which are naturally stateless in any version of wicket. of course, there’s a price to pay for optimization and i would argue that you should not prematurely optimize your wicket application until you know the costs.
– wicket 2.0 will have a second level cache that serializes (in a wicket-specific format for speed) extra page state to disk on a background thread to clear memory.
– wicket runs on terracotta, which provides large virtual heaps. this integration is very new and we don’t have any test data yet, but i think this has the potential to be a silver bullet for wicket memory issues. the reason is simple: terracotta virtual heaps ought to be a lot more granular and efficient than serialization. i would think terracotta ought to also be a better way to cluster wicket in general, particularly for failover.
– ultimately there is a tradeoff going on between the significant developer productivity yielded by a stateful, object-oriented web framework and wicket’s use of server memory. we’ve heard a few anecdotes about wicket’s productivity (for example, http://www.nabble.com/-Wicket-user–ui-framework-choice-t3137969.html and http://www.indicthreads.com/news/435/wicket_java_framework_saves_programming_time.html) suggesting roughly a 2X multiplier. and my suspicion is that the multiplier is even higher in maintainence than whatever it is during development because wicket code is so easily refactored. anyway, since developers are very expensive resources (maybe $150-200K per year including all expenses to a company like office space and benefits), you can buy quite a lot of hardware if you can build and maintain something twice as efficiently. a quad cpu dell box with a couple GB of ram these days is maybe $3000. if you saved one developer per year, $150K can buy 50 of those boxes per year. there is hosting to consider too of course, but the basic equation is still worth exploring.
I agree completely with eelco’s sentiments.
Two more mitigating factors:
– in our informal benchmark, wicket performance came out 17.4% faster than tapestry and 3-4X faster than JSF. wicket memory use makes it lighter on CPU.
– we’ve decided against client-side state because nobody on the team believes this is the best approach, but it would not be very difficult to implement this in the future if it turned out to be something worth exploring.
That was an eye opening equation Jonathan. Sometimes being too deep in technical analysis we tend to overlook these petty facts.
Pingback: Wickedly cool at Joed’s Stuff
Pingback: Spring vs JBoss, and why I don’t care about Sun standards « Incremental Operations
Very nice article peter.
very good web 2.0 java web layer stack.
Pingback: Until Lately » links for 2007-03-15
Pingback: Wicket vs. Spring MVC | bitwalker.nl
Pingback: JTrac UI makeover « Incremental Operations
very helpful points…! peter
Pingback: links for 2007-04-02 « Object neo = neo Object
This is a really useful blog entry. Many thanks for this critical review, you’ve saved me a lot of time.
I was about to embark on a new project using Spring MVC, as I am already quite familiar with the technology.
Having read you blog, you’ve managed to convince me to have a go at Wicket and to push my ‘not another framework’ bigotry to one side.
Thanks again!
Hi Peter,
I’ve really appreciated your post… After reading it carefully, however, a few doubts remain: how much of Spring have you actually put aside? I understand you’re keeping Spring in front of Hibernate. Are you keeping it in the middle tier as a container manager for your services? Maybe you’ve got rid of Spring MVC and WebFlow only… Is that true?
Thanks so much,
Cristina
Cristina,
I’m still using Spring mainly for dependency injection, declarative (AOP style) transaction management and Hibernate3 integration including the OpenSessionInViewFilter (which works well with Wicket). Spring-Modules are also being used for Lucene integration. Also worth mentioning are Spring’s helper classes for sending e-mail, setting up scheduled jobs etc.
Spring MVC is just a small part of the Spring Framework. For the record, I will be still using Spring MVC for implementing a REST kind of remote-API to the app because of how easy it is to extend the core framework.
So you are right, I moved the presentation layer away from Spring MVC / WebFlow and the other two layers still use Spring.
In one of your previous posts you mentioned Seam (and that you were going to give it a try)
Did you manage to do it?
/Manuel
No, not yet.
Hi, Peter what do you think about using JSF, Facelets and Ajax4jsf stack ? It gives great abstract for producing RIA’s, and easily integrate with Spring stack.
If I get time to try JSF which will be interesting considering I’m now familiar with Wicket – I’ll definitely post the details here. I am really interested in seeing how it compares head to head.
Hope to do this in the next week or so.
Pingback: A Wicket user tries JSF « Incremental Operations
really interesting, although i am new to java, but i can feel tat wicket is the future for web app.Emm…after reading ur article, i know i must learn wicket.Thanks for ur article.If there are any tutorial about wicket plz inform ya,thanks!
Great article.
Just wanted to mention that there are several projects that integrate wicket with popular javascript libraries (prototype, scriptaculous). might want to check them out instead of rolling your own.
Thanks Peter. I was really tired of using JSPs and Spring Webflow and looking at your article, now am gonna move to Wicket. I have started my development on this and *seriously* life is much better now :)
I’ve been casting about for a new framework for some months. I settled on Hibernate and Spring early, but choosing a web framework has taken a long time. I built fairly extensive prototypes with GWT and with JSF/Facelets, and I ultimately gave up on both. With GWT, synchronizing the state of domain objects between client and server side required me to write a synchronization framework, and my main goal is to avoid writing yet another framework myself. Also, domain objects on the client are effectively a cache, and I hate cache coherency bugs. With JSF, I got tired of having to think through reattaching my domain objects to my Hibernate session at the appropriate times. And even with Facelets (I can’t imagine how people use JSF with JSPs), JSF is a bit clunky.
I find Wicket to be a breath of fresh air. Its detachable models make keeping my domain objects in synch with the Hibernate session clean and simple. Wicket’s the one for me. However, that said, I do find the documentation frustrating. People mention friendly URLs, but I’ve not found how to get them, for example. Also, I’d really like to know what the life cycle of a page instance is. They plainly get cached in the session sometimes, but when exactly, and for how long? Why do I get “Page expired” messages so often when I use the back button? I’m really hoping Wicket in Action will put it all together clearly.
Why integrate Hibernate w/ any MVC framework?
Shouldn’t the persistence layer – implemented using Hibernate or whatever – be hidden behind a service layer? Services are exposed as Java interfaces (could be managed by Spring) and that’s the layer which used by ‘C’ in MVC.
So if you’d integrated w/ Spring, why expose Hibernate to MVC at all?
@Nikita
http://www.hibernate.org/43.html
While everyone is waking up to the blasphemous realization that ‘I possibly might not need to use Spring for everything’ you might like to check out our open source, light weight, dependency injection, ‘open session in view’ framework that implements the famous “exposed POJO model” pattern. It’s called expojo (http://expojo.com BSD, LGPL or Apache – take your pick)
It’s been used with everything from Wicket and Echo2 to JSPs without requiring any special framework dependent ‘adapters’.
It also provides a generic interface to transparent persistence so your apps can readily switch between Hibernate, JDO, JPA without requiring a major rewrite – and it does it all without requiring annotations.
And yes, I agree with Peter – after years of JSP/struts and then looking around at every dam Java UI framework under the sun I settled on Wicket – it rocks! If you’re not using it now I believe that there’s a 60% chance you will be using it within 12 months.
Hi there,
How am I able to integrate spring without using annotation? This is very interesting since my apps does not run on JDK 5. Can you point me to more information regarding this?
Thanks in advance
The Wicket documentation already has a section on Spring integration:
http://cwiki.apache.org/WICKET/spring.html
As I said in the blog post, I used an alternate option, you can find details on this mailing list thread:
http://www.nabble.com/spring-integration-question-t3013136.html
Example of real life usage:
http://fisheye3.cenqua.com/browse/j-trac/trunk/jtrac/src/main/java/info/jtrac/wicket/JtracApplication.java?r=1123
Ok thanks Thomas. I’m going to try it. Cheers.
Hi,
Thanks for the great article. It inspired us to use Wicket to port an existing application. We actually had a little Code Off going!
I am converting application written in wicket to spring mvc annotation so that action classes do not extend any classes.
@paul – if you don’t like extending classes then you are working with the wrong language – you should use COBOL. You don’t want to extend a class but having “import org.springframework.stereotype.Controller” is okay?
All the best for your project and whoever decided that MVC action classes of all things had to *not* extend any other class!
Could you give a an example/the code of how you delegated to Spring’s MessageSource instead of using Wicket’s own i18n?
@Martin
Sure. Have a look at lines 108 – 128.
http://fisheye3.cenqua.com/browse/j-trac/trunk/jtrac/src/main/java/info/jtrac/wicket/JtracApplication.java?r=1168
Thanks Peter, that looks ideal.
Hello Peter,
I got 2 questions for you:
1. What’s the reason you don’t like annotations?
2. Can I offer my knowledge in Java to you on the JTrac project?
Cheers!
@Andreas,
Annotations: They are okay, but just as a matter of principle if I can avoid them, I do. I don’t like them because
a) I don’t consider them pure Java
b) you have to recompile changes
c) they clutter the code
d) I don’t mind XML and find it surprising that people complain about it (heck I haven’t even switched to the new Spring 2.0 XML)
e) especially in POJOs you end up importing a dependency WTF!
f) inheritance is kind of broken
g) because of the hype I see newbie programmers blindly adopting it – see comment #48 *rolls eyes*
h) I personally prefer Spring to using EJB3 and Spring does not *require* annotations, which makes me like it even more
i) There are developers still stuck on JDK 1.4 for various reasons
j) With XML you can consolidate your config in a central place, great for readability and understanding the architecture if new to a project. But with annotations, your config is scattered here and there.
Regarding JTrac, you are welcome to submit patches, there are a few already. I have not opened up commit rights yet, but I’m exploring the options.
Thanks for sharing your thoughts on annotations Peter.
By the way, I might be wrong here, I don’t think you must use annotations for EJB3. You could still use the ejb-jar.xml.
Anyways, I like Spring and have done work with Spring since 2003. Only “bad” thing about Spring is that I feel that the framework got too big… still not bad but I lost focus a few years ago ;-)
I have a look at what I can offer regarding JTrac and maybe submit a patch or two.
Cheers!
Pingback: Never install NetBeans again! « Incremental Operations
Pingback: IT managers - let the Web 2.0 help you to make faster decisions and save money on POC’s and long investigations « Ha’s Blog
Peter, thanks for the great post and I feel lucky to come across it since I am looking for something “better” than Spring MVC. I have two questions:
1. do you think Validation (Commons Validator and Valang) from Spring Modules and Sitemesh can integrate well with Wicket? Or Does Wicket have similar equally powerful/useful tools? As you know, Validation from Spring Modules can generate both client-side and server-side validation.
2. I find Spring MVC’s property edit is very useful tool. Suppose you have a dropdown list in a form and each option in the list corresponds to an object. In this case, property editor is quite convenient and you can IOC it to any form that has the same dropdown list.
How do you do the same thing in Wicket?
Thanks in advance!
David
@David,
I have been using Wicket extensively now for more than a year and I feel ever so strongly that Wicket is far better than the alternatives – so you are on the right track :)
1. Integrating anything into Wicket is easy but I personally prefer server-side validation and have never tried client-side, you can also have a look at this blog post for more discussion:
http://www.jroller.com/wireframe/entry/wicket_client_side_validation
I would lean towards using Ajax or JS widgets for form validation.
2. You can do the same thing and more in Wicket. You should have no trouble migrating your code from Spring MVC, Wicket has excellent POJO binding support. I think you are referring to registering custom editors, now since Wicket is a component based framework and handles state for you – you don’t need to do all that work any more.
For example for getting Spring MVC to work properly with drop-downs or multi-select controls that were backed by your custom domain objects, you had to register something like this on a form:
http://fisheye3.cenqua.com/browse/j-trac/trunk/jtrac/src/main/java/info/jtrac/util/ItemUserEditor.java?r=56
But in Wicket, when you add a drop-down-choice component to a form, you just pass a List<MyPojo> and when the form is submitted you will be able to get the value of the selection straight away. No more worrying about calls to formBackingObject!
Peter,
Thanks for your prompt feedback!
Have you ever tried Sitemesh in your Spring applications? Can I continue to use Sitemesh in Wicket?
All the best!
David
No, never tried Sitemesh. My take on it is that it is a work around for the lack of templating in JSP. Wicket’s markup inheritance works great for things like having a common header / footer template for all pages. Also the framework natively allows you to composite a page out of multiple panels with full control over the layout.
But Wicket can co-exist with Sitemesh, I have seen messages on the Wicket mailing list to that effect.
Peter,
I bought the PDF book called Enjoying Web Development with Wicket and quickly went through it. Here is my first impression and it could be wrong. I feel Wicket is flexible and takes care of many things a developer has to do in Spring MVC. Somehow, Wicket seems too ambitious, which I feel is a bad sign. Example: Wicket tries to do Ajax part, which I feel makes the programming verbose and learning-curve tall. I feel Ajax is best left to Prototype, Dojo, etc. Feel free to comment and I love to hear from you.
Regards.
@David,
Well, I used to feel the same way. Quoting from the blog post:
And you can read the rest of my thoughts under the “Ajax” heading in the blog post. I too initially felt that Ajax should be left to other frameworks and I mentioned this in a previous blog post also.
Wicket does not prevent you from using Prototype or Dojo and I am willing to bet that no other framework makes integrating a third-party javascript library easier. I have wrapped a couple of Yahoo UI components with ease in my current project. Wicket solves the problem of how multiple components on a page can ‘contribute’ js or css to the HTML header in such an elegant way that I feel no book, tutorial or blog post can do it justice, you have to experience it for yourself!
You don’t need to use the Ajax components of Wicket but when you do – things work without you having to write a single line of javascript. Being too ambitious is one thing, but what if Wicket lives up to its promise? Try it and see :)
Peter, thanks for your feedback. Glad to know you had similar feel before. I can feel the power of Wicket. However, I do feel the programming is a LOT more complicated because of so many things Wicket attempts to do. I will do some excercises.
BTW, is it possible to for you to share your Acegi integration code?
Did you ever use displaytag with Wicket?
Or struts-menu?
Integration with the frameworks/tools I used with Spring is another concern I have.
Thank you!
You can download the source code of JTrac which includes Acegi integration. You won’t be able to use display-tag or struts-menu because those are JSP tag libraries. IMO you won’t miss them – I guess the best thing is to do a proof of concept and you can use the Wicket mailing list for help.
Peter, thanks for the tip. Best, David
Peter, I expressed some concerns about Wicket at Wicket’ users mailinglist. I copied here and hope to hear from you:
I am migrating from JSP+Valang+…+SpringMVC to Wicket
and am also still evaluting it. So far so good until I
saw this instance about using Form Validator to
validate two related form fields.
Problem (p81-82, book Enjoy Web Development with
Wicket, PDF version only):
Suppose a postage calculation form has two fields that
accept weight and patron discount code. For a
particular patron p1, you will never ship a package
that is weighted more than 50kg. Here is the code from
the book:
public class LightValidator extends
AbstractFormValidator {
private TextField weight;
private TextField patronCode;
public LightValidator(TextField weight, TextField
patronCode) {
this.weight = weight;
this.patronCode = patronCode;
}
public FormComponent[] getDependentFormComponents()
{
return new FormComponent[] { weight, patronCode };
}
public void validate(Form form) {
String patronCodeEntered = (String)
patronCode.getConvertedInput();
if (patronCodeEntered != null) {
if (patronCodeEntered.equals(“p1”)
&& ((Integer)
weight.getConvertedInput()).intValue() > 50) {
error(weight);
}
}
}
}
I have the bad feeling about this way of validation
1. It is too much coding. Anybody used Valang in
Spring Module? By using Valang, the validation code is
much clean and a lot fewer and you dont need to create
a class simply for this simple validation.
2. Valang covers both client AND server-side
validation. Please note that client-side validation is
equally important as server-side’s. I feel it is a
must for web apps in terms of user experience.
3. In Valang + Spring MVD, you have all the validation
code for a form in one place in stark contrast to
spreading it in “controller” code as in Wicket and
mixing validation code with visual manipulation code.
Valang’s way is much easier to understand and
management.
So in terms of elegance, productivity, management,
…, I am not sure Wicket’s is right.
Can Wicket provide a better solution?
I would like to share my concern regarding the
Wicket’s WebPage, where you put a form’s code for some
visual aspects, validation, ajax, etc. in one place. A
big object. I feel it is too ambitious and it looks
like spaghetti code and mixes concerns/modules in one
place. Comment?
I am very new to Wicket and don’t know the best ways
of using Wicket. I love to hear from expereinced
users/guru here.
Thanks for your input!
Warm regards,
David
@David – I think you have got a few answers already:
http://www.nabble.com/Advisory-question-to17017178.html#a17022506
… and do check out the presentation I uploaded here for more details on “Why Wicket”:
Pingback: Tapestry vs Wicket « Crónicas de un Arquitecto de Software
vey valueable article! I’ve come from Tapestry, and been thinking to use Wicket for a long time. Now, I’ve prepared to use Wicket
Thanks Thomas!!
Pingback: Onaswarm links for Thursday, 10 July 2008 « David’s Blog - What Did You Think?
Pingback: IT pro life
Peter,
I’m part of a largish team (about half professionals and half students) that is about to migrate a large application from Struts 1.2.9 to …something else.
The two most likely candidates are Spring MVC (Spring 2.5 with 3.0 just around the corner) or Wicket (1.3.5 out, 1.4 release date unknown). My post here, in Wicket evangelist territory, is designed to look for reasons to choose Wicket over Spring MVC as our new framework.
Some background: While I’ve been a developer for far more years than I care to remember, I’ve not been as active in front end web development up till this project (Call me Susan the Plumber – I’ve been doing backend stuff for years) I have lots of practical experience migrating software in general, but no specific experience with web MVC applications.
On the other hand, my colleague with substantial web development experience really likes Wicket, and of course, your thorough and article postings about Wicket make a strong case for using this framework.
But what keeps me up worrying about the choice is the migration process from Struts 1.x. We have a large team to retool from the Struts 1.X approach, and Spring MVC offers some obvious support for migrating from Struts 1.X. We need to be able to migrate in bitesize chunks from Struts to the new framework. What support is in Wicket for such an incremental migration?
The comparisons I’ve seen on the web date back to 2007 or so, and compare earlier versions of Wicket/Spring. But both Wicket and Spring MVC have released new versions since your initial posting of this article back in March ’07. Meanwhile, Spring 3.0 and the newest version of Spring MVC is around the corner (Milestone should be out by SpringOne in Dec ’08 and theoretically the final 3.0 release in January. The Spring juggernaut rolls on! By comparison, Wicket 1.3.5 just came out a couple weeks ago. However, there’s no data on when the Wicket 1.4 release will come out and it seems like there is still some controversy over generics. An indicator that makes me a bit nervous is that the QuickStart example on the Apache site doesn’t compile under 1.4M3). If the standard example on the Wicket project site still doesn’t compile, it raises a red flag for me.
So as a Wicket advocate do you have some quick advice to convince me that Wicket offers an equally good migration path out of Struts 1.x to Wicket nirvana? I’m comparing to the explicit classes and such for moving from Struts 1.x that are part of the Spring Framework and the current reference manual, which make such a migration more obvious. And I am a Wicket novice, just now playing around with the framework a bit, whereas I have used Spring Core in previous projects and while Spring MVC is new to me, Spring IoC is not.
Obviously our choice of framework depends on many factors besides ease of migration, including analysis of our existing application, and looking at the shortfalls that Struts had, and seeing what new framework addresses those best, etc. etc. There is no one right answer and you can only speak to some generalities.
But just in terms of migration from Struts to the current version of Spring MVC and Wicket, how would you rate the support in incremental migration from the old MVC framework to the new component based framework?
Any advice is most gratefully appreciated as we analyze and make a choice. The good thing is we have a lot of good choices of frameworks to choose from, and anything we do pick is not likely to be a bad choice. We’re just looking for the best choice, which kind of chocolate cake to use for our dessert framework if you will :-)
Thanks in advance.
Susan
Susan,
I migrated JTrac in bite size chunks actually. You can have both the Struts ActionServlet as well as the WicketFilter running in the same web.xml file but mapped to different URLs. For me it was the Spring MVC DispatcherServlet instead of ActionServlet. You should be able to easily do session co-existence using for e.g. the WicketSessionFilter.
First, you do need to make a fundamental choice whether you want to go action-based (Spring MVC) or component-based (Wicket). The presentation here may help you make a choice. If you feel that your team is more comfortable with action-based approaches (like Struts) you may very well choose Spring MVC.
I am using Wicket 1.3 in production and the fact that there has been a recent maintenance release is actually good news to me. My plan is to wait until 1.4 goes beta or final and then migrate. The discussions about generics in 1.4 have been very transparent on the mailing list and I trust the Wicket team will strike the best possible balance. My experience with Wicket upgrades in the past has been positive, for example this page was all I needed to migrate from 1.2 to 1.3. And I have to say that since all the code is in Java, you can really truly leverage your IDE for re-factoring. You can see why it is important that Wicket takes advantage of generics as much as possible.
I am not aware of explicit support in Spring for migrating from Struts, can you point me to some documentation? Also please consider posting to the Wicket mailing list to get more opinions. Do have a look at this recent thread where someone was asking for help on choosing between Wicket and Spring MVC.
http://www.nabble.com/Wicket-versus-Spring-MVC-td20021146.html#a20021146
Peter,
I derived that action servlet/Wicket filter setup just yesterday, based on my working through some of the examples from the Manning WICKET IN ACTION book. I think that will indeed be the way we keep things going in parallel. It’s good to know I found the official right way!
Re: your comment about whether I feel our team is more comfortable with action-based approaches vs. component: you’ve hit the nail on the head. We have a lot of folks who would need to learn a new approach and that is a cost to consider. Our decision about frameworks, based on a body of existing code, and trained developers is different than what we might make for a new clean-slate project. I’ll look over your presentation in some detail now that I have a little bit o wicket under my belt.
I also talked with an old colleague of mine, a guy with several Java startups under his belt, who looked at Wicket some months ago, and pronounced it way cool, but…he rejected it because he wasn’t sure of the critical mass behind the project and the ability for less experienced developers to learn it easily. I can understand that hesitation. Wicket is not the 500lb gorilla here. We want a framework for the long haul and there is always a risk going with something slightly off the beaten path for the long haul. Lack of mainstream adoption is of course NOT a reason to ignore Wicket, but it is something I feel we need to keep in mind.
And in retrospect, I overstated the level of migration support in migrating from Struts to Spring. I was basing this on Chapter 15 of the Spring 2.5.5 manual (http://static.springframework.org/spring/docs/2.5.x/reference/web-integration.html
As I look that doc over, what this really says is that there are classes to make Struts more accessible to Spring Core, but it doesn’t assist in the migration from Struts to Spring MVC. Chalk it up to information overload on too many new concepts in the Web app development world for the plumber!
And that thread about Wicket vs. Spring MVC? That’s my aforementioned colleague who likes Wicket a lot :-) He’s looking at Spring MVC right now and I’m looking at Wicket right now.
Thanks a bunch for the quick response. I’ll look over your presentation again, and if you’d like, I’ll put some feedback here on this comment when we come to closure.
Pingback: Some wicket impressions | Molindo Techblog
Spring MVC rules !!
compared to spring mvc (2.5>) wicket looks very awkward
@sj2004 – yeah, right.
Since its so Java heavy, how well does wicket work with a team that has UI designers?
@UI Designer
Not just Java – Wicket works with plain HTML also, heavy or light or CSS is up to you.
For more information you should read this post which specifically discusses the role a UI Designer plays in a Wicket project:
http://www.mysticcoders.com/blog/2009/03/09/5-days-of-wicket-day-1/
Hi, what do you think about comparition thelatest spring MVC version and Wicket. What do you think about it, whitch of them will be most popular ?
Best regards
If you want to use component oriented framework, you should use JSF instead of wicket, unless you are already comfortable with wicket.
@sj – completely disagree. Please see this blog post:
https://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/
Nobody mentions anything about developing in the Portlet API 1.0 environment. I use Spring WebFlow with portlets on WebSphere and jQuery for JavaScript/AJAX. Would Wicket work here? Thanks,
John
I am using Wicket 1.2 and I need to implement workflow in my application. Could anybody please guide me how to integrate jBPM or any other workflow with wicket.
Hi,
Very nice article, Congrats
I just gone through some samples of Wicket and Spring roo
I found both wicket and Spring roo are best frameworks
what do you think, which is better.
Rohit
Hi, thanks a lot for the article!
Have you tried the Apache Click Framework[1]?
I’m impressed by their simplicity!
Regards,
Gilberto
[1]http://click.apache.org
The article doesn’t really cover the trade-offs between these frameworks? Perhaps Andre’s article, along with this one, help create a balanced view? http://andrekampert.blogspot.com/2011/10/java-web-frameworks-how-to-choose.html
Perhaps. So you are implying that my article does not provide a balanced view eh ;)
Well, it is very easy to come up with a list of 10 points based on subjective personal prejudices and pass it off as a guide to choosing web frameworks. It is even easier to come up with a disclaimer that for the final decision “it depends”, you have to “choose for yourself” blah blah blah.
I wish more people would try to write code instead of just faffing around, but that’s just me ;)
Hi Peter
I have tried wicket and it feels great.
all the advantajes that you mention are true.
now im developing an application with Spring MVC, and i really miss wicket.
i think the simplicity with ajax and reuse components its the strongest thing that i found in wicket.
but, can you tell me any disadvantage?
Regards.
Pingback: Confluence: External Projects
Pingback: Confluence: Product Info
Pingback: Confluence: Product Info
Pingback: Confluence: SKIDATA Software House
Pingback: Confluence: PTIPS
Pingback: Confluence: Product Info
Pingback: My little caravan School Holiday craft parties for children
ar|splendid|striking|stunning|superb|unique|wonderful}
The real mvc framework is the collection of all Java EE edition from Oracle
Pingback: How to inject services using Wicket+Spring – GrailsLog
The betting procedures also vary amongst different poker video games. You require to have some great tips to perform on line casino online neat and clean. The purpose was mistaken identity but was acquitted.