Menu
▾
▴
springframework-developer
|
From: Kopylenko, D. <dko...@ac...> - 2004-02-17 19:23:36
|
Backward compatible - +1 -----Original Message----- From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20 Sent: Tuesday, February 17, 2004 2:10 PM To: spr...@li... 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... =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 ------------------------------------------------------- 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=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-02-17 22:17:57
|
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. =20 Juergen =20 ________________________________ 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. ______________________________________________________________________ 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 ------------------------------------------------------- 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 |
|
From: Tim K. <tim...@vi...> - 2004-02-17 22:37:22
|
I don=92t have an opinion either way, but if nobody's requested it - (don=92t know if someone did)then why add it? That=92s where feature = bloat comes from, and I don=92t necessarily see XML as an data-type that encourages/promotes shortcuts. Just ask any web designer where HTML got us. -tim -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Tuesday, February 17, 2004 5:11 PM To: spr...@li... Subject: Re: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests 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. =20 Juergen =20 ________________________________ 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. ______________________________________________________________________ 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 ------------------------------------------------------- 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 ------------------------------------------------------- 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 |
|
From: Colin S. <col...@ex...> - 2004-02-17 23:25:53
|
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ürgen höller [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ürgen höller [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ürgen höller [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=2425898 >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. > > |
|
From: Rod J. <rod...@in...> - 2004-02-18 07:05:17
|
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 > |
|
From: <jue...@we...> - 2004-02-17 22:59:21
|
Ehm, regarding a request for it, have a look at the subject ;-) =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Tim Kettering Gesendet: Di 17.02.2004 23:31 An: spr...@li... Betreff: RE: [Springframework-developer] Re: [springframework - Open = Discussion] Two feature requests I don't have an opinion either way, but if nobody's requested it - (don't know if someone did)then why add it? That's where feature bloat comes from, and I don't necessarily see XML as an data-type that encourages/promotes shortcuts. Just ask any web designer where HTML got us. -tim -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Tuesday, February 17, 2004 5:11 PM To: spr...@li... Subject: Re: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests 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. ______________________________________________________________________ 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 ------------------------------------------------------- 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 ------------------------------------------------------- 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 ------------------------------------------------------- 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 |
|
From: Tim K. <tim...@vi...> - 2004-02-17 23:13:44
|
Oh, oops, my bad. My other opinion still stands tho. :) -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Tuesday, February 17, 2004 5:54 PM To: spr...@li... Subject: Re: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests Ehm, regarding a request for it, have a look at the subject ;-) =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag von Tim Kettering Gesendet: Di 17.02.2004 23:31 An: spr...@li... Betreff: RE: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests I don't have an opinion either way, but if nobody's requested it - (don't know if someone did)then why add it? That's where feature bloat comes from, and I don't necessarily see XML as an data-type that encourages/promotes shortcuts. Just ask any web designer where HTML got us. -tim -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Tuesday, February 17, 2004 5:11 PM To: spr...@li... Subject: Re: [Springframework-developer] Re: [springframework - Open Discussion] Two feature requests 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. ______________________________________________________________________ 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 ------------------------------------------------------- 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 ------------------------------------------------------- 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 ------------------------------------------------------- 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 ------------------------------------------------------- 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 |
|
From: <jue...@we...> - 2004-02-18 11:07:30
|
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 |
