Hi Tony
We can all learn from criticism, so in my opinion it is great to get your
view on this :-)
I have not tried Spring MVC. I dropped it when I looked at the XML
configuration file(s)...
Perhaps this has gotten better lately, I don't know.
Let me explain the way I see it.
Stripes has from the beginning been built to honor Convention Over
Configuration. In my experience not many frameworks has had this idea built
in from the beginning, except Grails (which I like too).
Normally you had to create large XML files to tell the framework what to do.
Buggy and very time-consuming.
+1 to Stripes
As for the object oriented aspect, I do not agree with you.
If you think of a Car as a domain object, it will consist of several
properties and some actions that a car can do, i.e. drive, turn etc..
Not all properties is used on every action, but the actions are aimed at
servicing the Car object, doing what they have to do.
If you have an event that takes a rich VO as an argument, sets properties on
it and then populates it back to the view, it will (in my opinion) be the
same as putting the car on a truck and move it to the place you want,
instead of just drive where you wanna go.
You are right though, that it can be real messy it you do not show some
discipline and take care not to put your whole application into one action
bean :-)
This is where you should aim you fields and events at the task this action
bean is meant to handle.
In my opinion: +1 to Stripes
Then comes a general feeling about using Stripes.
I have many times, about a specific feature, thought: "Well, this is how it
is meant to work, now lets start fixing the bugs in my code...".
To my big surprise, in 90% (I guess, did not keep an accurate track on this
:-), there was no bug! It just worked as expected. Even stuff I tried out
like "Well, if works like that, it might also do this...". And again, I was
amazed that most of the time my expectations was fulfilled.
When something did not work, I was able to understand why and handle the
issue quickly.
+1 to Stripes
I work in a large organization where validators and formattors has been a
battle to find. Each time you needed a formattor for a specific VO, you had
to ask "some guy" to be able to find it and use it. Most of the time "some
guy" was not available, and then people started creating new formattors
doing the same thing. Leading to VOs being formatted differently in the
application.
Same thing goes for converters.
With Stripes, using the <s:format... tag you are can forget this worry,
since Stripes will look up the formattor and converter automatically -
without any configuration, except for telling Stripes where it should find
the extensions. This is done in the web.xml.
+1 to Stripes
I have created an integration into a CMS that renders portalpages. This
integration makes it possible to use Stripes applications as portlets - some
primitive portletbridge for Stripes. In my work I had to dig deep into how
Stripes works, and I have never been in a situation where I did not know
what to do. Thanks to Freddys book, actually - so "Thank you so much,
Freddy!!!" :-)))
I know that Spring MVC has a portlet bridge. I have not looked at it, but it
is probably fine. However, since I wanted to create portlets using
absolutely NO configuration, then Spring fails.
+1 to Stripes
Speaking of developers using Stripes and the size of the community, Spring
(MVC and others) are much larger.
This does not mean they are right, though (again, in my opinion).
Actually, this is probably the only place I would give point to Spring, for
being able to brand Spring the way they do.
+1 to Spring.
All the above is my humble opinion and experience, and I know that sometimes
I am wrong, so bare with me if I have said something about Spring that is
not true. Then correct me if I am wrong :-)
I hope this helps you a little in the motivation for using Stripes.
Cheers
Søren
2011/3/2 Tony Drago <do...@mailinator.com>
>
> Hi,
>
> First of all, I promise I'm not trolling. I'm going to say some critical
> things about Stripes here, but my intention is to understand whether I'm
> missing something, not to offend. If you don't like to read criticism of
> your favorite framework, you should probably not read any further. Now that
> we've got that out of the way......
>
> My web framework background is in SpringMVC (and Grails). In SpringMVC a
> request handler looks like this:
>
> // ANNOTATIONS OMITTED FOR BREVITY
> class MyController {
> ModelAndView showUserProfile(Integer userId) {
>
> UserProfile userProfile = userService.getProfile(userId);
>
> // An object that encapsulates the logical view name and data to be
> displayed
> return new ModelAndView("userProfile", userProfile);
> }
> }
>
>
> In Stripes, the equivalent ActionBean would look something like
>
>
> // ANNOTATIONS, GETTERS AND SETTERS OMITTED FOR BREVITY
> class MyActionBean extends BaseActionBean {
>
> private Integer userId;
> private UserProfile;
>
> Resolution showUserProfile() {
>
> this.userProfile = userService.getProfile(userId);
>
> // An object that encapsulates the logical view name and data to be
> displayed
> return new ForwardResolution("/userProfile.jsp");
> }
> }
>
> What bugs me about the Stripes approach is that the request parameters and
> the model (UserProfile) are not scoped to the relevant handler method. In
> most cases, a controller class has more than one handler, and I really
> dislike the fact that there's no way to tell just by looking at the code
> which request params and view model go with which handler method. I know
> you
> could put each handler in its own class, but that will create a whole other
> set of problems.
>
> Fundamentally, having variables which should be scoped to a single method
> scoped to a single class, feels like bad OO practice (poor encapsulation).
> Am I missing something, or is this just something that most Stripes users
> don't care about?
>
>
>
>
> --
> View this message in context:
> http://old.nabble.com/request-response-scoping-tp31050264p31050264.html
> Sent from the stripes-users mailing list archive at Nabble.com.
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
