[Springframework-developer] Re: ParameterNameMethodNameResolver

[<kat...@ho...>]

While on the topic, we should look at renaming the default parameter to 
something other than 'action'. This clashes with the form's 'action' in 
Javascript, and so is maybe not a good default. This would probably be 
OK as part of a 1.2 release.

Colin Sampaleanu wrote:
> Erwin,
> 
> Actually I wrote the original support for handling image buttons for 
> flows, check out RequestParamNameToRequestAttributeFilter, which is 
> still in the sandbox... It's just a filter that maps param names to 
> name/value Request Attribute pairs, which the flow code would also 
> recognize. Of course the present approach is better.
> 
> I agree about just combining the new code in 
> ParameterMethodNameResolver. I can't think of any real disadvantage, 
> although once in a while somebody might have to rename the default 
> 'action' parameter recognition to something else, if there's already an 
> unrelated 'action' paramter. I'll go ahead and do this.
> 
> It probably does make sense to try to leverage the 
> 'searchForRequestParameter' code. Then image button support would come 
> in too. The only real disadvantage I can think of is that in the case 
> where you are using only the simple action=xxxx format, and want to rely 
> on the default method being hit (i.e. no match), then in that case 
> you're actually going to be expending extra cycles looping through all 
> request parameters to check for the 'logicalName_value = xyz' format as 
> well. This is really only a concern for the default method (other 
> methods would match the simpel parameter directly), so I don't know how 
> big a deal this is, but I guess it could be configurable actually as to 
> whether it supports the extended matching.
> 
> Colin
> 
> 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.searchForRequestParameter(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