Re: [Stripes-users] re quest/response scoping
Hi Tony, I think the point you raised has been pretty much exhaustively elaborated by the previous posters. What I want to add is that as somebody who has to switch between SpringMVC and Stripes on a periodic basis - my experience is that Stripes wins hands down. Our company started a couple projects some 9 years ago on SpringMVC, but since I discovered Stripes cica 2006 all subsequent projects has been on Stripes. I still need to go back to do enhancements and maintenance on the couple of SpringMVC projects on periodic basis - and man, I keep wishing that I can turn back the clock to restart the projects on Stripes. Stripes is simply more natural, practical and less bloated compared to SpringMVC. It never gets into the way, and it is a lot easier for new comers (seasoned programmers as well as fresh graduates) to pick up. I have been using Stripes for some 6 years. I kept my eyes open for new comers, but I have not seen anything that gives me enough incentive to switch yet. Cheers, Yee -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] re quest/response scoping
On Mar 3, 2011, at 1:52 AM, Tony Drago wrote:
> // 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);
>}
> }
>
And here's where it fails. The KISS idiom is paramount here. Stripes Action
Beans are (typically) small enough where the encapsulation simply isn't
necessary, and in fact gets in the way because, as others have mentioned, when
you're working with many similar methods, pretty soon, they all have similar
signatures. While it's explicit, it's redundant.
Also, MVC REQUIRES this style because the controller is not thread safe. IMHO,
the fact that Servlets are not thread safe makes sense to me from a simplicity
of the implementation and design of the basic framework. The fact that other
frameworks KEEP that "feature" is, frankly, just insanity. ActionBeans are
created (typically) fresh with each request, so they don't need to encapsulate
logic and parameters at the method level, the Class is the level of abstraction
and encapsulation.
With Classes we get neat things like inheritance. We have a large chunk of
refactored code and handlers in our system that is shared among our
ActionBeans. Our Entities have common ancestry, which our factored out routines
and resolutions can work with. But Stripes binds to the Entities themselves,
correctly. So, our ActionBeans might have List in them, while the common
code works with List. With Methods as your sole level on encapsulation,
you can't have a handler that takes "List" because you'll lose the rest
of your model when the system binds to it. Since our binding is done at a
higher level, in the class, we can bind to List and then call a
resolution and treats them as List without losing information. You lose
that kind of flexibility when Methods are your sole level on encapsulation.
Stripes use of the "ActionBean as Controller/Model" also fits well in the 90%
use case. The simple fact that you're populating your "ModelAndView" is
something that Stripes doesn't have to do. Every method has to enumerate its
parameters (redundantly in the 90% use case), and then enumerate the objects
going in to the ModelAndView, again, in the 90% use case, redundantly. Stripes
factors all that boiler plate away. This, IMHO, simplifies the code.
I'll be the first to admit that on edge case, with really complicated
ActionBeans, it can get a little busy. Also, Stripes potentially lets other
things that we don't want populated, to be populated (i.e. some piece of the
model not used by the resolution). But, I'd rather deal with that rare bit of
busy than fight the repetitive, redundant boiler plate in the 90% case.
There's little stopping folks from writing redundant, wordy code (because, as
we all know, Java isn't wordy enough) with Stripes. *I* embrace the fact the
Stripes lets me NOT do that. Expedience and practicality in the every day work
outweighs design purity every time in my book.
Regard,
Will Hartung
"Bulldozing Ivory Towers since 1979"
--
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
Re: [Stripes-users] re quest/response scoping
Hello,
I was about to write the same reply as Christian.
To go further, compare
// ANNOTATIONS OMITTED FOR BREVITY
class MyController {
@Autowired
private UserService userService;
public ModelAndView prepareUser(Integer userId) {
ModelAndView modelAndView=new ModelAndView("/editUser.jsp");
modelAndView.addObject("user",userService.getUser(userId));
modelAndView.addObject("countries",userService.getCountries());
modelAndView.addObject("profiles",userService.getProfiles());
return modelAndView;
}
}
// ANNOTATIONS, GETTERS AND SETTERS OMITTED FOR BREVITY
class MyActionBean extends BaseActionBean {
@SpringBean
private UserService userService;
private User user;
private List countries;
private List profiles;
public Resolution prepareUser() {
user=userService.getUser(user.getId());
countries=userService.getCountries();
profiles=userService.getProfiles();
return new ForwardResolution(""/editUser.jsp");
}
}
Stripes-style has the virtue of being type-safe compared to Spring MVC
("user","countries"...): less error prone, easier to unit test. On the
contrary, Spring Controllers are "singletons" whereas Stripes Actions
are "prototypes": Spring-style is probably faster because dependency
injection is done only once.
Gérald
2011/3/3 Poitras Christian :
> 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 reques
Re: [Stripes-users] re quest/response scoping
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 "" 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
Re: [Stripes-users] re quest/response scoping
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: I
Re: [Stripes-users] re quest/response scoping
> 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? I suppose it depends on your definition of OO - I use subclassing in my ActionBeans so that I can share common parameters and validators efficiently. That is hard to do when your method arguments define the parameters. Also, I could argue that it's a slightly better OO practice to have lots of small ActionBeans, rather than big ActionBeans that have multiple entry points. But it depends on what you think of as an "Object" in a web application sense, and how Model-centric your thinking is. I don't really see either way as inherently bad practice. /Janne -- 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
Re: [Stripes-users] re quest/response scoping
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 :
${actionBean.myObject.xyz}
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
> 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 requ
Re: [Stripes-users] re quest/response scoping
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
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
Re: [Stripes-users] re quest/response scoping
Soren Pedersen wrote: > > > I have not tried Spring MVC. I dropped it when I looked at the XML > configuration file(s)... > Perhaps this has gotten better lately, I don't know. > > SpringMVC has really improved in this area. Since version 2.5 (current version is 3.0.X) you can basically do everything with annotations. The only thing you need to do in XML is configure the front controller servlet (AKA dispatcher servlet), just like Stripes! -- View this message in context: http://old.nabble.com/request-response-scoping-tp31050264p31057202.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
Re: [Stripes-users] re quest/response scoping
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 be
Re: [Stripes-users] re quest/response scoping
Tony, Comments in-line... Tony Drago wrote: > 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. Constructive criticism is great... making people think makes everything / everyone hopefully evolve ;-) > What bugs me about the Stripes approach is that the request parameters and > the model (UserProfile) are not scoped to the relevant handler method. Sure... but nothing stops you from having a class that has only 1 event handler in it. But yes I see your point... . > 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. On the surface your statement is totally valid and I have to agree. However... you could look at this from at least 2 different angles: 1) If the request params are so different then why put them in the same action bean in the 1st place? Nothing stops you from doing so... but is that good design... perhaps not i.e. any kind of class whether its an action bean or a POJO by definition encapsulates behaviour and attributes... if there are attributes in there that don't totally relate to the behaviour then refactoring might be warranted. 2) On the other hand if the request params are similar... as in cases like for example doing CRUD on a database entity... then I find it to be a non-issue as the action bean deals with the request params it has defined in it. In fact, I find it to be refreshing and clear and eliminates me having to define the params the same over and over again for multiple event handlers. I would suggest you try building some more real world examples / test cases to see if it suits you and in the end if it doesn't then so be it... but these examples are too simplistic to realize any significant pros or cons. > I know you could put each handler in its own class, but that will create a > whole other > set of problems. > As I mentioned if the attributes are really that different perhaps its warranted. But I'm sure you'll have cases it isn't. Test code and documentation is also not out of the question... Right? If you have say for example on a "add" event that the id should not be set or should be passed in as "-" or whatever then you could should test for that and document that in your add event handler. But what other issues are you alluding to? A proliferation of classes? > 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? > 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) ;-) HTH, --Nikolaos -- 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
Re: [Stripes-users] re quest/response scoping
Hi Tony
We can all learn from criticism, so in my opinion it is great to get your
view on this :-)
I have not tried Spring MVC. I dropped it when I looked at the XML
configuration file(s)...
Perhaps this has gotten better lately, I don't know.
Let me explain the way I see it.
Stripes has from the beginning been built to honor Convention Over
Configuration. In my experience not many frameworks has had this idea built
in from the beginning, except Grails (which I like too).
Normally you had to create large XML files to tell the framework what to do.
Buggy and very time-consuming.
+1 to Stripes
As for the object oriented aspect, I do not agree with you.
If you think of a Car as a domain object, it will consist of several
properties and some actions that a car can do, i.e. drive, turn etc..
Not all properties is used on every action, but the actions are aimed at
servicing the Car object, doing what they have to do.
If you have an event that takes a rich VO as an argument, sets properties on
it and then populates it back to the view, it will (in my opinion) be the
same as putting the car on a truck and move it to the place you want,
instead of just drive where you wanna go.
You are right though, that it can be real messy it you do not show some
discipline and take care not to put your whole application into one action
bean :-)
This is where you should aim you fields and events at the task this action
bean is meant to handle.
In my opinion: +1 to Stripes
Then comes a general feeling about using Stripes.
I have many times, about a specific feature, thought: "Well, this is how it
is meant to work, now lets start fixing the bugs in my code...".
To my big surprise, in 90% (I guess, did not keep an accurate track on this
:-), there was no bug! It just worked as expected. Even stuff I tried out
like "Well, if works like that, it might also do this...". And again, I was
amazed that most of the time my expectations was fulfilled.
When something did not work, I was able to understand why and handle the
issue quickly.
+1 to Stripes
I work in a large organization where validators and formattors has been a
battle to find. Each time you needed a formattor for a specific VO, you had
to ask "some guy" to be able to find it and use it. Most of the time "some
guy" was not available, and then people started creating new formattors
doing the same thing. Leading to VOs being formatted differently in the
application.
Same thing goes for converters.
With Stripes, using the
>
> 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,
[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
