Totally agree with Christian that the Stripes version can be redefined
as Christian points out.
Moreover, when doing CRUD operations we "typically" need to display the
entity that the user wants to delete and ask for user confirmation i.e.
we don't just ask the user if they wants to delete id "9999" but
actually show them the record and ask: "Do you really want to delete
it?". I might add that especially if you are dealing with a user record
you would want the admin to see the record before deleting it. No?
So in our case the object is loaded regardless... as Christian points out.
But the usage of an object over an id for delete goes beyond that... as
well... in CRUD for us... and for anyone using say JPA and an ORM.
In that if you use say JPA and Hibernate the OOB / least amount of code
approach (not necessarily the most efficient) to delete an object is to
use the object itself to do so. Of course that entails for us a 2 step
DB call (merge and delete) and clearly isn't the most efficient approach
but that is what you get OOB with an ORM. What we will do to improve
that later is use the id from the object to execute a simple delete SQL
statement and even then our BaseModel class heirarchy holds the ID so we
would simply pass in the object to delete and have its ID used to delete it.
So sorry... in the case of CRUD... including delete... we don't need to
define that separate id attribute in the action bean.
The only place an ID is defined in our case is in the URL binding... and
that is more so b/c of how we want to define clean URLs.
This is why I suggested you look at some more complete real world
examples to compare... b/c you might be surprised :-)
HTH,
--Nikolaos
Poitras Christian wrote:
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)
--
Nikolaos Giannopoulos
Director of Information Technology
BrightMinds Software Inc.
e. nikol...@brightminds.org
w. www.brightminds.org
t. 1.613.822.1700
c. 1.613.797.0036
f. 1.613.822.1915
------------------------------------------------------------------------------
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
