Re: [Springframework-developer] ParameterNameMethodNameResolver

[Colin S. <col...@ex...>]

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
>