Re: [Springframework-developer] ParameterNameMethodNameResolver

[Juergen H. <ju...@in...>]

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