Re: Looking for a Wicket training in France (paris) and argument for Wicket versus Spring MVC
I was looking to it. Thanx Martjin. (and thx for your book ! ;-) ) 2012/4/4 Martijn Dashorst > http://www.zenika.com/formation_wicket_avance.html > > Martijn > > 2012/4/4 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É > > > > -- > 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: Looking for a Wicket training in France (paris) and argument for Wicket versus Spring MVC
http://www.zenika.com/formation_wicket_avance.html Martijn 2012/4/4 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É -- 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
Looking for a Wicket training in France (paris) and argument for Wicket versus Spring MVC
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: Wicket versus Spring MVC
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
Re: Wicket versus Spring MVC
We're actually using two web frameworks in our application, depending on the type of page. Our application basically consists of two types of page: * "front of shop / front office" pages (these are the ones clients see like search results, product listings - characterised by high load & page impressions, relatively simple page logic and fewer components per page) * "back office" pages (these are the behind the scenes pages used to manage the shop, are more complex, require more state and have more complex logic and backing functionality and complex page component interactions). We basically use Wicket for the back office pages and Tapestry5 for the front office pages. I find this a great fit, both frameworks are well written and easy so we get to take advantage of the best bits of both! [EMAIL PROTECTED] wrote: Igor, I agree with Nino. What about posting something like that on wicketinaction.com? :-) Cheers, Bruno On Oct 17, 2008 2:41pm, Nino Saturnino Martinez Vazquez Wael <[EMAIL PROTECTED]> wrote: Good mail Igor. Did you place it on the wiki, or a blog somewhere? It's very sound arguments. Especially the part about statefull/stateless web applications. Igor Vaynberg wrote: here is really what it comes down to: springmvc/struts/etc are geared towards building stateless applications. building something statefull is hard in these frameworks because the burden of having to juggle state is on you and it is hard/impossible to get right when doing manually. wicket is geared towrads building stateful applications. it takes care of the state juggling so you dont have to. it is, however, hard to build stateless applications in wicket because you have to take care to use only stateless components - and even then you are back to having to juggle state yourself. an important, but peripheral point, is that wicket takes full advantage of OOP. frameworks like springmvc/struts are highly procedural, they give you a hierarchy and you usually just extend it one level deep. in wicket you have to build custom class hierarchies so you can factor out all the common bits and pieces of your application. do your developers know how to do this properly? if you showed your developers the repeater hierarchy of repeatingview through datatable and asked them to choose a base class for their usecase would they complain that there are too many classes to choose from? this is quiet a common complaint on this list by people who come from struts and friends :) so in the end you have to look at the kind of application you are building and the type of developers you have, and pick the framework based on that. -igor On Thu, Oct 16, 2008 at 12:28 PM, Richard Allen [EMAIL PROTECTED]>wrote: Hello, We have stateful, desktop-like Web applications based on Struts 1.x. We want to migrate them to a modern Java Web framework so we are trying to choose what framework to use. The decision will be left up to myself and another colleague with buy-in from other key people. The other colleague wants to use Spring MVC, which she just received training on from SpringSource. I want to use a component-based framework like Wicket. I think Wicket looks great, so I have been telling her that I think we should consider using it instead of Spring MVC. I think it is a better fit for the type of applications we produce. My colleague emailed the instructor from SpringSource and asked what he thought of us migrating to Wicket instead of Spring MVC. His response is below with my comments inlined. I would appreciate any convincing comments from Wicket experts. Thanks, Richard Allen Rich, Some background on what I am forwarding along... During last week's Spring Rich Client class I took full advantage of the fact I had unlimited access to a SpringSource consultant/instructor. When he asked people why they were there, I brought up that we were transitioning from Struts 1.X to something else, and the likely candidates were Spring MVC and Wicket. Many of my questions to him over the course of the 4 days were focused on that particular topic. And when he offered up his email address for contacts after the class, I wrote it down and got back in touch with him this week (getting our money's worth out of the face time, I like to think!) with some well-deserved adulation for the course, some questions about the Spring 3.0 release schedule and finally, a summary of the Spring MVC vs. Wicket decision we face, trying to synthesize what I took away from the class. *** Specifically, in my email, I asked the question that you, an experienced web developer, posed to me about moving our Struts app to another MVC oriented framework (Spring MVC) vs. moving to a component framework (Wicket). What I heard you say in so many words earlier this week, was: "Why switch to something that is a little better th
Re: Wicket versus Spring MVC
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
Re: Re: Wicket versus Spring MVC
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 develop
Re: Wicket versus Spring MVC
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 *
Re: Wicket versus Spring MVC
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
Re: Wicket versus Spring MVC
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
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 sti
