You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Richard Allen <ri...@gmail.com> on 2008/10/16 21:28:35 UTC
Wicket versus Spring MVC
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.
Re: Wicket versus Spring MVC
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
And if you like to repeat yourself fine.. Otherwise put it somewhere
people can find it like on the wiki:) I do think theres a page for it..
Apparently I didnt pick it up the other times..
Oh and have a nice weekend:)
Igor Vaynberg wrote:
> 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 <
> nino.martinez@jayway.dk> 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
>>> <ri...@gmail.com>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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket versus Spring MVC
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <
nino.martinez@jayway.dk> 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
>> <ri...@gmail.com>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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket versus Spring MVC
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
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
> <ri...@gmail.com>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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket versus Spring MVC
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<ri...@gmail.com>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.
>