Menu
▾
▴
springframework-developer
|
From: Colin S. <col...@ex...> - 2005-03-19 21:39:07
|
Ok, I'm going to add some variation of the methods from HttpFlowExecutionmanager to WebUtils, and will use them in ParameterMethodNameResolver. When you're ready to add back the capability in the flow system, just look there. Keith Donald wrote: >Just haven't added it back yet > >-----Original Message----- >From: Colin Sampaleanu [mailto:col...@ex...] >Sent: Saturday, March 19, 2005 2:29 PM >To: Erwin Vervaet; 'Keith Donald' >Subject: Re: [Springframework-developer] ParameterNameMethodNameResolver > >What happened to the parameter handling code from >HttpFlowExecutionManager? I can't find it any longer after the last >refactoring... HttpServletRequestEvent only has a simple getParameter >method... > > >Erwin Vervaet wrote: > > > >>Colin, >> >>Good idea, but I think it would be better to integrate both systems in >>the ParameterMethodNameResolver: >>1) first try the action=methodname syntax >>2) if nothing found, try action:methodName=foobar syntax >> >>Combining the two in 1 MethodNameResolver gives you to opportunity to >>mix and match the 2 techniques in the view. By having 2 resolvers >>you're forced to use one technique or the other. >> >>In the web flow system we originally also had these 2 systems in >>seperate "ParameterExtractors", but we abandoned this in favour of a >>more powerfull approach that supports both systems (and actually a >>third: image buttons). >>Check the following method in the sanbox source tree: >> >> >> >> >org.springframework.web.flow.support.HttpFlowExecutionManager.searchForReque >stParameter(HttpServletRequest > > >>request, String logicalName, String delimiter) >> >>Maybe it would be good to use that. We could move the method into the >>main source tree and put it on the WebUtils class. >> >>What do you think? >> >>Erwin Vervaet >>----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> >>To: <spr...@li...> >>Sent: Thursday, March 10, 2005 4:55 AM >>Subject: [Springframework-developer] ParameterNameMethodNameResolver >> >> >> >> >>>I've added a new resolver for the MultiActionController, >>>ParameterNameMethodNameResolver. Unlike ParameterMethodNameResolver, >>>which looks for a parameter like >>> action=methodname >>>where action stays constant, and the value is the method name, >>>ParameterNameMethodNameResolver uses the very existene of a parameter >>>name as an indication to map to a specific method. So feeding it the >>>String mapping array >>> "hello:goodbye", "validate", "colin:nina" >>>for example would map to the 'goodbye' method if there was a param >>>'hello', to the 'validate' method if there was a parameter named >>>'validate', and to 'nina' if there is a parameter named 'colin'. The >>>request parameter value is simply ignored, and the first match wins. >>> >>>This is useful when you have a bunch of submit buttons on a page, and >>>need to be able to tell them apart. The value attribute of a submit >>>button is also the display text, which is often localized, so it's >>>not a great mechanism to have the same button name and use the value >>>to tell the buttons apart. However, the name itself can be set >>>different for each button, and then this resolver can map based on that. >>> >>>Colin >>> >>> > > > > |
|
From: Erwin V. <erw...@er...> - 2005-03-20 08:45:46
|
Colin, I couldn't find the stuff in the WebUtils, so I reintroduced it in the web.flow system. It is now in the web.flow.support.HttpServletRequestEvent class. I suggest you move it to WebUtils if it is reusable for the ParameterMethodNameResolver. Erwin Vervaet erw...@er... ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> To: <spr...@li...> Sent: Saturday, March 19, 2005 10:39 PM Subject: Re: [Springframework-developer] ParameterNameMethodNameResolver > Ok, I'm going to add some variation of the methods from > HttpFlowExecutionmanager to WebUtils, and will use them in > ParameterMethodNameResolver. When you're ready to add back the capability > in the flow system, just look there. > > Keith Donald wrote: > >>Just haven't added it back yet >> >>-----Original Message----- >>From: Colin Sampaleanu [mailto:col...@ex...] Sent: Saturday, March >>19, 2005 2:29 PM >>To: Erwin Vervaet; 'Keith Donald' >>Subject: Re: [Springframework-developer] ParameterNameMethodNameResolver >> >>What happened to the parameter handling code from >>HttpFlowExecutionManager? I can't find it any longer after the last >>refactoring... HttpServletRequestEvent only has a simple getParameter >>method... >> >> >>Erwin Vervaet wrote: >> >> >>>Colin, >>> >>>Good idea, but I think it would be better to integrate both systems in >>>the ParameterMethodNameResolver: >>>1) first try the action=methodname syntax >>>2) if nothing found, try action:methodName=foobar syntax >>> >>>Combining the two in 1 MethodNameResolver gives you to opportunity to mix >>>and match the 2 techniques in the view. By having 2 resolvers you're >>>forced to use one technique or the other. >>> >>>In the web flow system we originally also had these 2 systems in seperate >>>"ParameterExtractors", but we abandoned this in favour of a more >>>powerfull approach that supports both systems (and actually a third: >>>image buttons). >>>Check the following method in the sanbox source tree: >>> >>> >>> >>org.springframework.web.flow.support.HttpFlowExecutionManager.searchForReque >>stParameter(HttpServletRequest >>>request, String logicalName, String delimiter) >>> >>>Maybe it would be good to use that. We could move the method into the >>>main source tree and put it on the WebUtils class. >>> >>>What do you think? >>> >>>Erwin Vervaet >>>----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> >>>To: <spr...@li...> >>>Sent: Thursday, March 10, 2005 4:55 AM >>>Subject: [Springframework-developer] ParameterNameMethodNameResolver >>> >>> >>> >>>>I've added a new resolver for the MultiActionController, >>>>ParameterNameMethodNameResolver. Unlike ParameterMethodNameResolver, >>>>which looks for a parameter like >>>> action=methodname >>>>where action stays constant, and the value is the method name, >>>>ParameterNameMethodNameResolver uses the very existene of a parameter >>>>name as an indication to map to a specific method. So feeding it the >>>>String mapping array >>>> "hello:goodbye", "validate", "colin:nina" >>>>for example would map to the 'goodbye' method if there was a param >>>>'hello', to the 'validate' method if there was a parameter named >>>>'validate', and to 'nina' if there is a parameter named 'colin'. The >>>>request parameter value is simply ignored, and the first match wins. >>>> >>>>This is useful when you have a bunch of submit buttons on a page, and >>>>need to be able to tell them apart. The value attribute of a submit >>>>button is also the display text, which is often localized, so it's not a >>>>great mechanism to have the same button name and use the value to tell >>>>the buttons apart. However, the name itself can be set different for >>>>each button, and then this resolver can map based on that. >>>> >>>>Colin >>>> >> >> >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Colin S. <col...@ex...> - 2005-03-21 22:22:32
|
I checked in a very slight modification to ParameterMethodNameResolver which also supports the "name.x" form sent by submit buttons of type "image", but I didn't end up trying to use the code from the flow packages, as we're not actually talking about a lot of code here, and the latter actually also supports the "name_value=xyz" form, which ParameterMehtodNameResolver doesn't care at all, and this would have slowed things down. Colin Erwin Vervaet wrote: > Colin, > > I couldn't find the stuff in the WebUtils, so I reintroduced it in the > web.flow system. It is now in the > web.flow.support.HttpServletRequestEvent class. I suggest you move it > to WebUtils if it is reusable for the ParameterMethodNameResolver. > > Erwin Vervaet > erw...@er... > ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> > To: <spr...@li...> > Sent: Saturday, March 19, 2005 10:39 PM > Subject: Re: [Springframework-developer] ParameterNameMethodNameResolver > > >> Ok, I'm going to add some variation of the methods from >> HttpFlowExecutionmanager to WebUtils, and will use them in >> ParameterMethodNameResolver. When you're ready to add back the >> capability in the flow system, just look there. >> >> Keith Donald wrote: >> >>> Just haven't added it back yet >>> >>> -----Original Message----- >>> From: Colin Sampaleanu [mailto:col...@ex...] Sent: Saturday, >>> March 19, 2005 2:29 PM >>> To: Erwin Vervaet; 'Keith Donald' >>> Subject: Re: [Springframework-developer] >>> ParameterNameMethodNameResolver >>> >>> What happened to the parameter handling code from >>> HttpFlowExecutionManager? I can't find it any longer after the last >>> refactoring... HttpServletRequestEvent only has a simple >>> getParameter method... >>> >>> >>> Erwin Vervaet wrote: >>> >>> >>>> Colin, >>>> >>>> Good idea, but I think it would be better to integrate both systems >>>> in the ParameterMethodNameResolver: >>>> 1) first try the action=methodname syntax >>>> 2) if nothing found, try action:methodName=foobar syntax >>>> >>>> Combining the two in 1 MethodNameResolver gives you to opportunity >>>> to mix and match the 2 techniques in the view. By having 2 >>>> resolvers you're forced to use one technique or the other. >>>> >>>> In the web flow system we originally also had these 2 systems in >>>> seperate "ParameterExtractors", but we abandoned this in favour of >>>> a more powerfull approach that supports both systems (and actually >>>> a third: image buttons). >>>> Check the following method in the sanbox source tree: >>>> >>>> >>>> >>> org.springframework.web.flow.support.HttpFlowExecutionManager.searchForReque >>> >>> stParameter(HttpServletRequest >>> >>>> request, String logicalName, String delimiter) >>>> >>>> Maybe it would be good to use that. We could move the method into >>>> the main source tree and put it on the WebUtils class. >>>> >>>> What do you think? >>>> >>>> Erwin Vervaet >>>> ----- Original Message ----- From: "Colin Sampaleanu" >>>> <col...@ex...> >>>> To: <spr...@li...> >>>> Sent: Thursday, March 10, 2005 4:55 AM >>>> Subject: [Springframework-developer] ParameterNameMethodNameResolver >>>> >>>> >>>> >>>>> I've added a new resolver for the MultiActionController, >>>>> ParameterNameMethodNameResolver. Unlike >>>>> ParameterMethodNameResolver, which looks for a parameter like >>>>> action=methodname >>>>> where action stays constant, and the value is the method name, >>>>> ParameterNameMethodNameResolver uses the very existene of a >>>>> parameter name as an indication to map to a specific method. So >>>>> feeding it the String mapping array >>>>> "hello:goodbye", "validate", "colin:nina" >>>>> for example would map to the 'goodbye' method if there was a param >>>>> 'hello', to the 'validate' method if there was a parameter named >>>>> 'validate', and to 'nina' if there is a parameter named 'colin'. >>>>> The request parameter value is simply ignored, and the first match >>>>> wins. >>>>> >>>>> This is useful when you have a bunch of submit buttons on a page, >>>>> and need to be able to tell them apart. The value attribute of a >>>>> submit button is also the display text, which is often localized, >>>>> so it's not a great mechanism to have the same button name and use >>>>> the value to tell the buttons apart. However, the name itself can >>>>> be set different for each button, and then this resolver can map >>>>> based on that. >>>>> >>>>> Colin >>>> |
