Menu
▾
▴
springframework-developer — Spring Framework developers list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <tri...@tr...> - 2003-07-18 13:55:19
|
Juergen, > I consider that an interesting idea: As an alternative to InitializingBean, > we could indeed add such an "initializing_method" attribute, specifying a > no-arg init method on the object. That would allow for initialization that > depends on multiple properties without implementing any Spring-specific > interface. What you think about this? +1 I see no disadvantages, and it would be nice to not having to depend on any Spring interfaces at all. Thomas |
|
From: <jue...@we...> - 2003-07-18 07:06:44
|
Um9kLA0KIA0KSSBjb25zaWRlciBhIG5ldyBzcGVjaWFsIGF0dHJpYnV0ZSAiaW5pdC1tZXRob2Qi IG1vc3QgYXBwcm9wcmlhdGUuIEkgd291bGRuJ3QgdXNlIGEgZGVmYXVsdCBtZXRob2QgbmFtZSB0 aG91Z2gsIGFzIGJ5IGRlZmF1bHQgdGhlcmUgc2hvdWxkIHNpbXBseSBiZSBubyBpbml0IG1ldGhv ZCBhdCBhbGwuIE9mIGNvdXJzZSwgY2hlY2tpbmcgZm9yIEluaXRpYWxpemluZ0JlYW4gd2lsbCBz dGlsbCBoYXBwZW4gaW4gYW55IGNhc2UsIHByb2JhYmx5IGFmdGVyIHRoZSAiaW5pdC1tZXRob2Qi IGNoZWNrLg0KIA0KQWN0dWFsbHksIHRoaXMgc2hvdWxkIGJlIHByZXR0eSBlYXN5IHRvIGltcGxl bWVudDogSnVzdCBjaGVjayBmb3IgdGhlICJpbml0LW1ldGhvZCIgYXR0cmlidXRlIGFuZCBpbnZv a2UgYSByZXNwZWN0aXZlIG5vLWFyZyBtZXRob2QgdmlhIHJlZmxlY3Rpb24uIFdvdWxkIHlvdSBt aW5kIGltcGxlbWVudGluZyB0aGlzLCBhcyBJIGhhdmVuJ3QgdG91Y2hlZCB0aGUgQmVhbkZhY3Rv cnkgaW1wbGVtZW50YXRpb25zIHRoYXQgbXVjaCBteXNlbGY/DQogDQpJJ20gcXVpdGUga2VlbiB0 byBnZXQgdGhpcyBpbnRvIDAuOS4xLCBhcyBJJ2QgbGlrZSB0byB3YWl0IGZvciBUaG9tYXMgQWNo bGVpdG5lcidzIGxvYWQgdGVzdCByZXN1bHRzIGFueXdheS4gUmVsZWFzaW5nIHNvbWUgdGltZSBu ZXh0IHdlZWsgc2hvdWxkIGJlIGdvb2QgZW5vdWdoIC0gNCB3ZWVrcyBhZnRlciAwLjkuDQogDQpS ZWdhcmRzLA0KSnVlcmdlbg0KIA0KIA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQt LS0tLSANCglWb246IFJvZCBKb2huc29uIFttYWlsdG86cm9kLmpvaG5zb25AaW50ZXJmYWNlMjEu Y29tXSANCglHZXNlbmRldDogRnIgMTguMDcuMjAwMyAwODo1MCANCglBbjogasO8cmdlbiBow7Zs bGVyIFt3ZXJrM0FUXTsgc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3Jn ZS5uZXQgDQoJQ2M6IA0KCUJldHJlZmY6IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0g Rnc6IFtzcHJpbmdmcmFtZXdvcmsgLSBPcGVuIERpc2N1c3Npb25dIFJFOiBCZWFuRmFjdG9yeT0+ R2VuZXJpYyBDb250YWluZXINCgkNCgkNCg0KCUkgdGhpbmsgdGhlcmUncyBtZXJpdCBpbiB0aGlz IGlkZWEuIEFzIGl0IGhhcHBlbnMsIGl0J3Mgc29tZXRoaW5nIEkndmUNCgl0aG91Z2h0IG9mIGEg ZmV3IHRpbWVzIG15c2VsZiwgYnV0IG5ldmVyIHNlZW4gdGhhdCBtdWNoIGFkdmFudGFnZSBpbi4g T24NCglyZWZsZWN0aW9uIEkgZ3Vlc3MgZWxpbWluYXRpbmcgeWV0IGFub3RoZXIgY29udGFpbmVy IGRlcGVuZGVuY3kgaXMgYSBnb29kDQoJdGhpbmcuDQoJDQoJSG93IHdvdWxkIHlvdSBwcm9wb3Nl IGltcGxlbWVudGluZyBpdD8gQW4gYWRkaXRpb25hbCAic3BlY2lhbCIgYXR0cmlidXRlDQoJbGlr ZSBjbGFzcyBvciBwYXJlbnQ/IFdpdGggYSBkZWZhdWx0IG9mIGluaXQoKSBvciBzb21ldGhpbmc/ DQoJDQoJVGhlIHNpZ25hdHVyZSB3b3VsZCBuZWVkIHRvIGJlIGFibGUgdG8gdGhyb3cgYW55IGV4 Y2VwdGlvbi4NCgkNCglPbiBiYWxhbmNlLCBJIHRoaW5rIHRoaXMgaXMgYSBnb29kIGlkZWEgYW5k IGFtIGluIGZhdm91ciBvZiBpdC4NCgkNCglSZWdhcmRzLA0KCVJvZA0KCQ0KCS0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0NCglGcm9tOiAiasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSIgPGp1 ZXJnZW4uaG9lbGxlckB3ZXJrM2F0LmNvbT4NCglUbzogPHNwcmluZ2ZyYW1ld29yay1kZXZlbG9w ZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KCVNlbnQ6IEZyaWRheSwgSnVseSAxOCwgMjAwMyA1 OjU0IEFNDQoJU3ViamVjdDogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIEZ3OiBbc3ByaW5n ZnJhbWV3b3JrIC0gT3BlbiBEaXNjdXNzaW9uXQ0KCVJFOiBCZWFuRmFjdG9yeT0+R2VuZXJpYyBD b250YWluZXINCgkNCgkNCgk+IFJvZCwgZXZlcnlvbmUsDQoJPg0KCT4gSSBjb25zaWRlciB0aGF0 IGFuIGludGVyZXN0aW5nIGlkZWE6IEFzIGFuIGFsdGVybmF0aXZlIHRvDQoJSW5pdGlhbGl6aW5n QmVhbiwgd2UgY291bGQgaW5kZWVkIGFkZCBzdWNoIGFuICJpbml0aWFsaXppbmdfbWV0aG9kIg0K CWF0dHJpYnV0ZSwgc3BlY2lmeWluZyBhIG5vLWFyZyBpbml0IG1ldGhvZCBvbiB0aGUgb2JqZWN0 LiBUaGF0IHdvdWxkIGFsbG93DQoJZm9yIGluaXRpYWxpemF0aW9uIHRoYXQgZGVwZW5kcyBvbiBt dWx0aXBsZSBwcm9wZXJ0aWVzIHdpdGhvdXQgaW1wbGVtZW50aW5nDQoJYW55IFNwcmluZy1zcGVj aWZpYyBpbnRlcmZhY2UuIFdoYXQgeW91IHRoaW5rIGFib3V0IHRoaXM/DQoJPg0KCT4gSnVlcmdl bg0KCT4NCgk+DQoJPg0KCT4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KCT4g Vm9uOiBTb3VyY2VGb3JnZS5uZXQgW21haWx0bzpub3JlcGx5QHNvdXJjZWZvcmdlLm5ldF0NCgk+ IEdlc2VuZGV0OiBGciAxOC4wNy4yMDAzIDAxOjQxDQoJPiBBbjogbm9yZXBseUBzb3VyY2Vmb3Jn ZS5uZXQNCgk+IENjOg0KCT4gQmV0cmVmZjogW3NwcmluZ2ZyYW1ld29yayAtIE9wZW4gRGlzY3Vz c2lvbl0gUkU6IEJlYW5GYWN0b3J5PT5HZW5lcmljDQoJQ29udGFpbmVyDQoJPg0KCT4NCgk+DQoJ Pg0KCT4gUmVhZCBhbmQgcmVzcG9uZCB0byB0aGlzIG1lc3NhZ2UgYXQ6DQoJPiBodHRwczovL3Nv dXJjZWZvcmdlLm5ldC9mb3J1bS9tZXNzYWdlLnBocD9tc2dfaWQ9MjEwOTQzNw0KCT4gQnk6IHNr cm9haA0KCT4NCgk+IE9rLCBpJ2xsIGJ1eSBub3QgY2hhbmdpbmcgdGhlIHhtbCBiaW5kaW5nIHN0 dWZmLiBIb3cgY29tZSBhbiBhbiBvcHRpb25hbA0KCTxiZWFuPg0KCT4gYXR0cmlidXRlIGNhbGxl ZCBpbml0aWFsaXppbmdfbWV0aG9kIHdhcyBub3QgYWRkZWQ/IFRoZSBiZWFuIGZhY3RvcnkgY2Fu DQoJdGhlbg0KCT4gaW52b2tlIHNvbWUgbmFtZWQgbm8gYXJnIGluaXQgbWV0aG9kIG9uIHRoZSBv YmplY3QuDQoJPg0KCT4NCgk+DQoJPg0KCT4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4gWW91IGFyZSByZWNl aXZpbmcgdGhpcyBlbWFpbCBiZWNhdXNlIHlvdSBlbGVjdGVkIHRvIG1vbml0b3IgdGhpcyBmb3J1 bS4NCgk+IFRvIHN0b3AgbW9uaXRvcmluZyB0aGlzIGZvcnVtLCBsb2dpbiB0byBTb3VyY2VGb3Jn ZS5uZXQgYW5kIHZpc2l0Og0KCT4gaHR0cHM6Ly9zb3VyY2Vmb3JnZS5uZXQvZm9ydW0vdW5tb25p dG9yLnBocD9mb3J1bV9pZD0yNTAzMzkNCgk+DQoJPg0KCT4gTkh1MXlqanpYORBMMnYgempyempy eiByfSB+e3p65YqtdcKWfnpxen57eg0KCQ0KCQ0KCQ0KDQo= |
|
From: Rod J. <rod...@in...> - 2003-07-18 06:52:32
|
I think there's merit in this idea. As it happens, it's something I've thought of a few times myself, but never seen that much advantage in. On reflection I guess eliminating yet another container dependency is a good thing. How would you propose implementing it? An additional "special" attribute like class or parent? With a default of init() or something? The signature would need to be able to throw any exception. On balance, I think this is a good idea and am in favour of it. Regards, Rod ----- Original Message ----- From: "jürgen höller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Friday, July 18, 2003 5:54 AM Subject: [Springframework-developer] Fw: [springframework - Open Discussion] RE: BeanFactory=>Generic Container > Rod, everyone, > > I consider that an interesting idea: As an alternative to InitializingBean, we could indeed add such an "initializing_method" attribute, specifying a no-arg init method on the object. That would allow for initialization that depends on multiple properties without implementing any Spring-specific interface. What you think about this? > > Juergen > > > > -----Ursprüngliche Nachricht----- > Von: SourceForge.net [mailto:no...@so...] > Gesendet: Fr 18.07.2003 01:41 > An: no...@so... > Cc: > Betreff: [springframework - Open Discussion] RE: BeanFactory=>Generic Container > > > > > Read and respond to this message at: > https://sourceforge.net/forum/message.php?msg_id=2109437 > By: skroah > > Ok, i'll buy not changing the xml binding stuff. How come an an optional <bean> > attribute called initializing_method was not added? The bean factory can then > invoke some named no arg init method on the object. > > > > > ______________________________________________________________________ > 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=250339 > > > NHu1yjjzX9L2v zjrzjrz r} ~{zz劭u~zqz~{z |
|
From: <jue...@we...> - 2003-07-18 04:56:09
|
Um9kLCBldmVyeW9uZSwNCiANCkkgY29uc2lkZXIgdGhhdCBhbiBpbnRlcmVzdGluZyBpZGVhOiBB cyBhbiBhbHRlcm5hdGl2ZSB0byBJbml0aWFsaXppbmdCZWFuLCB3ZSBjb3VsZCBpbmRlZWQgYWRk IHN1Y2ggYW4gImluaXRpYWxpemluZ19tZXRob2QiIGF0dHJpYnV0ZSwgc3BlY2lmeWluZyBhIG5v LWFyZyBpbml0IG1ldGhvZCBvbiB0aGUgb2JqZWN0LiBUaGF0IHdvdWxkIGFsbG93IGZvciBpbml0 aWFsaXphdGlvbiB0aGF0IGRlcGVuZHMgb24gbXVsdGlwbGUgcHJvcGVydGllcyB3aXRob3V0IGlt cGxlbWVudGluZyBhbnkgU3ByaW5nLXNwZWNpZmljIGludGVyZmFjZS4gV2hhdCB5b3UgdGhpbmsg YWJvdXQgdGhpcz8NCiANCkp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFj aHJpY2h0LS0tLS0gDQoJVm9uOiBTb3VyY2VGb3JnZS5uZXQgW21haWx0bzpub3JlcGx5QHNvdXJj ZWZvcmdlLm5ldF0gDQoJR2VzZW5kZXQ6IEZyIDE4LjA3LjIwMDMgMDE6NDEgDQoJQW46IG5vcmVw bHlAc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglCZXRyZWZmOiBbc3ByaW5nZnJhbWV3b3JrIC0g T3BlbiBEaXNjdXNzaW9uXSBSRTogQmVhbkZhY3Rvcnk9PkdlbmVyaWMgQ29udGFpbmVyDQoJDQoJ DQoNCg0KCVJlYWQgYW5kIHJlc3BvbmQgdG8gdGhpcyBtZXNzYWdlIGF0Og0KCWh0dHBzOi8vc291 cmNlZm9yZ2UubmV0L2ZvcnVtL21lc3NhZ2UucGhwP21zZ19pZD0yMTA5NDM3DQoJQnk6IHNrcm9h aA0KCQ0KCU9rLCBpJ2xsIGJ1eSBub3QgY2hhbmdpbmcgdGhlIHhtbCBiaW5kaW5nIHN0dWZmLiBI b3cgY29tZSBhbiBhbiBvcHRpb25hbCA8YmVhbj4NCglhdHRyaWJ1dGUgY2FsbGVkIGluaXRpYWxp emluZ19tZXRob2Qgd2FzIG5vdCBhZGRlZD8gVGhlIGJlYW4gZmFjdG9yeSBjYW4gdGhlbg0KCWlu dm9rZSBzb21lIG5hbWVkIG5vIGFyZyBpbml0IG1ldGhvZCBvbiB0aGUgb2JqZWN0Lg0KCQ0KCQ0K CQ0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCglZb3UgYXJlIHJlY2VpdmluZyB0aGlzIGVtYWlsIGJlY2F1 c2UgeW91IGVsZWN0ZWQgdG8gbW9uaXRvciB0aGlzIGZvcnVtLg0KCVRvIHN0b3AgbW9uaXRvcmlu ZyB0aGlzIGZvcnVtLCBsb2dpbiB0byBTb3VyY2VGb3JnZS5uZXQgYW5kIHZpc2l0Og0KCWh0dHBz Oi8vc291cmNlZm9yZ2UubmV0L2ZvcnVtL3VubW9uaXRvci5waHA/Zm9ydW1faWQ9MjUwMzM5DQoJ DQoNCg== |
|
From: Ken K. <kk...@kk...> - 2003-07-17 14:57:24
|
Juergen,
Way cool!! I guess it is pretty flexible, as I should have suspected ;-)
. I'll be sure to discuss this in the petclinic tutorial.
Ken
jürgen höller [werk3AT] wrote:
>Thomas,
>
>The reason why there is no automatic support for Integer or Date is that it's unclear how to parse them by default. As you noted, there is more than one way to handle empty values when binding to Integer, and parsing floating point decimals is locale-specific (e.g. "1234.5" in English vs "1.234,5" in German notation), as is parsing Dates. That's why I introduced CustomDateEditor, CustomNumberEditor, and CustomBooleanEditor: They allow you to specify the exact parsing behavior, depending on the current _request_, to be able to respect current locale etc.
>
>Note that these editors do not only parse strings into the respective property type but also vice versa, being applied on Errors.getFieldValue. So locale-specific form field values can be set to respective bean properties but also rendered in a suitable way on redisplay of the form (e.g. via the bind tag). Without proper framework support, such stuff can be quite tedious to write. Try to achieve this with a Struts ActionForm, for example: Every such field had to be a String there to accept invalid values, and you would have to do all the locale-specific parsing and rendering yourself.
>
>BTW, we use both CustomDateEditor and CustomNumberEditor in practice at werk3AT. For us, this pattern is convenient and works nicely.
>
>Regarding distinct "typeMismatch" error messages: Ken, as you've noted, you can specify "typeMismatch.myField" messages for type mismatches on the respective field. Don't forget that you can even specify "typeMismatch.myBean.myField" messages for type mismatches on the respective field of the respective bean ("myBean" being the name of the bean in the model)! What more fine-granular way of associating messages would you need?
>
>Thomas, if you'd like to add additional options to CustomNumberEditor, e.g. BigDecimal and BigInteger support as you've proposed, please go ahead! We can definitely benefit from more type parsing and rendering options.
>
>Regards,
>Juergen
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Ken Krebs [mailto:kk...@kk...]
> Gesendet: Mi 16.07.2003 22:52
> An: tri...@tr...
> Cc: spr...@li...
> Betreff: [Springframework-developer] PropertyEditing
>
>
> Thomas,
>
> <Thomas>
> Also, is there a way to distinguish betweeen a blank and an
> invalid number - I get typeMismatch for both, but sometimes a blank could be OK.
> </Thomas>
>
> If you override initBinder() in your Form to install a CustomNumberEditor, you can specify allowEmpty=true in the constructor to allow an empty String to pass through. You can then handle the empty String in your Validator if you wish.
>
> It seems to me that PropertyEditors could be fertile ground for useful extension.
>
> I do think we need something more flexible in the way BeanWrapperImpl, PropertyEditors, and Validators coordinate error handling. The typeMismatch error strings are tied to a particular fieldName but the same fieldName could possibly be used on different Forms to fulfill a somewhat different function. It's not clear in my mind yet what the right mechanism for doing this is.
>
> Regards,
> Ken
>
>
>
|
|
From: <jue...@we...> - 2003-07-17 14:05:46
|
Jean-Pierre, I guess my recent tests weren't thorough enough. Inheritance of = attributeCSV does _not_ work with the current Spring version. I've just looked into this issue: The reason is modified behavior of the = bean factory, which now _replaces_ a property value if is defined again. = It does not call the property setter multiple times like before. This = behavior is actually more consistent in terms of property value = handling, as it doesn't make sense to call a normal setter repeatedly on = bean initialization. Unfortunately, the new behaviour has the drawback that inheriting static = attributes via repeated setting of attributeCSV on a web view is not = possible anymore - it will overwrite the superclass value now. Note that = the repeated setting has only worked before because the attributesCSV = setter isn't a real bean setter: It calls addStaticAttribute for each = name/value pair, adding attributes on repeated setter calls. All things considered, we should simply define all static attributes on = each view instead of relying on repeated property setting via some = atypical bean setter. I've just changed the countries code accordingly. = BTW, I've also turned all links between pages into relative ones, which = for example makes moving the directory structure easier, and modified = the build file to include iText and POI. Juergen -----Original Message----- From: jp....@ti... [mailto:jp....@ti...] Sent: Wednesday, July 16, 2003 6:28 PM To: j=FCrgen h=F6ller [werk3AT] Subject: RE: [Springframework-developer] CSV instable? Thanks Juergen. I have cleaned all at work, but I still have the same = issues. I will download the repository from scratch at home.=20 Jean-Pierre ---------- Initial Header ----------- From : j=FCrgen h=F6ller [werk3AT] <jue...@we...> To : = <jp....@ti...>,<spr...@li...> Cc :=20 Date : Wed, 16 Jul 2003 18:17:22 +0200 Subject : RE: [Springframework-developer] CSV instable? Hi JP, On my system everything works nicely. I've just rechecked, attributeCSV = works too, with and without bean definition inheritance. I guess the = origin of your issues is outside of Spring. Juergen -----Original Message----- From: jp....@ti... [mailto:jp....@ti...] Sent: Wednesday, July 16, 2003 12:41 PM To: spr...@li... Subject: [Springframework-developer] CSV instable? Hello, Since I have upgrated from the last CSV changes from the week-end, I = have two wrong behaviors. 1) JBoss is no more able to correctly undeploy the new application and = patially crashes in this situation. As long as I don't try to undeploy = it, early applications undeploy and redeploy correctly. 2) In the view property file, the defaultView's attributeCSV entries are = no more merged with the current view ones. The other properties are = correctly inherited. Regards, Jean-Pierre =20 ********** L'ADSL A 20 EUR/MOIS********** Tiscali propose l'ADSL le moins cher du march=E9 : 20 EUR/mois et le = modem ADSL offert !=20 Pour profiter de cette offre exceptionnelle, cliquez ici : = http://register.tiscali.fr/adsl/ Offre soumise =E0 conditions. ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ********** L'ADSL A 20 EUR/MOIS********** Tiscali propose l'ADSL le moins cher du march=E9 : 20 EUR/mois et le = modem ADSL offert !=20 Pour profiter de cette offre exceptionnelle, cliquez ici : = http://register.tiscali.fr/adsl/ Offre soumise =E0 conditions. |
|
From: <jue...@we...> - 2003-07-17 12:17:52
|
Everyone, I've clarified the stored procedure issue with Thomas today. The proc = did not see the inserted row because it did not take part in the = HibernateTransactionManager-driven transaction. The reason for this was = that our StoredProdedure template fetched its JDBC Connection via = dataSource.getConnection, creating a new one in any case. I've just = changed this to DataSourceUtils.getConnection(dataSource): Now it will = receive a thread-bound Connection when in a DataSourceTransactionManager = or HibernateTransactionManager transaction. I've already committed the = change. BTW, I've also reintroduced eager initialization of the = SQLExceptionTranslater used by JdbcTemplate, but now in = afterPropertiesSet instead of in setDataSource. The original motivation = for lazy init was to avoid unnecessary initialization of the default = translater on setDataSource if a translater is explicitly set via = setSQLExceptionTranslater anyway. Unfortunately, lazy init via = connection metadata after a SQLException got thrown seems to cause = problems with some JNDI connection pools resp. JTA implementations. A = user reported this on our SourceForge forums yesterday. So it is now = recommended to call afterPropertiesSet on JdbcTemplate creation (new in = 0.9.1), or set the SQLExceptionTranslater explictly (also in 0.9), to = avoid potentially erroneous behavior. Juergen -----Original Message----- From: j=FCrgen h=F6ller [werk3AT]=20 Sent: Tuesday, July 15, 2003 5:06 PM To: Achleitner Thomas; spr...@li... Subject: RE: [Springframework-user] Transactions: Hibernate and Jdbc mixed up Thomas, Probably you just need to flush the Hibernate Session immediately at the = end of your Hibernate code. You can do this manually in your = HibernateCallback implementation by calling "session.flush()" at the = end, or better set your HibernateTemplate's "forceFlush" property to = true. By default, a Hibernate transaction just flushes at the end of the = transaction. This enables a very "soft" rollback until very late, as = normally the database will not have received any SQL statements yet. The = Javadoc of HibernateTemplate's "setForceFlush" method talks about this a = bit. As your JDBC access code depends on the Hibernate commands actually sent = to the database, you'll need the forced flush in the middle of the = transaction. Juergen -----Original Message----- From: Achleitner Thomas [mailto:ac...@ec...] Sent: Tuesday, July 15, 2003 4:42 PM To: spr...@li... Subject: [Springframework-user] Transactions: Hibernate and Jdbc mixed up Hello! Consider following situation (in pseudo code): doInTransaction() insert row with id =3D 1 using Hibernate (sessionFactory) load row with id =3D 1 using Jdbc / StoredProcedure (dataSource) end Since the insert and the load statement are executed within one single transaction the load statement is expected to return the inserted row with id =3D 1. I am using spring 0.9 and this is not working for me. = What is wrong about my configuration? ... <bean id=3D"dataSource" class=3D"com.interface21.jndi.JndiObjectFactoryBean"> <property name=3D"jndiName"> <value>jdbc/lms</value> </property> </bean> <bean id=3D"sessionFactory" class=3D"com.interface21.orm.hibernate.LocalSessionFactoryBean"> </bean> <bean id=3D"transactionManager" =09 class=3D"com.interface21.orm.hibernate.HibernateTransactionManager"> <property name=3D"sessionFactory"> <ref bean=3D"sessionFactory"/> </property> <property name=3D"dataSource"> <ref bean=3D"dataSource"/> </property> </bean> ... The insert statement gets executed in a DAO where property sessionFactory is set. The load statement gets executed in a separate DAO where property dataSource is set. thomas ------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 _______________________________________________ Springframework-user mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 _______________________________________________ Springframework-user mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-user |
|
From: <jue...@we...> - 2003-07-17 06:10:59
|
VGhvbWFzLA0KIA0KVGhlIHJlYXNvbiB3aHkgdGhlcmUgaXMgbm8gYXV0b21hdGljIHN1cHBvcnQg Zm9yIEludGVnZXIgb3IgRGF0ZSBpcyB0aGF0IGl0J3MgdW5jbGVhciBob3cgdG8gcGFyc2UgdGhl bSBieSBkZWZhdWx0LiBBcyB5b3Ugbm90ZWQsIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgd2F5IHRv IGhhbmRsZSBlbXB0eSB2YWx1ZXMgd2hlbiBiaW5kaW5nIHRvIEludGVnZXIsIGFuZCBwYXJzaW5n IGZsb2F0aW5nIHBvaW50IGRlY2ltYWxzIGlzIGxvY2FsZS1zcGVjaWZpYyAoZS5nLiAiMTIzNC41 IiBpbiBFbmdsaXNoIHZzICIxLjIzNCw1IiBpbiBHZXJtYW4gbm90YXRpb24pLCBhcyBpcyBwYXJz aW5nIERhdGVzLiBUaGF0J3Mgd2h5IEkgaW50cm9kdWNlZCBDdXN0b21EYXRlRWRpdG9yLCBDdXN0 b21OdW1iZXJFZGl0b3IsIGFuZCBDdXN0b21Cb29sZWFuRWRpdG9yOiBUaGV5IGFsbG93IHlvdSB0 byBzcGVjaWZ5IHRoZSBleGFjdCBwYXJzaW5nIGJlaGF2aW9yLCBkZXBlbmRpbmcgb24gdGhlIGN1 cnJlbnQgX3JlcXVlc3RfLCB0byBiZSBhYmxlIHRvIHJlc3BlY3QgY3VycmVudCBsb2NhbGUgZXRj Lg0KIA0KTm90ZSB0aGF0IHRoZXNlIGVkaXRvcnMgZG8gbm90IG9ubHkgcGFyc2Ugc3RyaW5ncyBp bnRvIHRoZSByZXNwZWN0aXZlIHByb3BlcnR5IHR5cGUgYnV0IGFsc28gdmljZSB2ZXJzYSwgYmVp bmcgYXBwbGllZCBvbiBFcnJvcnMuZ2V0RmllbGRWYWx1ZS4gU28gbG9jYWxlLXNwZWNpZmljIGZv cm0gZmllbGQgdmFsdWVzIGNhbiBiZSBzZXQgdG8gcmVzcGVjdGl2ZSBiZWFuIHByb3BlcnRpZXMg YnV0IGFsc28gcmVuZGVyZWQgaW4gYSBzdWl0YWJsZSB3YXkgb24gcmVkaXNwbGF5IG9mIHRoZSBm b3JtIChlLmcuIHZpYSB0aGUgYmluZCB0YWcpLiBXaXRob3V0IHByb3BlciBmcmFtZXdvcmsgc3Vw cG9ydCwgc3VjaCBzdHVmZiBjYW4gYmUgcXVpdGUgdGVkaW91cyB0byB3cml0ZS4gVHJ5IHRvIGFj aGlldmUgdGhpcyB3aXRoIGEgU3RydXRzIEFjdGlvbkZvcm0sIGZvciBleGFtcGxlOiBFdmVyeSBz dWNoIGZpZWxkIGhhZCB0byBiZSBhIFN0cmluZyB0aGVyZSB0byBhY2NlcHQgaW52YWxpZCB2YWx1 ZXMsIGFuZCB5b3Ugd291bGQgaGF2ZSB0byBkbyBhbGwgdGhlIGxvY2FsZS1zcGVjaWZpYyBwYXJz aW5nIGFuZCByZW5kZXJpbmcgeW91cnNlbGYuDQogDQpCVFcsIHdlIHVzZSBib3RoIEN1c3RvbURh dGVFZGl0b3IgYW5kIEN1c3RvbU51bWJlckVkaXRvciBpbiBwcmFjdGljZSBhdCB3ZXJrM0FULiBG b3IgdXMsIHRoaXMgcGF0dGVybiBpcyBjb252ZW5pZW50IGFuZCB3b3JrcyBuaWNlbHkuDQogDQpS ZWdhcmRpbmcgZGlzdGluY3QgInR5cGVNaXNtYXRjaCIgZXJyb3IgbWVzc2FnZXM6IEtlbiwgYXMg eW91J3ZlIG5vdGVkLCB5b3UgY2FuIHNwZWNpZnkgInR5cGVNaXNtYXRjaC5teUZpZWxkIiBtZXNz YWdlcyBmb3IgdHlwZSBtaXNtYXRjaGVzIG9uIHRoZSByZXNwZWN0aXZlIGZpZWxkLiBEb24ndCBm b3JnZXQgdGhhdCB5b3UgY2FuIGV2ZW4gc3BlY2lmeSAidHlwZU1pc21hdGNoLm15QmVhbi5teUZp ZWxkIiBtZXNzYWdlcyBmb3IgdHlwZSBtaXNtYXRjaGVzIG9uIHRoZSByZXNwZWN0aXZlIGZpZWxk IG9mIHRoZSByZXNwZWN0aXZlIGJlYW4gKCJteUJlYW4iIGJlaW5nIHRoZSBuYW1lIG9mIHRoZSBi ZWFuIGluIHRoZSBtb2RlbCkhIFdoYXQgbW9yZSBmaW5lLWdyYW51bGFyIHdheSBvZiBhc3NvY2lh dGluZyBtZXNzYWdlcyB3b3VsZCB5b3UgbmVlZD8NCiANClRob21hcywgaWYgeW91J2QgbGlrZSB0 byBhZGQgYWRkaXRpb25hbCBvcHRpb25zIHRvIEN1c3RvbU51bWJlckVkaXRvciwgZS5nLiBCaWdE ZWNpbWFsIGFuZCBCaWdJbnRlZ2VyIHN1cHBvcnQgYXMgeW91J3ZlIHByb3Bvc2VkLCBwbGVhc2Ug Z28gYWhlYWQhIFdlIGNhbiBkZWZpbml0ZWx5IGJlbmVmaXQgZnJvbSBtb3JlIHR5cGUgcGFyc2lu ZyBhbmQgcmVuZGVyaW5nIG9wdGlvbnMuDQogDQpSZWdhcmRzLA0KSnVlcmdlbg0KIA0KIA0KDQoJ LS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IEtlbiBLcmVicyBbbWFp bHRvOmtrQGtrdGVjLmNvbV0gDQoJR2VzZW5kZXQ6IE1pIDE2LjA3LjIwMDMgMjI6NTIgDQoJQW46 IHRyaXNiZXJnQHRyaWRiLmNvbSANCglDYzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0 cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQmV0cmVmZjogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJd IFByb3BlcnR5RWRpdGluZw0KCQ0KCQ0KCVRob21hcywNCgkNCgk8VGhvbWFzPg0KCUFsc28sIGlz IHRoZXJlIGEgd2F5IHRvIGRpc3Rpbmd1aXNoIGJldHdlZWVuIGEgYmxhbmsgYW5kIGFuDQoJaW52 YWxpZCBudW1iZXIgLSBJIGdldCB0eXBlTWlzbWF0Y2ggZm9yIGJvdGgsIGJ1dCBzb21ldGltZXMg YSBibGFuayBjb3VsZCBiZSBPSy4NCgk8L1Rob21hcz4NCgkNCglJZiB5b3Ugb3ZlcnJpZGUgaW5p dEJpbmRlcigpIGluIHlvdXIgRm9ybSB0byBpbnN0YWxsIGEgQ3VzdG9tTnVtYmVyRWRpdG9yLCB5 b3UgY2FuIHNwZWNpZnkgYWxsb3dFbXB0eT10cnVlIGluIHRoZSBjb25zdHJ1Y3RvciB0byBhbGxv dyBhbiBlbXB0eSBTdHJpbmcgdG8gcGFzcyB0aHJvdWdoLiBZb3UgY2FuIHRoZW4gaGFuZGxlIHRo ZSBlbXB0eSBTdHJpbmcgaW4geW91ciBWYWxpZGF0b3IgaWYgeW91IHdpc2guDQoJDQoJSXQgc2Vl bXMgdG8gbWUgdGhhdCBQcm9wZXJ0eUVkaXRvcnMgY291bGQgYmUgZmVydGlsZSBncm91bmQgZm9y IHVzZWZ1bCBleHRlbnNpb24uDQoJDQoJSSBkbyB0aGluayB3ZSBuZWVkIHNvbWV0aGluZyBtb3Jl IGZsZXhpYmxlIGluIHRoZSB3YXkgQmVhbldyYXBwZXJJbXBsLCBQcm9wZXJ0eUVkaXRvcnMsIGFu ZCBWYWxpZGF0b3JzIGNvb3JkaW5hdGUgZXJyb3IgaGFuZGxpbmcuIFRoZSB0eXBlTWlzbWF0Y2gg ZXJyb3Igc3RyaW5ncyBhcmUgdGllZCB0byBhIHBhcnRpY3VsYXIgZmllbGROYW1lIGJ1dCB0aGUg c2FtZSBmaWVsZE5hbWUgY291bGQgcG9zc2libHkgYmUgdXNlZCBvbiBkaWZmZXJlbnQgRm9ybXMg dG8gZnVsZmlsbCBhIHNvbWV3aGF0IGRpZmZlcmVudCBmdW5jdGlvbi4gSXQncyBub3QgY2xlYXIg aW4gbXkgbWluZCB5ZXQgd2hhdCB0aGUgcmlnaHQgbWVjaGFuaXNtIGZvciBkb2luZyB0aGlzIGlz Lg0KCQ0KCVJlZ2FyZHMsDQoJS2VuDQoJIA0KCXRyaXNiZXJnQHRyaWRiLmNvbSB3cm90ZToNCgkN Cg0KCQlLZW4sDQoJCQ0KCQlUaGFua3MsIHRoYXQgbWFrZXMgaXQgY2xlYXJlci4NCgkJDQoJCUl0 IHNlZW1zIHRvIG1lIHRob3VnaCB0aGF0IHRoZSBiZWFuIGZhY3RvcmllcyBzdXBwb3J0IGRpZmZl cmVudCBkZWZhdWx0IG1hcHBpbmdzDQoJCWNvbXBhcmVkIHRvIHdoYXQgaXMgcHJvdmlkZWQgaW4g dGhlIGJpbmRpbmcgb2YgZm9ybSBmaWVsZHMuICBJIGNhbiBtYXAgdG8gYW4NCgkJSW50ZWdlciBp biBhIGJlYW4sIGJ1dCBub3QgaW4gYSBmb3JtIHdpdGhvdXQgZ2V0dGluZyBpbnRvIHByb3ZpZGlu ZyBhIGN1c3RvbQ0KCQlQcm9wZXJ0eUVkaXRvci4gIEFsc28sIGlzIHRoZXJlIGEgd2F5IHRvIGRp c3Rpbmd1aXNoIGJldHdlZWVuIGEgYmxhbmsgYW5kIGFuDQoJCWludmFsaWQgbnVtYmVyIC0gSSBn ZXQgdHlwZU1pc21hdGNoIGZvciBib3RoLCBidXQgc29tZXRpbWVzIGEgYmxhbmsgY291bGQgYmUg T0suDQoJCSBJZiB3ZSBzdXBwb3J0ZWQgSW50ZWdlciwgdGhlbiB0aGF0IHNob3VsZCBtYXAgdG8g YSBudWxsLCBhbmQgSSBjb3VsZCBkbyBteSBvbg0KCQl2YWxpZGF0aW9uIGluIGEgVmFsaWRhdG9y IGNsYXNzLiAgQW0gSSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlPw0KCQkNCgkJSSBoYXZlIG5vdCBz cGVudCBhIGxvdCBvZiB0aW1lIGxvb2tpbmcgdGhyb3VnaCB0aGUgc291cmNlIGNvZGUsIGJ1dCB0 aGVyZSBzZWVtcw0KCQl0byBiZSBzb21lIGFkZGl0aW9uYWwgbWFwcGluZyB0aGF0IHdlIHNob3Vs ZCBwcm92aWRlIGluIHRoZSBkZWZhdWx0IHNldHVwLiAgV2UNCgkJZG9uJ3Qgc2VlbSB0byBzdXBw b3J0IG1hcHBpbmcgYSBudW1lcmljIHN0cmluZyB0byBhIGphdmEubWF0aC5CaWdEZWNpbWFsLCBi dXQNCgkJdGhhdCBpcyBzb21ldGhpbmcgSSB0aGluayB3b3VsZCBiZSBoYW5keSBmb3IgZW50ZXJp bmcgbW9uZXRhcnkgYW1vdW50cyBldGMuICBJZg0KCQlhbnlib2R5IGlzIGFscmVhZHkgd29ya2lu ZyBvbiBhbnkgb2YgdGhpcywgbGV0IG1lIGtub3cgLSBpZiBub3QgSSdsbCBzcGVuZCBzb21lDQoJ CW1vcmUgdGltZSBhZGRpbmcgc29tZSBmdW5jdGlvbmFsaXR5Lg0KCQkNCgkJVGhvbWFzDQoJCQ0K CQkgIA0KDQoJCQlUaG9tYXMsDQoJCQkNCgkJCUp1ZXJnZW4gc2hvd2VkIG1lIGEgd2F5IHRvIGhh bmRsZSBhIHNpbWlsYXIgc2l0dWF0aW9uIGZvciBQZXRjbGluaWMncyANCgkJCURhdGUgZW50cnkg cmVxdWlyZW1lbnRzLg0KCQkJDQoJCQk8SnVlcmdlbj4NCgkJCQ0KCQkJDQoJCQlZb3UgY2FuIGVh c2lseSByZXBsYWNlIHRoZSBkZWZhdWx0IGVycm9yIG1lc3NhZ2UgYnkgZGVmaW5pbmcgYSANCgkJ CU1lc3NhZ2VTb3VyY2UsIGkuZS4gYSAibWVzc2FnZXMucHJvcGVydGllcyIgYnVuZGxlIG9yIHRo ZSBsaWtlLiBJZiB5b3UgDQoJCQlkZWZpbmUgYSBtZXNzYWdlIGZvciB0aGUga2V5ICJ0eXBlTWlz bWF0Y2giIHRoZXJlLCB5b3UnbGwgc2VlIHRoYXQgDQoJCQltZXNzYWdlIGluIHlvdXIgZm9ybSBp biBjYXNlIG9mIGFuIGVycm9yIHdpdGggY29kZSAidHlwZU1pc21hdGNoIi4gWW91IA0KCQkJY2Fu IGV2ZW4gZGVmaW5lIG1vcmUgc3BlY2lmaWMgbWVzc2FnZXMgbGlrZSBmb3IgInR5cGVNaXNtYXRj aC5teUZpZWxkIiANCgkJCW9yIGV2ZW4gInR5cGVNaXNtYXRjaC5teU9iamVjdC5teUZpZWxkIiB0 aGF0IHdpbGwgb25seSBnZXQgdXNlZCBvbiB0aGUgDQoJCQlzcGVjaWZpZWQgZmllbGQgcmVzcC4g b2JqZWN0IGFuZCBmaWVsZC4gT2YgY291cnNlIHRoaXMgd29ya3Mgd2l0aCB5b3VyIA0KCQkJb3du IGVycm9yIGNvZGVzIHRoYXQgeW91ciBvd24gdmFsaWRhdG9yIHByb2R1Y2VzIHRvby4gU2VlIHRo ZSBGaWVsZEVycm9yIA0KCQkJamF2YWRvYyBmb3IgZGV0YWlscy4NCgkJCQ0KCQkJPC9KdWVyZ2Vu Pg0KCQkJDQoJCQlUaGUgbWVzc2FnZSBnZXRzIHRyaWdnZXJlZCB2aWEgYW4gSWxsZWdhbEFyZ3Vt ZW50RXhjZXB0aW9uIHRocm93biBieSB0aGUgDQoJCQlQcm9wZXJ0eUVkaXRvci4gVGhlIGhhbmRs ZXIgdGhhdCBjYXRjaGVzIHRoZSBJbGxlZ2FsQXJndW1lbnRFeGNlcHRpb24gDQoJCQlhbmQgdHJp Z2dlcnMgdGhlIG1lc3NhZ2UgaXMgZG9UeXBlQ29udmVyc2lvbklmTmVjZXNzYXJ5KCkgaW4gDQoJ CQlCZWFuV3JhcHBlckltcGwuIFlvdSBtYXkgYWxzbyB3YW50IHRvIGhhdmUgYSBsb29rIGF0IA0K CQkJYmVhbnMucHJvcGVydHllZGl0b3JzLkN1c3RvbU51bWJlckVkaXRvci4gUGV0Y2xpbmljJ3Mg QWJzdHJhY3RDbGluaWNGb3JtIA0KCQkJc2hvd3MgaG93IHRvIGluc3RhbGwgYSBwcm9wZXJ0eSBl ZGl0b3IgaW4gaXQncyBvdmVycmlkZSBvZiANCgkJCUJhc2VDb21tYW5kQ29udHJvbGxlci5pbml0 QmluZGVyKCkuDQoJCQkNCgkJCVJlZ2FyZHMsDQoJCQlLZW4NCgkJCQ0KCQkJdHJpc2JlcmdAdHJp ZGIuY29tIHdyb3RlOg0KCQkJDQoJCQkgICAgDQoNCgkJCQlLZW4gYW5kIEFsbCwNCgkJCQkNCgkJ CQlBcmUgdGhlcmUgYW55IGV4YW1wbGVzIHdoZXJlIHRoZSBIVE1MIEZvcm0gaGFzIHNvbWUgaW5w dXQgZmllbGRzIHRoYXQgYXJlDQoJCQkJICAgICAgDQoNCgkJCXVzZWQNCgkJCSAgICANCg0KCQkJ CXRvIGVudGVyIG51bWVyaWMgdmFsdWVzLiAgV2hhdCBpcyB0aGUgYmVzdCB3YXkgdG8gaGFuZGxl IG5vbiBudW1lcmljIGlucHV0DQoJCQkJICAgICAgDQoNCgkJCWZvcg0KCQkJICAgIA0KDQoJCQkJ bnVtZXJpYyBmaWVsZHM/ICBJJ20gdHJ5aW5nIHRvIGJpbmQgdG8gYSBjb21tYW5kT2JqZWN0IHRo YXQgaGFzIGEgZmllbGQgdGhhdA0KCQkJCSAgICAgIA0KDQoJCQlpcw0KCQkJICAgIA0KDQoJCQkJ YW4gaW50ZWdlci4NCgkJCQkNCgkJCQlJIGhhdmUgdHJpZWQgdXNpbmcgYW4gaW50IGFuZCBpdCB3 b3JrcyBpZiBJIGVudGVyIGEgbnVtYmVyIGJ1dCBpZiBJIGxlYXZlDQoJCQkJICAgICAgDQoNCgkJ CXRoZQ0KCQkJICAgIA0KDQoJCQkJZmllbGQgYmxhbmsgb3IgZW50ZXIgYW4gbm9uIG51ZXJpYyB2 YWx1ZSwgdGhlbiBJIGdldCB0aGUgZm9sbG93aW5nIGVycm9yDQoJCQkJICAgICAgDQoNCgkJCW1l c3NhZ2UNCgkJCT5mcm9tIHRoZSBiaW5kIGR1cmluZyB2YWxpZGF0aW9uOg0KCQkJICAgIA0KDQoJ CQkJRmFpbGVkIHRvIGNvbnZlcnQgcHJvcGVydHkgdmFsdWUgb2YgdHlwZSBbamF2YS5sYW5nLlN0 cmluZ10gdG8gcmVxdWlyZWQNCgkJCQkgICAgICANCg0KCQkJdHlwZQ0KCQkJICAgIA0KDQoJCQkJ W2ludF07IG5lc3RlZCBleGNlcHRpb24gaXM6IGphdmEubGFuZy5OdW1iZXJGb3JtYXRFeGNlcHRp b246IEZvciBpbnB1dA0KCQkJCSAgICAgIA0KDQoJCQlzdHJpbmc6ICIiDQoJCQkgICAgDQoNCgkJ CQlVc2luZyBhbiBJbnRlZ2VyIGl0IGRvZXMgbm90IHdvcmsgYXQgYWxsIC0gSSBnZXQgdGhpcyBl cnJvciBtZXNzYWdlOg0KCQkJCQ0KCQkJCUZhaWxlZCB0byBjb252ZXJ0IHByb3BlcnR5IHZhbHVl IG9mIHR5cGUgW2phdmEubGFuZy5TdHJpbmddIHRvIHJlcXVpcmVkDQoJCQkJICAgICAgDQoNCgkJ CXR5cGUNCgkJCSAgICANCg0KCQkJCVtqYXZhLmxhbmcuSW50ZWdlcl07IG5lc3RlZCBleGNlcHRp b24gaXM6DQoJCQkJICAgICAgDQoNCgkJCWphdmEubGFuZy5JbGxlZ2FsQXJndW1lbnRFeGNlcHRp b246DQoJCQkgICAgDQoNCgkJCQlhcmd1bWVudCB0eXBlIG1pc21hdGNoDQoJCQkJDQoJCQkJVGhv bWFzDQoJCQkJDQoJCQkJDQoJCQkJIA0KCQkJCQ0KCQkJCSAgICAgIA0KDQoJCQkgICAgDQoNCgkJ DQoJCQ0KCQkgIA0KDQoNCg== |
|
From: Ken K. <kk...@kk...> - 2003-07-17 03:10:28
|
Thomas, I just updated the website with the Petclinic javadocs and tutorial (still unfinished, sigh) from CVS. I didn't update the app itself because it's visible functionality hasn't changed. Ken |
|
From: <tri...@tr...> - 2003-07-17 03:06:06
|
Just in case you haven't seen these - here are some links to what people say about Spring on the web: http://www.cwinters.com/News/show/?news_id=963 http://www.entwickler.com/itr/news/psecom,p,,_psframe,,linkobject,print_,nocontainer,1_,id,10658,nodeid,10.html http://www.blueskyonmars.com/archives/2003_07_09.html#000922 Thomas > All, > > If you are interested in the usage statistics for our website - here is the > link: > > http://www.sixgeeks.org/usage/www.springframework.org/ > > > There was a nice spike after The Server Side posting, and there is still a > respectable number of pagehits. > > Thomas > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <tri...@tr...> - 2003-07-16 21:40:22
|
All, If you are interested in the usage statistics for our website - here is the link: http://www.sixgeeks.org/usage/www.springframework.org/ There was a nice spike after The Server Side posting, and there is still a respectable number of pagehits. Thomas |
|
From: Ken K. <kk...@kk...> - 2003-07-16 20:59:47
|
Thomas, <Thomas> Also, is there a way to distinguish betweeen a blank and an invalid number - I get typeMismatch for both, but sometimes a blank could be OK. </Thomas> If you override initBinder() in your Form to install a CustomNumberEditor, you can specify allowEmpty=true in the constructor to allow an empty String to pass through. You can then handle the empty String in your Validator if you wish. It seems to me that PropertyEditors could be fertile ground for useful extension. I do think we need something more flexible in the way BeanWrapperImpl, PropertyEditors, and Validators coordinate error handling. The typeMismatch error strings are tied to a particular fieldName but the same fieldName could possibly be used on different Forms to fulfill a somewhat different function. It's not clear in my mind yet what the right mechanism for doing this is. Regards, Ken tri...@tr... wrote: >Ken, > >Thanks, that makes it clearer. > >It seems to me though that the bean factories support different default mappings >compared to what is provided in the binding of form fields. I can map to an >Integer in a bean, but not in a form without getting into providing a custom >PropertyEditor. Also, is there a way to distinguish betweeen a blank and an >invalid number - I get typeMismatch for both, but sometimes a blank could be OK. > If we supported Integer, then that should map to a null, and I could do my on >validation in a Validator class. Am I missing something here? > >I have not spent a lot of time looking through the source code, but there seems >to be some additional mapping that we should provide in the default setup. We >don't seem to support mapping a numeric string to a java.math.BigDecimal, but >that is something I think would be handy for entering monetary amounts etc. If >anybody is already working on any of this, let me know - if not I'll spend some >more time adding some functionality. > >Thomas > > > >>Thomas, >> >>Juergen showed me a way to handle a similar situation for Petclinic's >>Date entry requirements. >> >><Juergen> >> >> >>You can easily replace the default error message by defining a >>MessageSource, i.e. a "messages.properties" bundle or the like. If you >>define a message for the key "typeMismatch" there, you'll see that >>message in your form in case of an error with code "typeMismatch". You >>can even define more specific messages like for "typeMismatch.myField" >>or even "typeMismatch.myObject.myField" that will only get used on the >>specified field resp. object and field. Of course this works with your >>own error codes that your own validator produces too. See the FieldError >>javadoc for details. >> >></Juergen> >> >>The message gets triggered via an IllegalArgumentException thrown by the >>PropertyEditor. The handler that catches the IllegalArgumentException >>and triggers the message is doTypeConversionIfNecessary() in >>BeanWrapperImpl. You may also want to have a look at >>beans.propertyeditors.CustomNumberEditor. Petclinic's AbstractClinicForm >>shows how to install a property editor in it's override of >>BaseCommandController.initBinder(). >> >>Regards, >>Ken >> >>tri...@tr... wrote: >> >> >> >>>Ken and All, >>> >>>Are there any examples where the HTML Form has some input fields that are >>> >>> >>used >> >> >>>to enter numeric values. What is the best way to handle non numeric input >>> >>> >>for >> >> >>>numeric fields? I'm trying to bind to a commandObject that has a field that >>> >>> >>is >> >> >>>an integer. >>> >>>I have tried using an int and it works if I enter a number but if I leave >>> >>> >>the >> >> >>>field blank or enter an non nueric value, then I get the following error >>> >>> >>message >>>from the bind during validation: >> >> >>>Failed to convert property value of type [java.lang.String] to required >>> >>> >>type >> >> >>>[int]; nested exception is: java.lang.NumberFormatException: For input >>> >>> >>string: "" >> >> >>>Using an Integer it does not work at all - I get this error message: >>> >>>Failed to convert property value of type [java.lang.String] to required >>> >>> >>type >> >> >>>[java.lang.Integer]; nested exception is: >>> >>> >>java.lang.IllegalArgumentException: >> >> >>>argument type mismatch >>> >>>Thomas >>> >>> >>> >>> >>> >>> >> >> > > > > > > |
|
From: <tri...@tr...> - 2003-07-16 18:37:07
|
Ken, Thanks, that makes it clearer. It seems to me though that the bean factories support different default mappings compared to what is provided in the binding of form fields. I can map to an Integer in a bean, but not in a form without getting into providing a custom PropertyEditor. Also, is there a way to distinguish betweeen a blank and an invalid number - I get typeMismatch for both, but sometimes a blank could be OK. If we supported Integer, then that should map to a null, and I could do my on validation in a Validator class. Am I missing something here? I have not spent a lot of time looking through the source code, but there seems to be some additional mapping that we should provide in the default setup. We don't seem to support mapping a numeric string to a java.math.BigDecimal, but that is something I think would be handy for entering monetary amounts etc. If anybody is already working on any of this, let me know - if not I'll spend some more time adding some functionality. Thomas > Thomas, > > Juergen showed me a way to handle a similar situation for Petclinic's > Date entry requirements. > > <Juergen> > > > You can easily replace the default error message by defining a > MessageSource, i.e. a "messages.properties" bundle or the like. If you > define a message for the key "typeMismatch" there, you'll see that > message in your form in case of an error with code "typeMismatch". You > can even define more specific messages like for "typeMismatch.myField" > or even "typeMismatch.myObject.myField" that will only get used on the > specified field resp. object and field. Of course this works with your > own error codes that your own validator produces too. See the FieldError > javadoc for details. > > </Juergen> > > The message gets triggered via an IllegalArgumentException thrown by the > PropertyEditor. The handler that catches the IllegalArgumentException > and triggers the message is doTypeConversionIfNecessary() in > BeanWrapperImpl. You may also want to have a look at > beans.propertyeditors.CustomNumberEditor. Petclinic's AbstractClinicForm > shows how to install a property editor in it's override of > BaseCommandController.initBinder(). > > Regards, > Ken > > tri...@tr... wrote: > > >Ken and All, > > > >Are there any examples where the HTML Form has some input fields that are > used > >to enter numeric values. What is the best way to handle non numeric input > for > >numeric fields? I'm trying to bind to a commandObject that has a field that > is > >an integer. > > > >I have tried using an int and it works if I enter a number but if I leave > the > >field blank or enter an non nueric value, then I get the following error > message > >from the bind during validation: > > > >Failed to convert property value of type [java.lang.String] to required > type > >[int]; nested exception is: java.lang.NumberFormatException: For input > string: "" > > > >Using an Integer it does not work at all - I get this error message: > > > >Failed to convert property value of type [java.lang.String] to required > type > >[java.lang.Integer]; nested exception is: > java.lang.IllegalArgumentException: > >argument type mismatch > > > >Thomas > > > > > > > > > > |
|
From: Ken K. <kk...@kk...> - 2003-07-16 16:44:46
|
Thomas, I'll address your concern in the tutorial narrative. I suppose I ought to put some notes in the code too. Thanks again for your probing comments. Ken pr...@se... wrote: >Your reasoning (and Rod/Juergen's) makes perfect sense, and a quick look at >the source confirms the "bad smells" you mentioned. I know how a manager >feels now, asking a question based on incomplete info (I commented based on >the "design" I saw by the class names, and didn't actually dig into the code) >that is usually a very well-thought out decision by the programmer. "The >programmers always right" :) , I was just a little quick (and pointy-haired) >for a few minutes last night! > >My biggest concern seeing those changes was that our samples will be used by >many as a model of how to design their programs using Spring, and it may >appear to many that a Spring best-practice is to merge the business object >with the persistence object. While it makes perfect sense in this case (due >to the reasons you identified), it is not totally clear why this decision was >made by looking at the code. We should probably document why this code is >done this way to help newbies understand that this a solution to this specific >problem (and not necessarily the "normal" way for most apps). Documenting it >will also prevent somebody (like me) who isn't familiar with the history and >design decisions from changing it back to how it was before. > > >Great work, >Trevor > > > > >------------------------------------------------------- >This SF.net email is sponsored by: VM Ware >With VMware you can run multiple operating systems on a single machine. >WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the >same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > |
|
From: <jue...@we...> - 2003-07-16 16:19:18
|
Hi JP, On my system everything works nicely. I've just rechecked, attributeCSV = works too, with and without bean definition inheritance. I guess the = origin of your issues is outside of Spring. Juergen -----Original Message----- From: jp....@ti... [mailto:jp....@ti...] Sent: Wednesday, July 16, 2003 12:41 PM To: spr...@li... Subject: [Springframework-developer] CSV instable? Hello, Since I have upgrated from the last CSV changes from the week-end, I = have two wrong behaviors. 1) JBoss is no more able to correctly undeploy the new application and = patially crashes in this situation. As long as I don't try to undeploy = it, early applications undeploy and redeploy correctly. 2) In the view property file, the defaultView's attributeCSV entries are = no more merged with the current view ones. The other properties are = correctly inherited. Regards, Jean-Pierre =20 ********** L'ADSL A 20 EUR/MOIS********** Tiscali propose l'ADSL le moins cher du march=E9 : 20 EUR/mois et le = modem ADSL offert !=20 Pour profiter de cette offre exceptionnelle, cliquez ici : = http://register.tiscali.fr/adsl/ Offre soumise =E0 conditions. ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rod J. <rod...@in...> - 2003-07-16 12:10:59
|
> My biggest concern seeing those changes was that our samples will be used by > many as a model of how to design their programs using Spring, and it may > appear to many that a Spring best-practice is to merge the business object > with the persistence object. While it makes perfect sense in this case (due > to the reasons you identified), it is not totally clear why this decision was > made by looking at the code. We should probably document why this code is > done this way to help newbies understand that this a solution to this specific > problem (and not necessarily the "normal" way for most apps). Documenting it > will also prevent somebody (like me) who isn't familiar with the history and > design decisions from changing it back to how it was before. Good point. We should also make it clear that Spring is _perfect_ for implementing the DAO pattern. Rod > > > Great work, > Trevor > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <pr...@se...> - 2003-07-16 11:10:10
|
Your reasoning (and Rod/Juergen's) makes perfect sense, and a quick look at the source confirms the "bad smells" you mentioned. I know how a manager feels now, asking a question based on incomplete info (I commented based on the "design" I saw by the class names, and didn't actually dig into the code) that is usually a very well-thought out decision by the programmer. "The programmers always right" :) , I was just a little quick (and pointy-haired) for a few minutes last night! My biggest concern seeing those changes was that our samples will be used by many as a model of how to design their programs using Spring, and it may appear to many that a Spring best-practice is to merge the business object with the persistence object. While it makes perfect sense in this case (due to the reasons you identified), it is not totally clear why this decision was made by looking at the code. We should probably document why this code is done this way to help newbies understand that this a solution to this specific problem (and not necessarily the "normal" way for most apps). Documenting it will also prevent somebody (like me) who isn't familiar with the history and design decisions from changing it back to how it was before. Great work, Trevor |
|
From: =?iso-8859-1?Q?<jp....@ti...> - 2003-07-16 10:40:56
|
Hello,=0D=0A=0D=0ASince I have upgrated from the last CSV changes from th= e week-end, I have two wrong behaviors.=0D=0A=0D=0A1) JBoss is no more ab= le to correctly undeploy the new application and patially crashes in this= situation. As long as I don't try to undeploy it, early applications und= eploy and redeploy correctly.=0D=0A=0D=0A2) In the view property file, th= e defaultView's attributeCSV entries are no more merged with the current = view ones. The other properties are correctly inherited.=0D=0A=0D=0ARegar= ds,=0D=0AJean-Pierre=0D=0A =0A=0A********** L'ADSL A 20 EUR/MOIS********= **=0ATiscali propose l'ADSL le moins cher du march=E9 : 20 EUR/mois et le= modem ADSL offert ! =0APour profiter de cette offre exceptionnelle, cliq= uez ici : http://register.tiscali.fr/adsl/=0AOffre soumise =E0 conditions= .=0A |
|
From: Ken K. <kk...@kk...> - 2003-07-16 04:15:03
|
Thomas, Juergen showed me a way to handle a similar situation for Petclinic's Date entry requirements. <Juergen> You can easily replace the default error message by defining a MessageSource, i.e. a "messages.properties" bundle or the like. If you define a message for the key "typeMismatch" there, you'll see that message in your form in case of an error with code "typeMismatch". You can even define more specific messages like for "typeMismatch.myField" or even "typeMismatch.myObject.myField" that will only get used on the specified field resp. object and field. Of course this works with your own error codes that your own validator produces too. See the FieldError javadoc for details. </Juergen> The message gets triggered via an IllegalArgumentException thrown by the PropertyEditor. The handler that catches the IllegalArgumentException and triggers the message is doTypeConversionIfNecessary() in BeanWrapperImpl. You may also want to have a look at beans.propertyeditors.CustomNumberEditor. Petclinic's AbstractClinicForm shows how to install a property editor in it's override of BaseCommandController.initBinder(). Regards, Ken tri...@tr... wrote: >Ken and All, > >Are there any examples where the HTML Form has some input fields that are used >to enter numeric values. What is the best way to handle non numeric input for >numeric fields? I'm trying to bind to a commandObject that has a field that is >an integer. > >I have tried using an int and it works if I enter a number but if I leave the >field blank or enter an non nueric value, then I get the following error message >from the bind during validation: > >Failed to convert property value of type [java.lang.String] to required type >[int]; nested exception is: java.lang.NumberFormatException: For input string: "" > >Using an Integer it does not work at all - I get this error message: > >Failed to convert property value of type [java.lang.String] to required type >[java.lang.Integer]; nested exception is: java.lang.IllegalArgumentException: >argument type mismatch > >Thomas > > > > |
|
From: Ken K. <kk...@kk...> - 2003-07-16 03:50:20
|
Trevor, I'm really glad you asked :-) . Really, I do appreciate your questioning this design decision and truly welcome more criticism. It helps me learn. I first got the suggestion from Juergen: <Juergen> Regarding the implementation: I've noticed that the Clinic interface duplicates ClinicDAO's methods to a large extent, and that ClinicImpl adds cross-referencing and caching to the entities (data access aspects). This isn't really proper separation between data access code and business logic, but of course the borders are often somewhat blurring. In our case, it's probably more appropriate to merge the two, i.e. offer just a Clinic interface, with the common logic in an AbstractClinic base class, and a ClinicJdbcImpl default implementation. IMO, the app simply isn't complex enough for separated business and data access layers. The more important thing is clear separation between the business and the web layer: Those two should never be merged, not even in very simple apps. </Juergen> These comments really hit home because I was already not liking the smell of that duplication in the Clinic and ClinicDAO interfaces, but I really didn't understand at the time why this should be so. When Rod seconded this opinion, I agreed to go ahead and do it, although I was still a bit unsure about it. While doing the refactoring, It finally dawned on me as to why this approach makes sense for this app. The situation really became clear to me while I was writing the new TestCase for Owner (+1 for XP). The application is all about database access and there is very little business logic in the application outside of that. What few business rules there are have been implemented by the Validators and the Owner class. Therefore, this change doesn't really exclude other options as you can just provide other classes that implement the Clinic interface, i.e. XmlClinic, EJBClinic, MockClinic or whatever. Since AbstractJdbcClinic doesn't really implement any business logic besides persistence, there is no need to derive from it except for Jdbc purposes. The reason why I didn't implement an AbstractClinic class as Juergen had suggested was simply because I couldn't find anything for it to do. I think the advantage that this change brings is that is simpler and clearer and as such suits the tutorial purpose just a little bit better. There actually is no clear and strong advantage to either implementation choice for this situation, IMO. Regards, Ken pr...@se... wrote: >Before I comment, thanks for all your work on the demo Ken. I haven't been >able to contribute to the project for a few months, and due to work/family >commitments, I probably won't be able to start contributing again until >September. I simply mention this so you can evaluate my comments accordingly >(I value action more than talk, and right now you're acting, I'm just >talking :) ). > > > > >>>I have just commited my latest changes to Petclinic. They include >>>the following changes: >>>- ClinicImpl, ClinicDAO, and ClinicJdbcDAO have been replaced >>>by AbstractJdbcClinic, HsqlClinic, and MysqlClinic. >>> >>> > >I question why you would make this change? I understand (and like) the Hsql >and MySql implementations since they show the core of what Spring allows (that >you can make specific implementations where required). However, you are >coupling the implementation of clinic with the dao interface and the jdbc dao >implementation. I may be missing something, but isn't this a step backwards? >In my mind, the implementation of Clinic should be seperate from its storage >mechansim (ClinicDAO), and the DAO would be an interface which is then >implemented (in this case by the above mentioned AbstractJDBC and then the 2 >db-specific implementations. To quote Rod's book "sometimes we are unable to >seperate the two (business logic and persistence logic)" but I don't see this >as one of those exceptions. While I personally hate EJB, this new design >totally excludes it (since there is no clinic object unless you use JDBC), but >it also would exclude other persistence mechanisms (xml, flat-file, etc.) or >even using an "unpersisted" version of the clinic (unless you choose to carry >around all the JDBC stuff as baggage which adds 13 RdbmsOperation objects). > >Sorry to question your design choice, and maybe I'm totally missing something, >just curious on what advantage this change brings. > >Trevor D. Cook > > >------------------------------------------------------- >This SF.Net email sponsored by: Parasoft >Error proof Web apps, automate testing & more. >Download & eval WebKing and get a free book. >www.parasoft.com/bulletproofapps1 >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > |
|
From: <tri...@tr...> - 2003-07-16 03:35:28
|
Ken and All, Are there any examples where the HTML Form has some input fields that are used to enter numeric values. What is the best way to handle non numeric input for numeric fields? I'm trying to bind to a commandObject that has a field that is an integer. I have tried using an int and it works if I enter a number but if I leave the field blank or enter an non nueric value, then I get the following error message from the bind during validation: Failed to convert property value of type [java.lang.String] to required type [int]; nested exception is: java.lang.NumberFormatException: For input string: "" Using an Integer it does not work at all - I get this error message: Failed to convert property value of type [java.lang.String] to required type [java.lang.Integer]; nested exception is: java.lang.IllegalArgumentException: argument type mismatch Thomas |
|
From: Rod J. <rod...@in...> - 2003-07-15 20:47:50
|
> I question why you would make this change? I understand (and like) the Hsql > and MySql implementations since they show the core of what Spring allows (that > you can make specific implementations where required). However, you are > coupling the implementation of clinic with the dao interface and the jdbc dao > implementation. I may be missing something, but isn't this a step backwards? > In my mind, the implementation of Clinic should be seperate from its storage > mechansim (ClinicDAO), and the DAO would be an interface which is then > implemented (in this case by the above mentioned AbstractJDBC and then the 2 > db-specific implementations. To quote Rod's book "sometimes we are unable to > seperate the two (business logic and persistence logic)" but I don't see this > as one of those exceptions. While I personally hate EJB, this new design > totally excludes it (since there is no clinic object unless you use JDBC), but > it also would exclude other persistence mechanisms (xml, flat-file, etc.) or > even using an "unpersisted" version of the clinic (unless you choose to carry > around all the JDBC stuff as baggage which adds 13 RdbmsOperation objects). Without going into the specifics, which I don't have time to think about right now, I should say that I've changed my opinions somewhat since the book regarding separating persistence & business logic. Where transparent persistence mechanisms such as JDO or Hibernate are concerned, I think there's no reason not to put business logic in persistent objects, as the persistent objects are not polluted by persistence-mechanism specific code. Entity beans have lumbered us with some baggage in this area. With JDBC, separation via a DAO does make more sense, as otherwise the JDBC code can pollute the object model. However in the case of the PetClinic I seem to recall there being a high level of duplication between DAO and business objects. In this case, simple subclassing to handle the persistence details in the subclasses probably makes more sense. Regards, Rod |
|
From: <pr...@se...> - 2003-07-15 20:13:56
|
Before I comment, thanks for all your work on the demo Ken. I haven't been able to contribute to the project for a few months, and due to work/family commitments, I probably won't be able to start contributing again until September. I simply mention this so you can evaluate my comments accordingly (I value action more than talk, and right now you're acting, I'm just talking :) ). >>I have just commited my latest changes to Petclinic. They include >>the following changes: >>- ClinicImpl, ClinicDAO, and ClinicJdbcDAO have been replaced >>by AbstractJdbcClinic, HsqlClinic, and MysqlClinic. I question why you would make this change? I understand (and like) the Hsql and MySql implementations since they show the core of what Spring allows (that you can make specific implementations where required). However, you are coupling the implementation of clinic with the dao interface and the jdbc dao implementation. I may be missing something, but isn't this a step backwards? In my mind, the implementation of Clinic should be seperate from its storage mechansim (ClinicDAO), and the DAO would be an interface which is then implemented (in this case by the above mentioned AbstractJDBC and then the 2 db-specific implementations. To quote Rod's book "sometimes we are unable to seperate the two (business logic and persistence logic)" but I don't see this as one of those exceptions. While I personally hate EJB, this new design totally excludes it (since there is no clinic object unless you use JDBC), but it also would exclude other persistence mechanisms (xml, flat-file, etc.) or even using an "unpersisted" version of the clinic (unless you choose to carry around all the JDBC stuff as baggage which adds 13 RdbmsOperation objects). Sorry to question your design choice, and maybe I'm totally missing something, just curious on what advantage this change brings. Trevor D. Cook |
|
From: Ken K. <kk...@kk...> - 2003-07-15 18:17:47
|
All,
I have just commited my latest changes to Petclinic. They include the
following changes:
- ClinicImpl, ClinicDAO, and ClinicJdbcDAO have been replaced by
AbstractJdbcClinic, HsqlClinic, and MysqlClinic.
- ClinicImplTest has been replaced by JdbcClinicTest.
- Added some more tests.
- Removed AbstractSearchController.
- Many improvements to Javadocs and program comments.
- Made the app name consistent in the Tomcat context definition files
and added a separate app log file.
- Tightened and pruned the Java code.
- Removed the "incrementer" bean, functionality replaced in database
specific classes.
- All of the default RdbmsOperation objects (in AbstractJdbcClinic) are
replaceable by subclasses, which also provide the incrementers.
- Updated and improved tutorial html. Simpler html ( and much smaller!),
no longer generated from an MSWord file.
NOTE:The tutorial docs are still very much unfinished. I hope to rectify
that soon.
Alef,
Sorry I wasn't able to commit on Saturday as I said I would. I got an
emergency call and had to hustle off to Atlanta to fix an ice cream
freezer. The changes I made to the jsps' are relatively trivial.
Ken
Alef Arendsen (JTeam) wrote:
>Ok, I can implement it all, no problem, however, I've got to do it in my spare time, which means in the evenings, because I have to do some other things this week as well...
>
>So it'll probably finished by Thursday evening... If that's alright with you?
>
>Cheers,
>
>Alef
>
>-----Oorspronkelijk bericht-----
>Van: spr...@li... [mailto:spr...@li...] Namens Alef Arendsen (JTeam)
>Verzonden: Sunday, July 13, 2003 7:27 PM
>Aan: 'Ken Krebs'; 'jürgen höller [werk3AT]'
>CC: spr...@li...
>Onderwerp: [Springframework-developer] RE: Tags using expression language?? & Petclinic
>
>
>I'm currently checking out the sourcecode. Somehow I wasn't able to during the last couple of days. Well, anyway, I'll have a look into it and I'll let you know tomorrow...
>
>Cheers,
>
>Alef
>
>-----Oorspronkelijk bericht-----
>Van: Ken Krebs [mailto:kk...@kk...]
>Verzonden: Saturday, July 12, 2003 6:22 PM
>Aan: jürgen höller [werk3AT]; al...@jt...
>CC: spr...@li...
>Onderwerp: Tags using expression language?? & Petclinic
>
>
>Eliminating repetitive code in the jsp's is something I'd very much like
>to see. Alef: thanks for your contribution, it looks like it will help.
>
>I've been in the process lately of refactoring Petclinic's Clinic
>implementation along with code tightening and documentation improvements
>and am just about ready to commit the changes. I WILL commit these
>changes sometime later today. A couple of jsp's have minor changes.
>
>Alef: If you would like to make the changes to the jsp's, please go
>ahead. If not, I'll do it. Please let me know if you will be doing it.
>
>Regards,
>Ken
>
>jürgen höller [werk3AT] wrote:
>
>
>
>>I've introduced support for EL on tag attributes yesterday, already
>>committed. Thanks for the idea and the prototype, Alef! I hope you are satisfied with the integration. You're very welcome to try it out :-)
>>
>>There's a new ExpressionEvaluationsUtils class now in
>>com.interface21.web.util, taking a String argument value and parsing it to Object, String, int, or boolean. It will just attempt EL evaluation if the value starts with "${", else it will simply parse the value with standard means.
>>
>>All of Spring's tags use this class now for all attributes, simply
>>delegating to the respective ExpressionEvaluationsUtils method in each setter. This means that all attributes still accept normal String values as before (like <i21:bind path="person.name">), but also EL expressions (like <i21:bind path="${bindPath}">).
>>
>>For EL evaluation, ExpressionEvaluationsUtils depends on Jakarta's JSTL
>>implementation (standard.jar). It doesn't have a runtime dependency if just parsing normal String values though, as it delegates EL evaluation to an inner class that will just get loaded in case of actual EL expressions. So you'll just need the Jakarta JSTL implementation in your classpath if you actually use EL attribute values on tags.
>>
>>BTW, our AopProxy uses a similar mechanism to avoid a runtime
>>dependency on CGLIB. If just proxying interfaces, it will use standard J2SE proxies. Only if you try to proxy a class itself, it will invoke CGLIB by delegating to a respective inner class.
>>
>>Finally, we should adapt PetClinic to use EL expressions on its bind
>>tags. Alef has already shown the way in the prototype that he sent. Ken, what do you think? Would you like Alef to do this?
>>
>>Juergen
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: jürgen höller [werk3AT]
>> Gesendet: Fr 11.07.2003 08:13
>> An: al...@jt...; spr...@li...
>> Cc:
>> Betreff: Re: [Springframework-developer] Tags using expression
>>language??
>>
>>
>>
>> Alef,
>>
>> I've just browsed your code - this looks very interesting! It makes
>>iterating such repetitive form fields like in the petclinic much easier. I'll have a look at the implementation details, and if everything works out I'll add a clean room version to the main source tree promptly.
>>
>> I wonder if we could make that work with any JSTL implementation, not
>>just the Jakarta one, although I wouldn't mind a dependency on the latter for this feature.
>>
>> Cool stuff :-)
>>
>> Juergen
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Alef Arendsen [mailto:al...@jt...]
>> Gesendet: Di 08.07.2003 19:43
>> An: jürgen höller [werk3AT]; spr...@li...
>> Cc:
>> Betreff: RE: [Springframework-developer] Tags using expression
>>language??
>>
>>
>>
>> Ok, here we go...
>>
>> Like you said, at first glance, it does not look like the i21:bind tag
>> needs expressionalization (hmmm, nice huh ;-). However, in the petclinic
>> demo app I'm seeing a lot of input.jsps in the jsp/fields directory.
>> These are things I'm hoping to solve using for instance EL-based tags...
>> Attached you'll find a reworked version of the ownerForm. It does not
>> use the JSPs from the fields directory anymore, but uses only one
>> input.jsp that uses the bindstatus object to create the input
>>field.
>>
>> Ok, it's still all rough and reworking the tags is a little bit more
>> work than the 15 minutes I spent on it now, but maybe you're getting the
>> idea.
>>
>> Consequences for adding / reworking the tags:
>>
>> 1. dependency on jakarta-jstl-1.0.3 (jakarta.apache.org/taglib -->
>> standard).
>> 2. dependency on jstl-1.0.3 (java.sun.com)
>> 3. In case you want to have both version in there, an extending class
>> for each tag
>> 4. For each tag, a BeanInfo class
>> 5. I wasn't able to use the EvalHelper from jakarta, so I copied it
>> (hmmm... not so nice, is it ;-)
>>
>> Probably I don't have time this week or something to refactor them to be
>> all EL-based... Just let me know if you'd like it.
>>
>> Well, that's it for now, still discovering really cool features and
>> already running out (brain)memory to think up everything I could do with
>> Spring ;-)
>>
>> Cheers,
>>
>> Alef
>>
>>
>> NHS^隊[){([j J뢺kyƮ^اj+x:0Zuڕg*)jw`z֟盢0
>> Z(~(W(}iT)~{
>> +ׯzZ)zXX*kx Šuޖ^X( ~zwilq zlX)ߣ))~{
>> +ׯzZ)
>>
>>?????????????????????????????????????????ӆ+?^?隊[)?{(??[??ڭ?(~?+??鮊 Y?
>>ڦ??j?h??^??-?x?????:0?Zw?jU?l????݁?Z~??n?$? 0???j? ??(???W???(}?i?_???????????????????????????????????*k?x ???Š??ׯzZ)z???X??X??*k?x ???Š??ׯzZ)z???l??.?ǟ?? ?w???i????+-??(?? ~??{??b????+-?w???k?x ???Š??ׯzZ)
>>
>>
>>
>>
>>
>>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Parasoft
>Error proof Web apps, automate testing & more.
>Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 _______________________________________________
>Springframework-developer mailing list Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
|
|
From: Luke T. <ne...@fr...> - 2003-07-15 17:00:23
|
Rod Johnson wrote: > Luke, > > This is looking really good. Thanks. I might give Maven another try myself. > > Guys, we should try to put the report somewhere. The source xreference is > particularly nice. > I've added a page with some basic information to the Wiki: http://www.springframework.org/wiki/jsp/Wiki?MavenBuild I'll be away for the next week hiding from computers in the Hebrides, but I'll expand on it when I get back. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523C http://www.monkeymachine.ltd.uk |
1239 messages has been excluded from this view by a project administrator.
