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]
>
>

Reply via email to