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:[email protected]]
Sent: Thursday, 3 March 2011 2:11 AM
To: [email protected]
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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
