Re: [Springframework-developer] ParameterNameMethodNameResolver

[Dmitriy K. <dko...@ru...>]

Juergen, everyone,

I guess it would be too long, but how about explicit name like 
"paramNamesAsMethodNames"?

Dmitriy.

Juergen Hoeller wrote:

>Colin,
>
>I've just looked at the new functionality in ParameterMethodNameResolver: a
>worthwhile improvement! However, I would prefer different naming of the bean
>properties:
>
>* As a minor thing, "paramNameList" should be named "paramNames" (we're
>usually using "xxxs" instead of xxxList" in property naming).
>
>* The bigger issues is that "paramName" and "paramNames" are named so
>similarly, but mean two different things: the first is a parameter whose
>*value* will be interpreted as method name, while the latter are parameters
>whose *name* will be used as method name (with the very existence of the
>parameter triggering the method).
>
>However, I can't come up with a good separation in name there. Maybe
>"methodParamNames" for the latter? I don't know and would appreciate some
>input :-)
>
>The only thing I'm sure of is that we need to do something about this. Two
>such bean properties with similar names but different meaning would confuse
>users.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Thursday, March 10, 2005 7:32 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] ParameterNameMethodNameResolver
>
>
>Note btw that I've change the logic of the code a bit. There is the old
>ability to declare a paramter (default is 'action') whose value is the
>method name. Then you can declare a simple list (as a String array) of
>parameter names, which are treated such that (on a first match basis) if
>a parameter exists, that is the method name. Then there is also an
>optional logicalMappings Properties property that can be set, which can
>be used to treat the method name as logical name, and map it to the
>'real' name. This allows the person configuring the controller to
>completely decouple the method name from that specified by the JSP page
>(or other browser based code sending in the request).
>
>Colin Sampaleanu wrote:
>
>  
>
>>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.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
>
>
>
>-------------------------------------------------------
>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
>  
>