Hi Tony,
Personally, I would code the action bean differently making it look almost
exactly like the Spring version.
// ANNOTATIONS, GETTERS AND SETTERS OMITTED FOR BREVITY
class MyActionBean extends BaseActionBean {
private User user;
Resolution deleteUser() {
userService.deleteUser(user);
return new RedirectResolution("/listUsers.jsp");
}
Resolution addUser() {
userService.addUser(user);
return new ForwardResolution("/showUser.jsp");
}
}
Is there anything wrong in getting the whole user object to delete it instead
of just the id?
That's even more trivial to do if your user converter takes the id.
Christian
-----Message d'origine-----
De : Tony Drago [mailto:do...@mailinator.com]
Envoyé : March-03-11 4:52 AM
À : stripes-users@lists.sourceforge.net
Objet : Re: [Stripes-users] re quest/response scoping
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
