Re: [Springframework-developer] ParameterNameMethodNameResolver

[Erwin V. <erw...@er...>]

Making it configurable would be good. Keith actually mentioned he noticed 
degraded performance with the extensive search, although that seems unlikely 
unless you have a very large amount of request parameters :-)


Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Thursday, March 10, 2005 3:51 PM
Subject: Re: [Springframework-developer] ParameterNameMethodNameResolver


> 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
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>