The downside of using 2 binders is that it's difficult to mix both approach.
Still, it would seem bizarre to have both approach in the same program... -----Message d'origine----- De : Evan Leonard [mailto:evan.leon...@gmail.com] Envoyé : October-05-10 3:31 PM À : nikol...@brightminds.org; Stripes Users List Objet : Re: [Stripes-users] Associating Parameters to Specific Actions Certainly! I started doing a little prototyping with this today while waiting for another build to finish. I'm trying the approach of having one annotation on the method like this: @ParamBinding({"aString", "aNumber"}) public Resolution myAction(String aString, int aNumber) { ... } The question I'm currently thinking about is whether to add to the implementation of DefaultActionBeanPropertyBinder or whether there should be second type of binder, something like this: public interface ActionHandlerParameterBinder extends ConfigurableComponent { ValidationErrors bind(final Method handler, ActionBean bean, ActionBeanContext context, boolean validate); } Thoughts? Evan On Oct 5, 2010, at 1:19 PM, Nikolaos Giannopoulos wrote: > Evan / Christian / Remi et al. > > This thread is very interesting and I am enjoying it... and hope it > continues... > However, can we rename this thread to something more aligned to the > discussion? > > If no one minds I have taken the liberty to rename it to the above ;-) > > Regards, > > --Nikolaos > > > > > Evan Leonard wrote: >> Here's an interesting approach from the waffle framework. It uses >> annotations, but lists all the parameter names in a single annotation. >> >> @ActionMethod(parameters = {"firstNumber", "secondNumber"}) >> >> Evan >> >> >> On Oct 5, 2010, at 6:48 AM, Poitras Christian wrote: >> >> >>> It's a problem that we faced in MyBatis when dealing with multiple >>> parameters. We went with the annotation approach. >>> I guess there are many workarounds for that and Spring is probably using >>> one. Debug seems like a good workaround. >>> >>> Christian >>> >>> -----Message d'origine----- >>> De : Freddy Daoud [mailto:xf2...@fastmail.fm] >>> Envoyé : October-05-10 8:40 AM >>> À : Stripes Users List >>> Objet : Re: [Stripes-users] Stripes Development and its Future... (long) >>> >>> Are you sure? I think that if you compile with debug info turned >>> on, and your request parameters are named param1 and param2, >>> they will be bound correctly without the need for the annotations. >>> >>> Or is that what you meant by "you will need the source code"? >>> >>> Cheers, >>> Freddy >>> >>> On Tue, 5 Oct 2010 08:36:43 -0400, "Poitras Christian" >>> <christian.poit...@ircm.qc.ca> said: >>> >>>> A problem with the Spring approach is that parameter names are not >>>> accessible by reflection. >>>> The consequence is that if you have method like >>>> public void substract(int param1, int param2) >>>> It will be difficult to pass the parameters in the right order. You will >>>> need either the source code to find the parameter names or an annotation >>>> like >>>> public void substract(@Param("param1") int param1, @Param("param2") int >>>> param2) >>>> >>>> Stripes is not affected by that problem. >>>> >>>> Christian >>>> >>>> -----Message d'origine----- >>>> De : Evan Leonard [mailto:evan.leon...@gmail.com] >>>> Envoyé : October-04-10 4:59 PM >>>> À : Stripes Users List >>>> Objet : Re: [Stripes-users] Stripes Development and its Future... (long) >>>> >>>> +1. Though it will take one of us being dissatisfied *enough* to >>>> implement this ourselves :-) >>>> >>>> >>>> On Oct 2, 2010, at 9:05 PM, Simon wrote: >>>> >>>> >>>>>> In other words, in Stripes you'd have >>>>>> >>>>>> private User user; >>>>>> >>>>>> /* getters and setters */ >>>>>> >>>>>> public Resolution save() { >>>>>> // do something with user >>>>>> } >>>>>> >>>>>> In Spring MVC you'd have >>>>>> >>>>>> public void save(User user) { >>>>>> // do something with user >>>>>> } >>>>>> >>>>>> The "do something"s in both Stripes action beans and Spring controllers >>>>>> are >>>>>> best left to injected helpers, daos, and so on, keeping the >>>>>> action/controller >>>>>> classes simple. >>>>>> >>>>>> So, in that respect, I'm not sure that using local variables leads to >>>>>> more >>>>>> complex procedural code, if you keep things simple in controllers. >>>>>> >>>>> The main drawback to the Stripes approach is that if you have multiple >>>>> handlers on a single action it becomes ambiguous which bean properties >>>>> are inputs to each action. When they are arguments to the handler >>>>> method it is super clear what applies where. I wouldn't mind >>>>> sometimes if Stripes supported either approach - why not just look for >>>>> any method that returns Resolution and then if there are parameters, >>>>> try to bind them, if you can? (yes, you probably need annotations to >>>>> tell you the name to bind on, but I can live with that) >>>>> >>>>> Cheers, >>>>> >>>>> Simon >>>>> >>>>> > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Stripes-users mailing list > Stripes-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/stripes-users ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
