I was thinking it would be possible to use both. Either by adding a second type of binder to the configuration, so they both run, or potentially by subclassing the existing binder to overlay the functionality.
On Oct 5, 2010, at 2:36 PM, Poitras Christian wrote: > 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 ------------------------------------------------------------------------------ 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
