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

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

I'm against this. People should use XML editors, so typing is irrelevant.
And we shouldn't add "conveniences" that we wouldn't use ourselves.

Messing up our XML format may hurt us in future. For example, we should
probably add an XSLT stylesheet to generate pretty doco of bean definitio=
n
files. This gets a bit harder with such blurring.

----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Tuesday, February 17, 2004 11:23 PM
Subject: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests


> It doesn't feel incredibly clean to me, but I am not opposed to adding
> it. My one concern would be if this constrained us somehow for future
> enhancements, but I can't think of any issues right now...
>
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
> >I'd like to hear further opinions on this... Does anyone strongly obje=
ct
to adding that shortcut style as option? Anyone actually preferring the
shortcut style? I wouldn't use it myself, but I don't mind the option.
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag =
von
Rod Johnson
> >Gesendet: Di 17.02.2004 22:50
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests
> >
> >
> >
> >Well if it's backward compatible... But I don't think we should advoca=
te
> >this.
> >
> >----- Original Message -----
> >From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> >To: <spr...@li...>
> >Sent: Tuesday, February 17, 2004 7:10 PM
> >Subject: [Springframework-developer] Re: [springframework - Open
Discussion]
> >Two feature requests
> >
> >
> >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...
> >
> >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 i=
nto
a
> >certain style here.
> >
> >If noone objects, I'll commit this promptly.
> >
> >Juergen
> >
> >
> >________________________________
> >
> >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...
> >
> >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... Hav=
ing
a
> >default would be trivial to implement and allow the developer to let t=
he
> >application
> >proceed when a parameter was not provided (no reason to pollute the GE=
T
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> elemen=
ts,
> >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 c=
an
> >inspect
> >the request and response arguments, you cannot rewrite them (since the
> >interfaces
> >do not provide mutators).  This makes using request wrappers impossibl=
e.
I
> >suggest another form of method signature for handlers which take objec=
ts
> >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.
> >
> >
>
>
>
>
> -------------------------------------------------------
> 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=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>