Looking for a Wicket training in France (paris) and argument for Wicket versus Spring MVC

2012-04-04 Thread Yves-Marie LAINÉ
Hi all,

I'm working with wicket since 2 years, and I'm convinced by this great
fremework. Today, in my company we are facing the choice of a new web
framework in order to replace our old Struts 1... The debate turn arround
Spring MVC or Wicket. I spend one day to show Wicket to my colleagues, but
they only knows struts 1 and it's really hard to make them feel the power
of Wicket. After a long discussion, my boss decided to give Wicket a second
chance and proposed me to find good training to try to make them adhere. I
think this choice is really important, more particularly when leaving
struts 1 after 10 years...

So I need your Help ! If someone has feedback on a good training in paris,
it's more than welcome.

And any good agument for Wicket versus Spring MVC is welcome too.

(sorry for my english)

Regard,
Yves-Marie LAINÉ


Re: Looking for a Wicket training in France (paris) and argument for Wicket versus Spring MVC

2012-04-04 Thread Yves-Marie LAINÉ
I was looking to it. Thanx Martjin. (and thx for your book ! ;-) )


2012/4/4 Martijn Dashorst martijn.dasho...@gmail.com

 http://www.zenika.com/formation_wicket_avance.html

 Martijn

 2012/4/4 Yves-Marie LAINÉ ymla...@gmail.com:
  Hi all,
 
  I'm working with wicket since 2 years, and I'm convinced by this great
  fremework. Today, in my company we are facing the choice of a new web
  framework in order to replace our old Struts 1... The debate turn arround
  Spring MVC or Wicket. I spend one day to show Wicket to my colleagues,
 but
  they only knows struts 1 and it's really hard to make them feel the power
  of Wicket. After a long discussion, my boss decided to give Wicket a
 second
  chance and proposed me to find good training to try to make them adhere.
 I
  think this choice is really important, more particularly when leaving
  struts 1 after 10 years...
 
  So I need your Help ! If someone has feedback on a good training in
 paris,
  it's more than welcome.
 
  And any good agument for Wicket versus Spring MVC is welcome too.
 
  (sorry for my english)
 
  Regard,
  Yves-Marie LAINÉ



 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-- 
Yves-Marie LAINÉ


Re: Wicket versus Spring MVC

2008-10-20 Thread Richard Allen
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 

Re: Wicket versus Spring MVC

2008-10-17 Thread Igor Vaynberg
didnt put it anywhere, didnt think it was anything special. i said the same
thing plenty of times in the past.

-igor

On Fri, Oct 17, 2008 at 10:41 AM, Nino Saturnino Martinez Vazquez Wael 
[EMAIL PROTECTED] wrote:

 Good mail Igor.

 Did you place it on the wiki, or a blog somewhere? It's very sound
 arguments. Especially the part about statefull/stateless web applications.



 Igor Vaynberg wrote:

 here is really what it comes down to:

 springmvc/struts/etc are geared towards building stateless applications.
 building something statefull is hard in these frameworks because the
 burden
 of having to juggle state is on you and it is hard/impossible to get right
 when doing manually.

 wicket is geared towrads building stateful applications. it takes care of
 the state juggling so you dont have to. it is, however, hard to build
 stateless applications in wicket because you have to take care to use only
 stateless components - and even then you are back to having to juggle
 state
 yourself.

 an important, but peripheral point, is that wicket takes full advantage of
 OOP. frameworks like springmvc/struts are highly procedural, they give you
 a
 hierarchy and you usually just extend it one level deep. in wicket you
 have
 to build custom class hierarchies so you can factor out all the common
 bits
 and pieces of your application. do your developers know how to do this
 properly? if you showed your developers the repeater hierarchy of
 repeatingview through datatable and asked them to choose a base class for
 their usecase would they complain that there are too many classes to
 choose
 from? this is quiet a common complaint on this list by people who come
 from
 struts and friends :)

 so in the end you have to look at the kind of application you are building
 and the type of developers you have, and pick the framework based on that.

 -igor

 On Thu, Oct 16, 2008 at 12:28 PM, Richard Allen
 [EMAIL PROTECTED]wrote:



 Hello,

 We have stateful, desktop-like Web applications based on Struts 1.x. We
 want
 to migrate them to a modern Java Web framework so we are trying to choose
 what framework to use. The decision will be left up to myself and another
 colleague with buy-in from other key people.

 The other colleague wants to use Spring MVC, which she just received
 training on from SpringSource. I want to use a component-based framework
 like Wicket. I think Wicket looks great, so I have been telling her that
 I
 think we should consider using it instead of Spring MVC. I think it is a
 better fit for the type of applications we produce.

 My colleague emailed the instructor from SpringSource and asked what he
 thought of us migrating to Wicket instead of Spring MVC. His response is
 below with my comments inlined. I would appreciate any convincing
 comments
 from Wicket experts.

 Thanks,
 Richard Allen

 Rich,

 Some background on what I am forwarding along...

 During last week's Spring Rich Client class I took full advantage of the
 fact I had unlimited access to a SpringSource consultant/instructor.

 When he asked people why they were there, I brought up that we were
 transitioning from Struts 1.X to something else, and the likely
 candidates were Spring MVC and Wicket.

 Many of my questions to him over the course of the 4 days were focused
 on that particular topic.

 And when he offered up his email address for contacts after the
 class, I wrote it down and got back in touch with him this week (getting
 our money's worth out of the face time, I like to think!) with some
 well-deserved adulation for the course, some questions about the Spring
 3.0 release schedule and finally, a summary of the Spring MVC vs. Wicket
 decision we face, trying to synthesize what I took away from the class.

 ***

 Specifically, in my email, I asked the question that you, an
 experienced web developer, posed to me about moving our Struts app to
 another MVC oriented framework (Spring MVC) vs. moving to a component
 framework (Wicket).  What I heard you say in so many words earlier this
 week, was:

   Why switch to something that is a little better than Struts 1, such
 as Spring MVC,  instead of moving to something altogether better like
 Wicket?

 And that is indeed a good question that cuts to the heart of the matter
 we must decide going forward.

 We have a lot invested in MVC technology right now, and our developers
 understand this approach. My instincts and experience on other
 migrations say that a transition from Struts to Spring MVC will be an
 easier migration than a movement to a different approach than Wicket.

  Wicket *is* an MVC framework, like Java Swing is an MVC framework. I
 would
 argue that Wicket is *more* of an MVC framework in the classical sense
 than
 Struts or Spring MVC. There is no doubt that Wicket absolutely does a
 better
 job of separation of concerns (one of the key philosophies behind MVC)
 than
 any JSP/Velocity/Freemarker based framework. If developers are
 comfortable
 in Java 

Re: Re: Wicket versus Spring MVC

2008-10-17 Thread bruno . borges

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 

Re: Wicket versus Spring MVC

2008-10-17 Thread Nino Saturnino Martinez Vazquez Wael
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 
[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 

Wicket versus Spring MVC

2008-10-16 Thread Richard Allen
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 

Re: Wicket versus Spring MVC

2008-10-16 Thread Igor Vaynberg
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