Hi Freddy,
Yeah, or stuff like this :
public ModelAndView save(HttpServletRequest, HttpServletResponse, User)
All this model/view thing they have, plus the crappy so-called CoC...
http://static.springsource.org/spring/docs/2.0.x/reference/mvc.html#mvc-coc
I always found it quite ugly, and I prefer the Stripes way. I think it's a
good design trade off : here again (binding, handlers and use of Resolutions
without indirection), Tim stopped at the right point. We don't need more :)
Funny, this thread reminds me 2 years ago at SpringOne, when I finally got a
lead dev of Grails to admit that SpringMVC was good for building frameworks,
but certainly not for building applications... He was selling SpringMVC to
everyone (they had just got acquired by SpringSource so they would do lots
of advertising), but in private he mentioned that he had looked at Stripes
and found it very nice !! Was pretty cool to hear this from him...
Cheers
Remi
2010/10/1 Freddy Daoud <xf2...@fastmail.fm>
> Hi Karen,
>
> Karen <ka...@...> writes:
>
> > [...] I looked closer and noticed that the big difference between Stripes
> and
> > Spring MVC still is, that Stripes action beans are threat safe and Spring
> 3
> > MVC beans are not thread safe.
> > Just like Servlets the Spring MVC beans are singletons with multiple
> active
> > threads running through them. Unlike Stripes they can't use instance
> > variables.
> > Thus the Spring beans have to use local variables, a programming model
> that
> > leads to more complex procedural code.
>
> I've looked more closely to Spring MVC. Now, my feeling is that it's not a
> problem for Spring MVC controller beans to be singletons. It's just a
> different
> approach than Stripes. Whereas Stripes has instance variables that can be
> set
> from request parameters, Spring event handler methods accept those same
> objects
> as parameters.
>
> In other words, in Stripes you'd have
>
> private User user;
>
> /* getters and setters */
>
> public Resolution save() {
> // do something with user
> }
>
> In Spring MVC you'd have
>
> public void save(User user) {
> // do something with user
> }
>
> The "do something"s in both Stripes action beans and Spring controllers are
> best left to injected helpers, daos, and so on, keeping the
> action/controller
> classes simple.
>
> So, in that respect, I'm not sure that using local variables leads to more
> complex procedural code, if you keep things simple in controllers.
>
> But, you seem to speak from experience, so I'd love to read your thoughts
> on this.
>
> Cheers,
> Freddy
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
