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

[Rod J. <rod...@in...>]

I'm not keen to relax this. I think XML structures where you get "either =
an
element or text" are messy.

I'm not "religious" on it, but I like the present approach. With XMLBuddy=
 or
any decent XML editor it's a non-issue as it helps with the structure, an=
d
it's good to see it explicit.

Editing XML without such a tool just doesn't make sense, IMO. I haven't
typed a <value> element for months.

Regards,
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 7:02 PM
Subject: [Springframework-developer] Fw: [springframework - Open Discussi=
on]
Two feature requests


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

Juergen


________________________________

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 u=
rl)

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 error=
s
relating
to not including the nested <value> element.  Also, some docs give exampl=
es
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 respective=
ly,
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




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer