here is really what it comes down to: springmvc/struts/etc are geared towards building stateless applications. building something statefull is hard in these frameworks because the burden of having to juggle state is on you and it is hard/impossible to get right when doing manually.
wicket is geared towrads building stateful applications. it takes care of the state juggling so you dont have to. it is, however, hard to build stateless applications in wicket because you have to take care to use only stateless components - and even then you are back to having to juggle state yourself. an important, but peripheral point, is that wicket takes full advantage of OOP. frameworks like springmvc/struts are highly procedural, they give you a hierarchy and you usually just extend it one level deep. in wicket you have to build custom class hierarchies so you can factor out all the common bits and pieces of your application. do your developers know how to do this properly? if you showed your developers the repeater hierarchy of repeatingview through datatable and asked them to choose a base class for their usecase would they complain that there are too many classes to choose from? this is quiet a common complaint on this list by people who come from struts and friends :) so in the end you have to look at the kind of application you are building and the type of developers you have, and pick the framework based on that. -igor On Thu, Oct 16, 2008 at 12:28 PM, Richard Allen <[EMAIL PROTECTED]>wrote: > Hello, > > We have stateful, desktop-like Web applications based on Struts 1.x. We > want > to migrate them to a modern Java Web framework so we are trying to choose > what framework to use. The decision will be left up to myself and another > colleague with buy-in from other key people. > > The other colleague wants to use Spring MVC, which she just received > training on from SpringSource. I want to use a component-based framework > like Wicket. I think Wicket looks great, so I have been telling her that I > think we should consider using it instead of Spring MVC. I think it is a > better fit for the type of applications we produce. > > My colleague emailed the instructor from SpringSource and asked what he > thought of us migrating to Wicket instead of Spring MVC. His response is > below with my comments inlined. I would appreciate any convincing comments > from Wicket experts. > > Thanks, > Richard Allen > > Rich, > > Some background on what I am forwarding along... > > During last week's Spring Rich Client class I took full advantage of the > fact I had unlimited access to a SpringSource consultant/instructor. > > When he asked people why they were there, I brought up that we were > transitioning from Struts 1.X to something else, and the likely > candidates were Spring MVC and Wicket. > > Many of my questions to him over the course of the 4 days were focused > on that particular topic. > > And when he offered up his email address for contacts after the > class, I wrote it down and got back in touch with him this week (getting > our money's worth out of the face time, I like to think!) with some > well-deserved adulation for the course, some questions about the Spring > 3.0 release schedule and finally, a summary of the Spring MVC vs. Wicket > decision we face, trying to synthesize what I took away from the class. > > *** > > Specifically, in my email, I asked the question that you, an > experienced web developer, posed to me about moving our Struts app to > another MVC oriented framework (Spring MVC) vs. moving to a component > framework (Wicket). What I heard you say in so many words earlier this > week, was: > > "Why switch to something that is a little better than Struts 1, such > as Spring MVC, instead of moving to something altogether better like > Wicket?" > > And that is indeed a good question that cuts to the heart of the matter > we must decide going forward. > > We have a lot invested in MVC technology right now, and our developers > understand this approach. My instincts and experience on other > migrations say that a transition from Struts to Spring MVC will be an > easier migration than a movement to a different approach than Wicket. > > Wicket *is* an MVC framework, like Java Swing is an MVC framework. I would > argue that Wicket is *more* of an MVC framework in the classical sense than > Struts or Spring MVC. There is no doubt that Wicket absolutely does a > better > job of separation of concerns (one of the key philosophies behind MVC) than > any JSP/Velocity/Freemarker based framework. If developers are comfortable > in Java and OO (ours should be), and if they have ever done any Java Swing > development (many of us have because we have Swing applications), then > Wicket will feel natural. It is an easy transition. I do not believe that > getting our developers up to speed on Wicket will be as difficult as you > think. I believe, as a whole, Wicket is less complicated than Struts or > Spring MVC. If you have ever tried it, you would know what I mean. You > should read this page: http://wicket.apache.org/introduction.html. > > And besides, Spring MVC is significantly different than Struts 1.x -- so > much so that I think the transition from Struts 1.x to Spring will be > nearly > as tough. The only thing you gain is the overall framework concept: > action-based. Once the developers understand the component-based concept > (which is not hard to grasp -- think Java Swing), than you no longer get an > experience advantage by using Spring MVC. > > But as you correctly pointed out, it's not just the ease of migration > that drives our choice of technologies (again I'm paraphrasing what I > heard you say) > > "If you end up with a product that is easier to maintain and grow in > the long haul, it's worth it to pay the upfront cost in the migration > process to get there." > > Absolutely true - we need to focus on the long term, not the short term, > so that the redesigned framework that results will be as solid as > the framework you and the original team put together based on Struts 1 > however many years ago that was. > > But when I think about long term solutions, my sense is that Spring MVC > addresses the shortfalls in the Struts approach head on. Plus, the > overall integration of Spring MVC with other aspects of the Spring > Framework offers us still more options down the road. > > I do agree that Spring MVC addresses the shortfalls in the Struts > approach. > However, Spring MVC does not address the short-falls in the action-based > approach for a stateful, dynamic, desktop-like Web *application*. I believe > that is one reason why Sun developed JSF. > > I'm still studying Spring MVC, so the jury is out, but as of yet I do not > see how Spring MVC's integration with Spring Core provides you any more > value than Wicket's integration with Spring Core. > > Therefore, a migration to Spring MVC would not be a solution that is > just a little bit better, but a genuinely good solution which can stand > on its own merits as a robust and maintainable approach. > > True, but I think there are better solutions for our problem. > > *** > > So here's what he had to say about Spring MVC vs. Wicket choice. See > what you think - his arguments make sense to me. > > Note his comments about JSPs...is something like Freemarker a > replacement technology for JSPs we should consider in this migration? > > Freemarker and Velocity do some good in improving over JSP, and we could > readily use them now with Struts 1.x. However, from what I have seen, they > are not as clean/easy-to-maintain a solution as Wicket or Tapestry for > templating. > > With regards to Spring MVC and Wicket, firstly as you rightly pointed > out, to say that Spring MVC is slightly better than Struts is incorrect. > It is more correct to say Spring MVC was built on the same philosophy > but otherwise sits on a much stronger architectural foundation. This is > what makes it easiest to understand for Struts developers while at the > same time being very versatile. And by the way this philosophy, the > "request-driven approach" is not about to go defunct as Struts did. The > stateless approach is one of the 4 REST principles. > > The "request-driven approach" is certainly a good solution for many > applications. I just don't think it is the correct solution for ours. > > Consider how the Spring MVC DispatcherServlet can be used in all these > scenarios: HTML browser requests, remoting requests (HttpInvoker, > Burlap), Web Service requests (SOAP). Additionally it serves as a > foundation of both request-driven (Spring MVC) and stateful JSF requests > (Spring Faces). On the view side unlike Struts it was built to support > many technologies. Indeed JSP's are not the best markup and you will > read that a lot in Wicket marketing. If that is a main concern suggest > using Freemarker as templating technology. It is supported in Spring > MVC and so is Velocity. Another suggestion is jspx. > > I went actively looking for a better solution to JSP several years ago. I > didn't happen upon Wicket until about 7 months ago. So it's not "Wicket > marketing" that has driven me to the conclusion that JSP is not the best > solution. It's having developed in JSP for several years that lead me to > that conclusion. > > In regards to jspx, the examples I have seen of writing JSP in XML, and the > examples that I wrote myself, created very ugly code. > > This flexibility has found Spring MVC well suited for both Ajax > interactions and for REST applications. Version 3.0 of Spring MVC will > have slight enhancements that make it a top choice. I'm not sure how > Wicket competes here. I suspect it doesn't quite because it is much more > stateful. > > It is certainly correct that Wicket is a stateful framework, but so are * > our* applications. We make significant use of server-side state > (HttpSession), and transitioning to a full REST application would be a > large > transition. If you know REST, you know that there is no server-side state, > but instead the state must be maintained via URL parameters. I think the > concept of REST is great for certain scenarios, but I do not think it is > fully appropriate for a desktop-like Web application. For example, in our > applications, REST would be useful for providing bookmarkable URLs to GET > documents. And that is elegantly supported by Wicket: > http://stuq.nl/weblog/2008-06-20/create-restful-urls-with-wicket > > For Ajax, there is now Spring JavaScript as you know and Spring will > continue to expand its support in this area integrating more of Dojo and > taking the best-of-breed approach. I know that you're on Ext right now > but Wicket custom approach isn't going to help with that either. > > Wicket has great support for integrating other JavaScript libraries. There > is already integration with YUI, Dojo, Prototype, Scriptaculous, and some > other libraries (see > http://wicketstuff.org/confluence/display/STUFFWIKI/Wiki). From what I > have > read, the next major version of Wicket will use YUI internally. > > In the end customers we talk to have chosen Spring MVC because it has a > much larger community and this is something that is very important if > you put in the context of migrating from one framework to another. > > I don't know how big the Spring MVC community is if you separate out those > that just use Spring Core and not Spring web features. I do know that > Wicket > has a significant and very active community. Just post a question on the > mailing list and see how fast you get a response. Wicket is a top-level > Apache project and is not going to disappear. Besides, if we were solely > judging by user base, then JSF would clearly be the winner. > > The burden is on those proposing Wicket to demonstrate it should be > chosen > over Spring MVC that is a more natural fit on *multiple* levels. >
