[Springframework-developer] Re: [springframework - Open Discussion] Two feature requests

[<jue...@we...>]

Actually, this is extremely easy to implement: I've just adapted =
DefaultXmlBeanDefinitionParser and it works nicely, still allowing for =
<value> tags but also for text values as CDATA...
=20
Of course, I do appreciate the explicit notion of a value, but I guess =
we should allow for this shortcut style too - we shouldn't force people =
into a certain style here.
=20
If noone objects, I'll commit this promptly.
=20
Juergen
=20

________________________________

Von: j=FCrgen h=F6ller [werk3AT]
Gesendet: Di 17.02.2004 20:02
An: spr...@li...
Betreff: Fw: [springframework - Open Discussion] Two feature requests


Any thoughts on suggestion number 2? As I wrote in that forum, I've =
considered that myself repeatedly...
=20
Juergen
=20

________________________________

Von: SourceForge.net [mailto:no...@so...]
Gesendet: Mo 16.02.2004 18:10
An: no...@so...
Betreff: [springframework - Open Discussion] Two feature requests




Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=3D2425898
By: aaron

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.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=3D250339