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]
