1) Add a default attribute to the ParameterMethodNameResolver. Currently, if the parameter is not present, this resolver just bombs all over... Having a default would be trivial to implement and allow the developer to let the application proceed when a parameter was not provided (no reason to pollute the GET url)
2) This might be a religious issue, but it would be very convenient if the requirement of using a nested <value> element in <property> elements, for values was lifted. Either there is CDATA (in which case we assume it's a literal value), or there are nested elements. Having both could simply result in a configuration error. This would save typing and lots of cumbersome errors relating to not including the nested <value> element. Also, some docs give examples with literals without this <value> element.
The other things I've run into is: in mapping handlers, although you can inspect the request and response arguments, you cannot rewrite them (since the interfaces do not provide mutators). This makes using request wrappers impossible. I suggest another form of method signature for handlers which take objects which hold a reference to HttpServletRequest and HttpServletResponse respectively, instead of having those objects as direct, immutable arguments.
To get around this I have overridden a handleRequestInternal method in my controller and just call super.handleRequestInternal giving it my HttpServletRequestWrapper.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The SourceForge trackers are deactivated because we use a JIRA instance now (see Spring website)...
ad 1) Good point. Just added, to be committed tomorrow.
ad 2) Another good point, I've considered that myself repeatedly. While I do appreciate the explicit notion of String values, I wouldn't mind allowing for plain CDATA as String value too. What do others think?
Juergen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since there are no trackers...
I have two feature requests, and some comments
1) Add a default attribute to the ParameterMethodNameResolver. Currently, if the parameter is not present, this resolver just bombs all over... Having a default would be trivial to implement and allow the developer to let the application proceed when a parameter was not provided (no reason to pollute the GET url)
2) This might be a religious issue, but it would be very convenient if the requirement of using a nested <value> element in <property> elements, for values was lifted. Either there is CDATA (in which case we assume it's a literal value), or there are nested elements. Having both could simply result in a configuration error. This would save typing and lots of cumbersome errors relating to not including the nested <value> element. Also, some docs give examples with literals without this <value> element.
The other things I've run into is: in mapping handlers, although you can inspect the request and response arguments, you cannot rewrite them (since the interfaces do not provide mutators). This makes using request wrappers impossible. I suggest another form of method signature for handlers which take objects which hold a reference to HttpServletRequest and HttpServletResponse respectively, instead of having those objects as direct, immutable arguments.
To get around this I have overridden a handleRequestInternal method in my controller and just call super.handleRequestInternal giving it my HttpServletRequestWrapper.
The SourceForge trackers are deactivated because we use a JIRA instance now (see Spring website)...
ad 1) Good point. Just added, to be committed tomorrow.
ad 2) Another good point, I've considered that myself repeatedly. While I do appreciate the explicit notion of String values, I wouldn't mind allowing for plain CDATA as String value too. What do others think?
Juergen