Joel, What advantage does Tapestry 5 provide you over Wicket for your front office pages?
Thanks, Richard Allen On Sun, Oct 19, 2008 at 8:17 AM, Joel Halbert <[EMAIL PROTECTED]> wrote: > We're actually using two web frameworks in our application, depending on > the type of page. > > Our application basically consists of two types of page: > > * "front of shop / front office" pages (these are the ones clients see like > search results, product listings - characterised by high load & page > impressions, relatively simple page logic and fewer components per page) > > * "back office" pages (these are the behind the scenes pages used to manage > the shop, are more complex, require more state and have more complex logic > and backing functionality and complex page component interactions). > > > We basically use Wicket for the back office pages and Tapestry5 for the > front office pages. > > I find this a great fit, both frameworks are well written and easy so we > get to take advantage of the best bits of both! > > > > > [EMAIL PROTECTED] wrote: > >> Igor, I agree with Nino. >> >> What about posting something like that on wicketinaction.com? :-) >> >> Cheers, >> Bruno >> >> On Oct 17, 2008 2:41pm, 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] >>> >>> >>> >>> >> > -- > SU3 Analytics Ltd > 61b Oxford Gardens > W10 5UJ > London > > Tel: +44 20 8960 2634 > Mob: +44 75 2501 0825 > www.su3analytics.com > > SU3 Analytics Ltd is a company registered in England and Wales under > company number 06639473 at registered address 61b Oxford Gardens, London W10 > 5UJ, United Kingdom. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
