Hi folks,
This has already been discussed on the mailing list (not so long ago).
The debate is open, and ultimately it's a personal preference : some prefer
method parameters "a la Spring", others favor properties.
I think there is no answer here : both methods have their pros and cons, and
will drive the design of your actions.
In all honesty (and in my humble opinion of course, and yes I'm bias :P ),
the Spring way looks theoretically better, but in practise Stripes wins
hands down. Just because you have one class less to write (the model). In
Stripes the "model" (from Spring) is the bean. This makes the
controller/view duet very smooth :
class MyAction ... {
MyObject myObject
Resolution doIt() {
return new ForwardResolution("/WEB-INF/jsp/doIt.jsp"
}
}
doIt.jsp :
<p>${actionBean.myObject.xyz}</p>
I fail to see how it could be more clear and concise. Spring has an
additional indirection here that, IMO, ain't KISS at all !
Now when it comes to complex actions (with many event handlers and bound
props), it can become tedious (hard to share validation rules, properties
etc). But a common "good practise" in Stripes is just to divide and conqueer
: split your beans into smaller ones. If they get too big, you probably have
a design problem (just like for regular POJOs).
I think the current design in Stripes is good, but we could also imagine to
have "parameters instead of props" (or both) enabled. And let the user
choose, depending on the situation. Feel free to send a patch :)
Cheers
Remi
2011/3/3 Jeppe Cramon <je...@cramon.dk>
> Hi Tony
>
> I agree IF Stripes would allow you to supply parameters for Action Methods,
> like Spring MVC or JERSEY (REST), that would mean a good cleanup and better
> encapsulation.
>
> /Jeppe
>
> *"It is difficult to get a man to understand something when his salary
> depends upon him not understanding it.” - Upton Sinclair*
>
>
>
> On 03/03/2011, at 10.53, Tony Drago wrote:
>
>
>
> Nikolaos Giannopoulos wrote:
>
>
>
> Encapsulation in OO IMHO pertains to the class as a whole not the method
>
> level. If you want to encapsulate at the method level then your going
>
> to have a hard time not allowing someone to access and affect other
>
> attributes of the class (e.g. other attributes) as even if you mark
>
> attributes as private any method of the class can alter it.
>
>
> Perhaps you might be used to defining classes that should ideally be
>
> further refactored into multiple classes. Not sure - but if you could
>
> provide some more complex examples then we could examine specifics and
>
> dispense with theory or generalized statements (from my side as well) ;-)
>
>
>
> Thanks for the response. You asked for a specific example, so here you
> go.....
>
> An action bean which creates and deletes users. IMO, these two actions
> belong to the same bean, but in the case of add we need all the User
> properties, but in the case of delete we only need the id. In Spring the
> controller would look like this:
>
> // ANNOTATIONS OMITTED FOR BREVITY
> class MyController {
>
> public String deleteUser(Integer userId) {
>
> userService.deleteUser(userId);
> return "redirect:/listUsers";
> }
>
> public ModelAndView addUser(User user) {
>
> userService.addUser(user);
> return new ModelAndView("/showUser", user);
> }
> }
>
> In Stripes the action would look like this:
>
> // ANNOTATIONS, GETTERS AND SETTERS OMITTED FOR BREVITY
> class MyActionBean extends BaseActionBean {
>
> private Integer userId;
> private User user;
>
> Resolution deleteUser() {
>
> userService.deleteUser(userId);
> return new RedirectResolution("/listUsers.jsp");
> }
>
> Resolution addUser() {
>
> userService.addUser(user);
> return new ForwardResolution("/showUser.jsp");
> }
> }
>
> From a readability point of view I much prefer the Spring MVC code because
> I
>
> can tell without looking at the method body, what parameters are used by
> each handler/event. In the case of Stripes, I have to read the body of each
> method to figure out whether userId/User are used as request parameters or
> view model by each event.
>
> I feel like the Stripes approach is poorly encapsulated because
>
> - public getters/setters must be defined for userId and User, but these
> should only be accessible to the event handler that needs them
> - the view model produced by a handler also must have public
> getters/setters, but this model should really only be visible to the view
> (JSP)
> - there is no way to prevent one handler/view from attempting to access
> parameters or view data intended only for use by another handler in the
> same
> bean
>
> Again, I'm not attempting to "prove" that SpringMVC is better than Stripes,
> the question of interest is whether Stripes encourages bad practice from an
> OO point-of-view?
>
> (Incidentally, a nice side-effect of SpringMVC's approach is that there's
> no
> need to write boilerplate getters/setters for the request parameters,
> though
> I guess I could eliminate these by writing my Stripes action beans in
> Groovy)
>
> --
> View this message in context:
> http://old.nabble.com/request-response-scoping-tp31050264p31057415.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
>
>
------------------------------------------------------------------------------
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
