Re: [Springframework-developer] ParameterNameMethodNameResolver

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

To fix the CVS case-sensitive delete: first commit the delete of the file, 
then commit the renamed version (do both commits seperately).

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


> I've moved the new code into ParameterMethodNameResolver, and killed 
> ParameterNameMethodNameResolver. Unfortunately I had to name the new test 
> class (there were no tests for the existing ParameterMethodNameResolver) 
> as ParameterMethodNameResolverTest and not our standard 
> ParameterMethodNameResolverTests, as the latter had some sort of conflict 
> based on there apparently already being some sort of deleted file in CVS 
> with the same name but differering only in case.
>
> I did not go ahead and try to use the 'searchForRequestParameter' code. Do 
> we all agree that it makes sense to pull that code from the sandbox, and 
> move it into WebUtils, and then use it here? Doing so would allow the 
> method resolver to also work with image buttons.
>
> Colin
>
> 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
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>