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

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

Okidoki, if there aren't any strongly positive replies, I consider this =
turned down.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Wednesday, February 18, 2004 8:01 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: [springframework - Open
Discussion] Two feature requests


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 =
definition
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 =
object
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 =
advocate
> >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 =
into
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... =
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.
> >
> >
>
>
>
>
> -------------------------------------------------------
> 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
>




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