didnt put it anywhere, didnt think it was anything special. i said the same thing plenty of times in the past.
-igor On Fri, Oct 17, 2008 at 10:41 AM, Nino Saturnino Martinez Vazquez Wael < [EMAIL PROTECTED]> wrote: > Good mail Igor. > > Did you place it on the wiki, or a blog somewhere? It's very sound > arguments. Especially the part about statefull/stateless web applications. > > > > Igor Vaynberg wrote: > >> 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. >>> >>> >>> >> >> >> > > -- > -Wicket for love > > Nino Martinez Wael > Java Specialist @ Jayway DK > http://www.jayway.dk > +45 2936 7684 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
