Hi Tony, I don't know that it's poor encapsulation/bad OO design: after all, injecting parameters into an object via getter/setter methods, then calling some other routine that works on some/all of those is very Spring-like, and that is apparently okay.
Also, having a shared getter/setters across multiple event handlers allows you to only specify your validations once, rather than annotating each handler methods arguments separately, which helps in some cases. But it would be nice if you could choose which way suited your need, and make it possible to use the @Validate annotation on method parameters. I'm thinking of a CRUD ActionBean that needs a unique ID only (but must have one) to support a read/delete action, but needs a full set of properties for update/create, which could show that by asking for the ID property in the read/delete event handlers and the object in the update/create. Another way that might fit more readily into the Stripes way would be an annotation @ValidateFor(events = { event names... }) on the getter/setter, but this way it still wouldn't be easy to just look at a bean and see which event used what inputs. Kind regards, William Rose -----Original Message----- From: Tony Drago [mailto:do...@mailinator.com] Sent: Thursday, 3 March 2011 2:11 AM To: stripes-users@lists.sourceforge.net Subject: [Stripes-users] re quest/response scoping 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 This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. ------------------------------------------------------------------------------ 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