springframework-developer

[Springframework-developer] ParameterNameMethodNameResolver

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

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

Re: [Springframework-developer] ParameterNameMethodNameResolver

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

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
>
> 

Re: [Springframework-developer] ParameterNameMethodNameResolver

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

I agree with Erwin that combining both approaches into
ParameterMethodNameResolver would be nice. Any objection to this, Colin?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Erwin Vervaet
Sent: Thursday, March 10, 2005 8:48 AM
To: spr...@li...
Subject: Re: [Springframework-developer] ParameterNameMethodNameResolver


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

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
>

Re: [Springframework-developer] ParameterNameMethodNameResolver

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

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
>>

Re: [Springframework-developer] ParameterNameMethodNameResolver

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

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.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
>>>
>>>
>
>

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

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
>  
>

Re: [Springframework-developer] ParameterNameMethodNameResolver

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

Well the funny thing is that I was in that code last night on the 
airplane home from my engagement this last week, the idea being that I 
would also add the code from the flow packages which can handle 
parameter names in the XXXX.x form which are submitted by image submit 
buttons. But I can't find the related code in the flow packages any 
longer. Unless I'm just not seeing it, Keith may have accidentally or 
intentionally removed it.

As for an alternate name, how about either paramNameMappings or 
paramNamesToMethodNames?

Colin


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
>>>>>          
>>>>>

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
>
> 

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
>
> 

Re: [Springframework-developer] ParameterNameMethodNameResolver

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

Unfortunately it's not that simple. I don't have the file to delete. 
It's something in the attic presumably (I get the infamous:
  cvs update: nothing known about 
test/org/springframework/web/servlet/mvc/multiaction/ParameterMethodNameResolverTests.java
error when I do an update), and I can't see the Attic or any other part 
of the actual CVS filessytem, at SF. So there's nothing to delete, and I 
can't check in a new file by that name.

Colin

Erwin Vervaet wrote:

> 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
>>
>>
>
>
>
> -------------------------------------------------------
> 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

[Springframework-developer] Re: ParameterNameMethodNameResolver

[<kat...@ho...>]

While on the topic, we should look at renaming the default parameter to 
something other than 'action'. This clashes with the form's 'action' in 
Javascript, and so is maybe not a good default. This would probably be 
OK as part of a 1.2 release.

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

Re: [Springframework-developer] Re: ParameterNameMethodNameResolver

[Matt R. <li...@ra...>]

On Mar 10, 2005, at 3:04 PM, kat...@ho... wrote:

> While on the topic, we should look at renaming the default parameter 
> to something other than 'action'. This clashes with the form's 
> 'action' in Javascript, and so is maybe not a good default. This would 
> probably be OK as part of a 1.2 release.

+1, I'd recommend "method" or something.  I've seen the same issue re: 
JavaScript, forms and button names.

Re: [Springframework-developer] Re: ParameterNameMethodNameResolver

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

Matt Raible wrote:

>
> On Mar 10, 2005, at 3:04 PM, kat...@ho... wrote:
>
>> While on the topic, we should look at renaming the default parameter 
>> to something other than 'action'. This clashes with the form's 
>> 'action' in Javascript, and so is maybe not a good default. This 
>> would probably be OK as part of a 1.2 release.
>
>
> +1, I'd recommend "method" or something.  I've seen the same issue re: 
> JavaScript, forms and button names.

Hmm,

I kind of like the idea, but this would probably break exsiting apps 
that relied on the "action" default. They would not require a recompile, 
a config change to set the property back to "action" would do, but I'm a 
bit loath to break backwards compatibility in a .X release for something 
that's not a true bug. Even now people can alway rename the param name.

Anybody else have an opinion on this?

Colin

Re: [Springframework-developer] Re: ParameterNameMethodNameResolver

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

First try "method", and if that's not found try "action" to deal with 
backwards compatibility?

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


> Matt Raible wrote:
>
>>
>> On Mar 10, 2005, at 3:04 PM, kat...@ho... wrote:
>>
>>> While on the topic, we should look at renaming the default parameter to 
>>> something other than 'action'. This clashes with the form's 'action' in 
>>> Javascript, and so is maybe not a good default. This would probably be 
>>> OK as part of a 1.2 release.
>>
>>
>> +1, I'd recommend "method" or something.  I've seen the same issue re: 
>> JavaScript, forms and button names.
>
> Hmm,
>
> I kind of like the idea, but this would probably break exsiting apps that 
> relied on the "action" default. They would not require a recompile, a 
> config change to set the property back to "action" would do, but I'm a bit 
> loath to break backwards compatibility in a .X release for something 
> that's not a true bug. Even now people can alway rename the param name.
>
> Anybody else have an opinion on this?
>
> 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
>
> 

Re: [Springframework-developer] Re: ParameterNameMethodNameResolver

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

How do you disable it then? Right now you can set the string to 
something you know is not going to come in.

Erwin Vervaet wrote:

> First try "method", and if that's not found try "action" to deal with 
> backwards compatibility?
>
> Erwin Vervaet
> erw...@er...
> ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...>
> To: <spr...@li...>
> Sent: Thursday, March 10, 2005 11:18 PM
> Subject: Re: [Springframework-developer] Re: 
> ParameterNameMethodNameResolver
>
>
>> Matt Raible wrote:
>>
>>>
>>> On Mar 10, 2005, at 3:04 PM, kat...@ho... wrote:
>>>
>>>> While on the topic, we should look at renaming the default 
>>>> parameter to something other than 'action'. This clashes with the 
>>>> form's 'action' in Javascript, and so is maybe not a good default. 
>>>> This would probably be OK as part of a 1.2 release.
>>>
>>>
>>>
>>> +1, I'd recommend "method" or something.  I've seen the same issue 
>>> re: JavaScript, forms and button names.
>>
>>
>> Hmm,
>>
>> I kind of like the idea, but this would probably break exsiting apps 
>> that relied on the "action" default. They would not require a 
>> recompile, a config change to set the property back to "action" would 
>> do, but I'm a bit loath to break backwards compatibility in a .X 
>> release for something that's not a true bug. Even now people can 
>> alway rename the param name.
>>
>> Anybody else have an opinion on this?
>>
>> Colin
>