Hi folks, There's one thing though, what about the views ? One cool aspect of the stripes way is that you access the bean directly from the view, usually using el, like "actionBean.myProp". The values accessed are often bound by stripes on the bean. Now, if you pass bound objects to a handler method, how will you access those values from your jsps ? If you have to use bean state for that, you still have your initial problem : you'll need accessors, and you won't know easily where (in views this time) props are used. In spring there is the ModelAndView indirection : a kind of binding passed to the view with all needed data. that doesn't exist in stripes : views access the bean directly. So imho the current system is sufficient, and most of all, it's simple. In most cases, when your validation and binding becomes complex, you'll probably make it much simpler by just breaking your one fat action into several smaller ones... Cheers Remi
2010/10/6, Poitras Christian <christian.poit...@ircm.qc.ca>: > It could be a good idea to keep both binders separate and have a aggregate > binder that uses both sub-binders. That would allow full flexibility. > What do you think? > > Christian > > -----Message d'origine----- > De : Evan Leonard [mailto:evan.leon...@gmail.com] > Envoyé : October-05-10 5:42 PM > À : Stripes Users List > Objet : Re: [Stripes-users] Associating Parameters to Specific Actions > > > 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 > > ------------------------------------------------------------------------------ > 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 > -- Envoyé avec mon mobile ------------------------------------------------------------------------------ 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
