Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-07-08 14:27:58
|
Hi Alef, Thanks for the compliments - they are much appreciated! :-) The SourceForge archives are somewhat peculiar, I've experienced that = "unarchived" message myself repeatedly. Never mind, they'll reappear... Regarding JSTL EL usage: As BindErrorsTag and BindTag just take a bean = name resp. a bean path (consisting of bean name + a property path) as = attributes, I don't see much place for EL there - maybe for iteration = over a predefined set of bound fields? The main candidate for EL support = is probably MessageTag: It supports message lookup via code, or simply = writing a message text (possibly automatically HTML-escaped) - both = could be computed by EL expressions. Do you have any concrete EL usage scenarios with Spring tags? In any = case, if you'd like to look into potential EL support for MessageTag or = others, please go ahead! Regards, Juergen -----Original Message----- From: Alef Arendsen [mailto:al...@jt...] Sent: Tuesday, July 08, 2003 4:16 PM To: spr...@li... Subject: [Springframework-developer] Tags using expression language?? Hi all, Somehow I was able to browse the archives this morning, but now they appear as being unarchived on sourceforge. Kind of strange. So I wasn't able to browse through the archives for the following question: Is there a version of the custom tags available using the JSTL expression language somewhere or is there any special reason not to have those. If nothing is available and nobody objects, I'd like to have a go, since it would make life a lot easier... Cheers, Alef By the way, I'm even more stunned than before. Everything I'm in need of is there!!! Now I'll stop complimented you guys, otherwise you might even think the job is done ;-) ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2003-07-11 06:15:16
|
QWxlZiwNCiANCkkndmUganVzdCBicm93c2VkIHlvdXIgY29kZSAtIHRoaXMgbG9va3MgdmVyeSBp bnRlcmVzdGluZyEgSXQgbWFrZXMgaXRlcmF0aW5nIHN1Y2ggcmVwZXRpdGl2ZSBmb3JtIGZpZWxk cyBsaWtlIGluIHRoZSBwZXRjbGluaWMgbXVjaCBlYXNpZXIuIEknbGwgaGF2ZSBhIGxvb2sgYXQg dGhlIGltcGxlbWVudGF0aW9uIGRldGFpbHMsIGFuZCBpZiBldmVyeXRoaW5nIHdvcmtzIG91dCBJ J2xsIGFkZCBhIGNsZWFuIHJvb20gdmVyc2lvbiB0byB0aGUgbWFpbiBzb3VyY2UgdHJlZSBwcm9t cHRseS4NCiANCkkgd29uZGVyIGlmIHdlIGNvdWxkIG1ha2UgdGhhdCB3b3JrIHdpdGggYW55IEpT VEwgaW1wbGVtZW50YXRpb24sIG5vdCBqdXN0IHRoZSBKYWthcnRhIG9uZSwgYWx0aG91Z2ggSSB3 b3VsZG4ndCBtaW5kIGEgZGVwZW5kZW5jeSBvbiB0aGUgbGF0dGVyIGZvciB0aGlzIGZlYXR1cmUu DQogDQpDb29sIHN0dWZmIDotKQ0KIA0KSnVlcmdlbg0KIA0KIA0KDQoJLS0tLS1VcnNwcsO8bmds aWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IEFsZWYgQXJlbmRzZW4gW21haWx0bzphbGVmQGp0 ZWFtLm5sXSANCglHZXNlbmRldDogRGkgMDguMDcuMjAwMyAxOTo0MyANCglBbjogasO8cmdlbiBo w7ZsbGVyIFt3ZXJrM0FUXTsgc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vm b3JnZS5uZXQgDQoJQ2M6IA0KCUJldHJlZmY6IFJFOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Bl cl0gVGFncyB1c2luZyBleHByZXNzaW9uIGxhbmd1YWdlPz8NCgkNCgkNCg0KCU9rLCBoZXJlIHdl IGdvLi4uDQoJDQoJTGlrZSB5b3Ugc2FpZCwgYXQgZmlyc3QgZ2xhbmNlLCBpdCBkb2VzIG5vdCBs b29rIGxpa2UgdGhlIGkyMTpiaW5kIHRhZw0KCW5lZWRzIGV4cHJlc3Npb25hbGl6YXRpb24gKGht bW0sIG5pY2UgaHVoIDstKS4gSG93ZXZlciwgaW4gdGhlIHBldGNsaW5pYw0KCWRlbW8gYXBwIEkn bSBzZWVpbmcgYSBsb3Qgb2YgaW5wdXQuanNwcyBpbiB0aGUganNwL2ZpZWxkcyBkaXJlY3Rvcnku DQoJVGhlc2UgYXJlIHRoaW5ncyBJJ20gaG9waW5nIHRvIHNvbHZlIHVzaW5nIGZvciBpbnN0YW5j ZSBFTC1iYXNlZCB0YWdzLi4uDQoJQXR0YWNoZWQgeW91J2xsIGZpbmQgYSByZXdvcmtlZCB2ZXJz aW9uIG9mIHRoZSBvd25lckZvcm0uIEl0IGRvZXMgbm90DQoJdXNlIHRoZSBKU1BzIGZyb20gdGhl IGZpZWxkcyBkaXJlY3RvcnkgYW55bW9yZSwgYnV0IHVzZXMgb25seSBvbmUNCglpbnB1dC5qc3Ag dGhhdCB1c2VzIHRoZSBiaW5kc3RhdHVzIG9iamVjdCB0byBjcmVhdGUgdGhlIGlucHV0IGZpZWxk Lg0KCQ0KCU9rLCBpdCdzIHN0aWxsIGFsbCByb3VnaCBhbmQgcmV3b3JraW5nIHRoZSB0YWdzIGlz IGEgbGl0dGxlIGJpdCBtb3JlDQoJd29yayB0aGFuIHRoZSAxNSBtaW51dGVzIEkgc3BlbnQgb24g aXQgbm93LCBidXQgbWF5YmUgeW91J3JlIGdldHRpbmcgdGhlDQoJaWRlYS4NCgkNCglDb25zZXF1 ZW5jZXMgZm9yIGFkZGluZyAvIHJld29ya2luZyB0aGUgdGFnczoNCgkNCgkxLiBkZXBlbmRlbmN5 IG9uIGpha2FydGEtanN0bC0xLjAuMyAoamFrYXJ0YS5hcGFjaGUub3JnL3RhZ2xpYiAtLT4NCglz dGFuZGFyZCkuDQoJMi4gZGVwZW5kZW5jeSBvbiBqc3RsLTEuMC4zIChqYXZhLnN1bi5jb20pDQoJ My4gSW4gY2FzZSB5b3Ugd2FudCB0byBoYXZlIGJvdGggdmVyc2lvbiBpbiB0aGVyZSwgYW4gZXh0 ZW5kaW5nIGNsYXNzDQoJZm9yIGVhY2ggdGFnDQoJNC4gRm9yIGVhY2ggdGFnLCBhIEJlYW5JbmZv IGNsYXNzDQoJNS4gSSB3YXNuJ3QgYWJsZSB0byB1c2UgdGhlIEV2YWxIZWxwZXIgZnJvbSBqYWth cnRhLCBzbyBJIGNvcGllZCBpdA0KCShobW1tLi4uIG5vdCBzbyBuaWNlLCBpcyBpdCA7LSkNCgkN CglQcm9iYWJseSBJIGRvbid0IGhhdmUgdGltZSB0aGlzIHdlZWsgb3Igc29tZXRoaW5nIHRvIHJl ZmFjdG9yIHRoZW0gdG8gYmUNCglhbGwgRUwtYmFzZWQuLi4gSnVzdCBsZXQgbWUga25vdyBpZiB5 b3UnZCBsaWtlIGl0Lg0KCQ0KCVdlbGwsIHRoYXQncyBpdCBmb3Igbm93LCBzdGlsbCBkaXNjb3Zl cmluZyByZWFsbHkgY29vbCBmZWF0dXJlcyBhbmQNCglhbHJlYWR5IHJ1bm5pbmcgb3V0IChicmFp biltZW1vcnkgdG8gdGhpbmsgdXAgZXZlcnl0aGluZyBJIGNvdWxkIGRvIHdpdGgNCglTcHJpbmcg Oy0pDQoJDQoJQ2hlZXJzLA0KCQ0KCUFsZWYNCgkNCg0K |
|
From: <jue...@we...> - 2003-07-12 14:38:19
|
SSd2ZSBpbnRyb2R1Y2VkIHN1cHBvcnQgZm9yIEVMIG9uIHRhZyBhdHRyaWJ1dGVzIHllc3RlcmRh eSwgYWxyZWFkeSBjb21taXR0ZWQuIFRoYW5rcyBmb3IgdGhlIGlkZWEgYW5kIHRoZSBwcm90b3R5 cGUsIEFsZWYhIEkgaG9wZSB5b3UgYXJlIHNhdGlzZmllZCB3aXRoIHRoZSBpbnRlZ3JhdGlvbi4g WW91J3JlIHZlcnkgd2VsY29tZSB0byB0cnkgaXQgb3V0IDotKQ0KIA0KVGhlcmUncyBhIG5ldyBF eHByZXNzaW9uRXZhbHVhdGlvbnNVdGlscyBjbGFzcyBub3cgaW4gY29tLmludGVyZmFjZTIxLndl Yi51dGlsLCB0YWtpbmcgYSBTdHJpbmcgYXJndW1lbnQgdmFsdWUgYW5kIHBhcnNpbmcgaXQgdG8g T2JqZWN0LCBTdHJpbmcsIGludCwgb3IgYm9vbGVhbi4gSXQgd2lsbCBqdXN0IGF0dGVtcHQgRUwg ZXZhbHVhdGlvbiBpZiB0aGUgdmFsdWUgc3RhcnRzIHdpdGggIiR7IiwgZWxzZSBpdCB3aWxsIHNp bXBseSBwYXJzZSB0aGUgdmFsdWUgd2l0aCBzdGFuZGFyZCBtZWFucy4NCiANCkFsbCBvZiBTcHJp bmcncyB0YWdzIHVzZSB0aGlzIGNsYXNzIG5vdyBmb3IgYWxsIGF0dHJpYnV0ZXMsIHNpbXBseSBk ZWxlZ2F0aW5nIHRvIHRoZSByZXNwZWN0aXZlIEV4cHJlc3Npb25FdmFsdWF0aW9uc1V0aWxzIG1l dGhvZCBpbiBlYWNoIHNldHRlci4gVGhpcyBtZWFucyB0aGF0IGFsbCBhdHRyaWJ1dGVzIHN0aWxs IGFjY2VwdCBub3JtYWwgU3RyaW5nIHZhbHVlcyBhcyBiZWZvcmUgKGxpa2UgPGkyMTpiaW5kIHBh dGg9InBlcnNvbi5uYW1lIj4pLCBidXQgYWxzbyBFTCBleHByZXNzaW9ucyAobGlrZSA8aTIxOmJp bmQgcGF0aD0iJHtiaW5kUGF0aH0iPikuDQogDQpGb3IgRUwgZXZhbHVhdGlvbiwgRXhwcmVzc2lv bkV2YWx1YXRpb25zVXRpbHMgZGVwZW5kcyBvbiBKYWthcnRhJ3MgSlNUTCBpbXBsZW1lbnRhdGlv biAoc3RhbmRhcmQuamFyKS4gSXQgZG9lc24ndCBoYXZlIGEgcnVudGltZSBkZXBlbmRlbmN5IGlm IGp1c3QgcGFyc2luZyBub3JtYWwgU3RyaW5nIHZhbHVlcyB0aG91Z2gsIGFzIGl0IGRlbGVnYXRl cyBFTCBldmFsdWF0aW9uIHRvIGFuIGlubmVyIGNsYXNzIHRoYXQgd2lsbCBqdXN0IGdldCBsb2Fk ZWQgaW4gY2FzZSBvZiBhY3R1YWwgRUwgZXhwcmVzc2lvbnMuIFNvIHlvdSdsbCBqdXN0IG5lZWQg dGhlIEpha2FydGEgSlNUTCBpbXBsZW1lbnRhdGlvbiBpbiB5b3VyIGNsYXNzcGF0aCBpZiB5b3Ug YWN0dWFsbHkgdXNlIEVMIGF0dHJpYnV0ZSB2YWx1ZXMgb24gdGFncy4NCiANCkJUVywgb3VyIEFv cFByb3h5IHVzZXMgYSBzaW1pbGFyIG1lY2hhbmlzbSB0byBhdm9pZCBhIHJ1bnRpbWUgZGVwZW5k ZW5jeSBvbiBDR0xJQi4gSWYganVzdCBwcm94eWluZyBpbnRlcmZhY2VzLCBpdCB3aWxsIHVzZSBz dGFuZGFyZCBKMlNFIHByb3hpZXMuIE9ubHkgaWYgeW91IHRyeSB0byBwcm94eSBhIGNsYXNzIGl0 c2VsZiwgaXQgd2lsbCBpbnZva2UgQ0dMSUIgYnkgZGVsZWdhdGluZyB0byBhIHJlc3BlY3RpdmUg aW5uZXIgY2xhc3MuDQogDQpGaW5hbGx5LCB3ZSBzaG91bGQgYWRhcHQgUGV0Q2xpbmljIHRvIHVz ZSBFTCBleHByZXNzaW9ucyBvbiBpdHMgYmluZCB0YWdzLiBBbGVmIGhhcyBhbHJlYWR5IHNob3du IHRoZSB3YXkgaW4gdGhlIHByb3RvdHlwZSB0aGF0IGhlIHNlbnQuIEtlbiwgd2hhdCBkbyB5b3Ug dGhpbms/IFdvdWxkIHlvdSBsaWtlIEFsZWYgdG8gZG8gdGhpcz8NCiANCkp1ZXJnZW4NCiANCiAN Cg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBqw7xyZ2VuIGjD tmxsZXIgW3dlcmszQVRdIA0KCUdlc2VuZGV0OiBGciAxMS4wNy4yMDAzIDA4OjEzIA0KCUFuOiBh bGVmQGp0ZWFtLm5sOyBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdl Lm5ldCANCglDYzogDQoJQmV0cmVmZjogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBU YWdzIHVzaW5nIGV4cHJlc3Npb24gbGFuZ3VhZ2U/Pw0KCQ0KCQ0KDQoJQWxlZiwNCgkNCglJJ3Zl IGp1c3QgYnJvd3NlZCB5b3VyIGNvZGUgLSB0aGlzIGxvb2tzIHZlcnkgaW50ZXJlc3RpbmchIEl0 IG1ha2VzIGl0ZXJhdGluZyBzdWNoIHJlcGV0aXRpdmUgZm9ybSBmaWVsZHMgbGlrZSBpbiB0aGUg cGV0Y2xpbmljIG11Y2ggZWFzaWVyLiBJJ2xsIGhhdmUgYSBsb29rIGF0IHRoZSBpbXBsZW1lbnRh dGlvbiBkZXRhaWxzLCBhbmQgaWYgZXZlcnl0aGluZyB3b3JrcyBvdXQgSSdsbCBhZGQgYSBjbGVh biByb29tIHZlcnNpb24gdG8gdGhlIG1haW4gc291cmNlIHRyZWUgcHJvbXB0bHkuDQoJDQoJSSB3 b25kZXIgaWYgd2UgY291bGQgbWFrZSB0aGF0IHdvcmsgd2l0aCBhbnkgSlNUTCBpbXBsZW1lbnRh dGlvbiwgbm90IGp1c3QgdGhlIEpha2FydGEgb25lLCBhbHRob3VnaCBJIHdvdWxkbid0IG1pbmQg YSBkZXBlbmRlbmN5IG9uIHRoZSBsYXR0ZXIgZm9yIHRoaXMgZmVhdHVyZS4NCgkNCglDb29sIHN0 dWZmIDotKQ0KCQ0KCUp1ZXJnZW4NCgkNCgkNCgkNCgkgICAgICAgIC0tLS0tVXJzcHLDvG5nbGlj aGUgTmFjaHJpY2h0LS0tLS0NCgkgICAgICAgIFZvbjogQWxlZiBBcmVuZHNlbiBbbWFpbHRvOmFs ZWZAanRlYW0ubmxdDQoJICAgICAgICBHZXNlbmRldDogRGkgMDguMDcuMjAwMyAxOTo0Mw0KCSAg ICAgICAgQW46IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF07IHNwcmluZ2ZyYW1ld29yay1kZXZl bG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJICAgICAgICBDYzoNCgkgICAgICAgIEJldHJl ZmY6IFJFOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gVGFncyB1c2luZyBleHByZXNzaW9u IGxhbmd1YWdlPz8NCgkgICAgICAgDQoJICAgICAgIA0KCQ0KCSAgICAgICAgT2ssIGhlcmUgd2Ug Z28uLi4NCgkgICAgICAgDQoJICAgICAgICBMaWtlIHlvdSBzYWlkLCBhdCBmaXJzdCBnbGFuY2Us IGl0IGRvZXMgbm90IGxvb2sgbGlrZSB0aGUgaTIxOmJpbmQgdGFnDQoJICAgICAgICBuZWVkcyBl eHByZXNzaW9uYWxpemF0aW9uIChobW1tLCBuaWNlIGh1aCA7LSkuIEhvd2V2ZXIsIGluIHRoZSBw ZXRjbGluaWMNCgkgICAgICAgIGRlbW8gYXBwIEknbSBzZWVpbmcgYSBsb3Qgb2YgaW5wdXQuanNw cyBpbiB0aGUganNwL2ZpZWxkcyBkaXJlY3RvcnkuDQoJICAgICAgICBUaGVzZSBhcmUgdGhpbmdz IEknbSBob3BpbmcgdG8gc29sdmUgdXNpbmcgZm9yIGluc3RhbmNlIEVMLWJhc2VkIHRhZ3MuLi4N CgkgICAgICAgIEF0dGFjaGVkIHlvdSdsbCBmaW5kIGEgcmV3b3JrZWQgdmVyc2lvbiBvZiB0aGUg b3duZXJGb3JtLiBJdCBkb2VzIG5vdA0KCSAgICAgICAgdXNlIHRoZSBKU1BzIGZyb20gdGhlIGZp ZWxkcyBkaXJlY3RvcnkgYW55bW9yZSwgYnV0IHVzZXMgb25seSBvbmUNCgkgICAgICAgIGlucHV0 LmpzcCB0aGF0IHVzZXMgdGhlIGJpbmRzdGF0dXMgb2JqZWN0IHRvIGNyZWF0ZSB0aGUgaW5wdXQg ZmllbGQuDQoJICAgICAgIA0KCSAgICAgICAgT2ssIGl0J3Mgc3RpbGwgYWxsIHJvdWdoIGFuZCBy ZXdvcmtpbmcgdGhlIHRhZ3MgaXMgYSBsaXR0bGUgYml0IG1vcmUNCgkgICAgICAgIHdvcmsgdGhh biB0aGUgMTUgbWludXRlcyBJIHNwZW50IG9uIGl0IG5vdywgYnV0IG1heWJlIHlvdSdyZSBnZXR0 aW5nIHRoZQ0KCSAgICAgICAgaWRlYS4NCgkgICAgICAgDQoJICAgICAgICBDb25zZXF1ZW5jZXMg Zm9yIGFkZGluZyAvIHJld29ya2luZyB0aGUgdGFnczoNCgkgICAgICAgDQoJICAgICAgICAxLiBk ZXBlbmRlbmN5IG9uIGpha2FydGEtanN0bC0xLjAuMyAoamFrYXJ0YS5hcGFjaGUub3JnL3RhZ2xp YiAtLT4NCgkgICAgICAgIHN0YW5kYXJkKS4NCgkgICAgICAgIDIuIGRlcGVuZGVuY3kgb24ganN0 bC0xLjAuMyAoamF2YS5zdW4uY29tKQ0KCSAgICAgICAgMy4gSW4gY2FzZSB5b3Ugd2FudCB0byBo YXZlIGJvdGggdmVyc2lvbiBpbiB0aGVyZSwgYW4gZXh0ZW5kaW5nIGNsYXNzDQoJICAgICAgICBm b3IgZWFjaCB0YWcNCgkgICAgICAgIDQuIEZvciBlYWNoIHRhZywgYSBCZWFuSW5mbyBjbGFzcw0K CSAgICAgICAgNS4gSSB3YXNuJ3QgYWJsZSB0byB1c2UgdGhlIEV2YWxIZWxwZXIgZnJvbSBqYWth cnRhLCBzbyBJIGNvcGllZCBpdA0KCSAgICAgICAgKGhtbW0uLi4gbm90IHNvIG5pY2UsIGlzIGl0 IDstKQ0KCSAgICAgICANCgkgICAgICAgIFByb2JhYmx5IEkgZG9uJ3QgaGF2ZSB0aW1lIHRoaXMg d2VlayBvciBzb21ldGhpbmcgdG8gcmVmYWN0b3IgdGhlbSB0byBiZQ0KCSAgICAgICAgYWxsIEVM LWJhc2VkLi4uIEp1c3QgbGV0IG1lIGtub3cgaWYgeW91J2QgbGlrZSBpdC4NCgkgICAgICAgDQoJ ICAgICAgICBXZWxsLCB0aGF0J3MgaXQgZm9yIG5vdywgc3RpbGwgZGlzY292ZXJpbmcgcmVhbGx5 IGNvb2wgZmVhdHVyZXMgYW5kDQoJICAgICAgICBhbHJlYWR5IHJ1bm5pbmcgb3V0IChicmFpbilt ZW1vcnkgdG8gdGhpbmsgdXAgZXZlcnl0aGluZyBJIGNvdWxkIGRvIHdpdGgNCgkgICAgICAgIFNw cmluZyA7LSkNCgkgICAgICAgDQoJICAgICAgICBDaGVlcnMsDQoJICAgICAgIA0KCSAgICAgICAg QWxlZg0KCSAgICAgICANCgkNCglOGEhTXumailspeyhbah9K66K6a3nGrl7Yp2oreDowWhp12pVn Kilqd2B61p/nm6IwDQoJWih+KFcofWlUKX57DQoJK9evelopelhYKmt4H8KKdd6WXlgoHn56d2ls cQd6bFgp36MpKX57DQoJK9evelopIA0KDQo= |
|
From: Ken K. <kk...@kk...> - 2003-07-12 16:28:19
|
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( ~zwilqzlX)ߣ))~{
> +ׯ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)
>
>
>
>
|
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-07-13 17:25:13
|
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=C3=BCrgen h=C3=B6ller [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=20
implementation along with code tightening and documentation improvements =
and am just about ready to commit the changes. I WILL commit these=20
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=20
ahead. If not, I'll do it. Please let me know if you will be doing it.
Regards,
Ken
=20
j=C3=BCrgen h=C3=B6ller [werk3AT] wrote:
>I've introduced support for EL on tag attributes yesterday, already=20
>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 :-)
>=20
>There's a new ExpressionEvaluationsUtils class now in=20
>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.
>=20
>All of Spring's tags use this class now for all attributes, simply=20
>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=3D"person.name">), but also EL =
expressions (like <i21:bind path=3D"${bindPath}">).
>=20
>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.
>=20
>BTW, our AopProxy uses a similar mechanism to avoid a runtime=20
>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.
>=20
>Finally, we should adapt PetClinic to use EL expressions on its bind=20
>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?
>=20
>Juergen
>=20
>=20
>
> -----Urspr=C3=BCngliche Nachricht-----=20
> Von: j=C3=BCrgen h=C3=B6ller [werk3AT]=20
> Gesendet: Fr 11.07.2003 08:13=20
> An: al...@jt...; spr...@li...=20
> Cc:=20
> Betreff: Re: [Springframework-developer] Tags using expression=20
>language??
>=09
>=09
>
> Alef,
>=09
> I've just browsed your code - this looks very interesting! It makes=20
>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.
>=09
> I wonder if we could make that work with any JSTL implementation, not=20
>just the Jakarta one, although I wouldn't mind a dependency on the =
latter for this feature.
>=09
> Cool stuff :-)
>=09
> Juergen
>=09
>=09
>=09
> -----Urspr=C3=BCngliche Nachricht-----
> Von: Alef Arendsen [mailto:al...@jt...]
> Gesendet: Di 08.07.2003 19:43
> An: j=C3=BCrgen h=C3=B6ller [werk3AT]; =
spr...@li...
> Cc:
> Betreff: RE: [Springframework-developer] Tags using expression =
>language??
> =20
> =20
>=09
> Ok, here we go...
> =20
> 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=20
>field.
> =20
> 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.
> =20
> Consequences for adding / reworking the tags:
> =20
> 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 ;-)
> =20
> 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.
> =20
> 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 ;-)
> =20
> Cheers,
> =20
> Alef
> =20
>=09
> =
N=18HS^=E9=9A=8A[){([j=1FJ=EB=A2=BAky=C6=AE^=D8=A7j+x:0Z=1Au=DA=95g*)jw`z=
=D6=9F=E7=9B=A20
> Z(~(W(}iT)~{
> +=D7=AFzZ)zXX*kx=1F=C5=A0u=DE=96^X(=1E~zwilq zlX)=DF=A3))~{
> +=D7=AFzZ)
>
>?????????????????????????????????????????=D3=86+=12=17?^?=E9=9A=8A[)?{(?=
?[??=DA=AD?(~?+??=E9=AE=8A=1FY?
>=DA=A6??j?h??^??-?x?????:0?Z=1Aw?jU?l????=DD=81?Z~??n?$?=0C0???j?=1F??(?=
??W???(}?i?_???????????????????????????????????*k?x=1F???=C5=A0??=D7=AFzZ=
)z???X??X??*k?x=1F???=C5=A0??=D7=AFzZ)z???l??.?=C7=9F??=1E?w???i????+-??(=
??=1E~??{?=DE=B7?b????+-?w???k?x=1F???=C5=A0??=D7=AFzZ)
>
>
> =20
>
|
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-07-14 09:33:35
|
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=C3=BCrgen h=C3=B6ller [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=C3=BCrgen h=C3=B6ller [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=20
implementation along with code tightening and documentation improvements =
and am just about ready to commit the changes. I WILL commit these=20
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=20
ahead. If not, I'll do it. Please let me know if you will be doing it.
Regards,
Ken
=20
j=C3=BCrgen h=C3=B6ller [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 :-)
>=20
>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.
>=20
>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=3D"person.name">), but also EL =
expressions (like <i21:bind path=3D"${bindPath}">).
>=20
>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.
>=20
>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.
>=20
>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?
>=20
>Juergen
>=20
>=20
>
> -----Urspr=C3=BCngliche Nachricht-----=20
> Von: j=C3=BCrgen h=C3=B6ller [werk3AT]=20
> Gesendet: Fr 11.07.2003 08:13=20
> An: al...@jt...; spr...@li...=20
> Cc:=20
> Betreff: Re: [Springframework-developer] Tags using expression
>language??
>=09
>=09
>
> Alef,
>=09
> 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.
>=09
> 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.
>=09
> Cool stuff :-)
>=09
> Juergen
>=09
>=09
>=09
> -----Urspr=C3=BCngliche Nachricht-----
> Von: Alef Arendsen [mailto:al...@jt...]
> Gesendet: Di 08.07.2003 19:43
> An: j=C3=BCrgen h=C3=B6ller [werk3AT]; =
spr...@li...
> Cc:
> Betreff: RE: [Springframework-developer] Tags using expression
>language??
> =20
> =20
>=09
> Ok, here we go...
> =20
> 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.
> =20
> 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.
> =20
> Consequences for adding / reworking the tags:
> =20
> 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 ;-)
> =20
> 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.
> =20
> 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 ;-)
> =20
> Cheers,
> =20
> Alef
> =20
>=09
> =
N=18HS^=E9=9A=8A[){([j=1FJ=EB=A2=BAky=C6=AE^=D8=A7j+x:0Z=1Au=DA=95g*)jw`z=
=D6=9F=E7=9B=A20
> Z(~(W(}iT)~{
> +=D7=AFzZ)zXX*kx=1F=C5=A0u=DE=96^X(=1E~zwilq zlX)=DF=A3))~{
> +=D7=AFzZ)
>
>?????????????????????????????????????????=D3=86+=12=17?^?=E9=9A=8A[)?{(?=
?[??=DA=AD?(~?+??=E9=AE=8A=1FY?
>=DA=A6??j?h??^??-?x?????:0?Z=1Aw?jU?l????=DD=81?Z~??n?$?=0C0???j?=1F??(?=
??W???(}?i?_???????????????????????????????????*k?x=1F???=C5=A0??=D7=AFzZ=
)z???X??X??*k?x=1F???=C5=A0??=D7=AFzZ)z???l??.?=C7=9F??=1E?w???i????+-??(=
??=1E~??{?=DE=B7?b????+-?w???k?x=1F???=C5=A0??=D7=AFzZ)
>
>
> =20
>
-------------------------------------------------------
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: 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: <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: 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: <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 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: Alef A. \(JTeam\) <al...@jt...> - 2003-07-23 16:53:17
|
Hi Juergen (I still can't find the ALT-code for u-umlaut),
There's a slight bug in the ExpressionEvaluationUtils.
Expressionlanguage supports partial expressions combined with strings.
Something like this: <i21:bind path="Account.${item}"/>...
The isExpressionLanguage()-method says: 'value.startsWith("${")' while
it should read 'value.indexOf("${") != -1'. This will fix the tag in
order to make the example above work...
Cheers,
Alef
P.s. In one of your replies, you stated that it might be handier for me
(and some other people I'm constantly bothering ;-) to become a
developer. I kind of agree with and since I'm currently developing kind
of a large application using Spring, I'll probably run into some more
minor things I would be able to commit myself directly... So if nobody
objects...
|
|
From: <jue...@we...> - 2003-07-23 18:08:32
|
SnVzdCBmaXhlZCAtIEV4cHJlc3Npb25FdmFsdWF0aW9uVXRpbHMgc3VwcG9ydHMgcGFydGlhbCBl eHByZXNzaW9ucyBub3chIEFuZCBhcyBJJ3ZlIGFscmVhZHkgaGludGVkIGF0LCB5b3UncmUgd2Vs Y29tZSB0byBiZWNvbWUgYSBkZXZlbG9wZXIgLSBqdXN0IHRlbGwgbWUgeW91ciBTb3VyY2VGb3Jn ZSBVbml4IHVzZXJuYW1lLi4uIDotKQ0KIA0KQlRXLCBmZWVsIGZyZWUgdG8gbWFrZSBCaW5kVGFn IHN1cHBvcnQgbmVzdGVkIHRhZ3MuIFlvdSdyZSBnZW5lcmFsbHkgaW52aXRlZCB0byBleHRlbmQg dGhlIHRhZyBzdWl0ZSBpZiB5b3UgbGlrZSB0bywgYXMgdGhhdCBpcyBsb3cgb24gbXkgcGVyc29u YWwgcHJpb3JpdHkgbGlzdC4gUmVnYXJkaW5nIGEgTGlzdENvbnRyb2xsZXI6IFNvdW5kcyBpbnRl cmVzdGluZywgYnV0IEknZCBzdWdnZXN0IHRvIGRpc2N1c3MgcHJvdG90eXBpY2FsIGNvZGUgYmVm b3JlIGNvbW1pdHRpbmcgYW55dGhpbmcgdG8gdGhlIG1haW4gc291cmNlIHRyZWUuDQogDQpKdWVy Z2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjog QWxlZiBBcmVuZHNlbiAoSlRlYW0pIFttYWlsdG86YWxlZkBqdGVhbS5ubF0gDQoJR2VzZW5kZXQ6 IE1pIDIzLjA3LjIwMDMgMTg6NTQgDQoJQW46IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF07IHNw cmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglC ZXRyZWZmOiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFRhZ3MgdXNpbmcgZXhwcmVz c2lvbiBsYW5ndWFnZT8/DQoJDQoJDQoNCglIaSBKdWVyZ2VuIChJIHN0aWxsIGNhbid0IGZpbmQg dGhlIEFMVC1jb2RlIGZvciB1LXVtbGF1dCksDQoJDQoJVGhlcmUncyBhIHNsaWdodCBidWcgaW4g dGhlIEV4cHJlc3Npb25FdmFsdWF0aW9uVXRpbHMuDQoJRXhwcmVzc2lvbmxhbmd1YWdlIHN1cHBv cnRzIHBhcnRpYWwgZXhwcmVzc2lvbnMgY29tYmluZWQgd2l0aCBzdHJpbmdzLg0KCVNvbWV0aGlu ZyBsaWtlIHRoaXM6IDxpMjE6YmluZCBwYXRoPSJBY2NvdW50LiR7aXRlbX0iLz4uLi4NCgkNCglU aGUgaXNFeHByZXNzaW9uTGFuZ3VhZ2UoKS1tZXRob2Qgc2F5czogJ3ZhbHVlLnN0YXJ0c1dpdGgo IiR7IiknIHdoaWxlDQoJaXQgc2hvdWxkIHJlYWQgJ3ZhbHVlLmluZGV4T2YoIiR7IikgIT0gLTEn LiBUaGlzIHdpbGwgZml4IHRoZSB0YWcgaW4NCglvcmRlciB0byBtYWtlIHRoZSBleGFtcGxlIGFi b3ZlIHdvcmsuLi4NCgkNCglDaGVlcnMsDQoJDQoJQWxlZg0KCQ0KCVAucy4gSW4gb25lIG9mIHlv dXIgcmVwbGllcywgeW91IHN0YXRlZCB0aGF0IGl0IG1pZ2h0IGJlIGhhbmRpZXIgZm9yIG1lDQoJ KGFuZCBzb21lIG90aGVyIHBlb3BsZSBJJ20gY29uc3RhbnRseSBib3RoZXJpbmcgOy0pIHRvIGJl Y29tZSBhDQoJZGV2ZWxvcGVyLiBJIGtpbmQgb2YgYWdyZWUgd2l0aCBhbmQgc2luY2UgSSdtIGN1 cnJlbnRseSBkZXZlbG9waW5nIGtpbmQNCglvZiBhIGxhcmdlIGFwcGxpY2F0aW9uIHVzaW5nIFNw cmluZywgSSdsbCBwcm9iYWJseSBydW4gaW50byBzb21lIG1vcmUNCgltaW5vciB0aGluZ3MgSSB3 b3VsZCBiZSBhYmxlIHRvIGNvbW1pdCBteXNlbGYgZGlyZWN0bHkuLi4gU28gaWYgbm9ib2R5DQoJ b2JqZWN0cy4uLg0KCQ0KCQ0KCQ0KDQo= |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-07-24 07:36:49
|
Yeah, of course prototypes will be discussed, I'm not even into the
framework enough to see the best possible option for some things I have
to do... I'm working on a partially publicly available version of the
site we're building that'll show the listcontroller... But I'll mention
that when it's done.
Thanx for the fix in EL-stuff...
Alef
Ah, before I forget, The unixname: 'aarendsen'
Just fixed - ExpressionEvaluationUtils supports partial expressions now!
And as I've already hinted at, you're welcome to become a developer -
just tell me your SourceForge Unix username... :-)
=20
BTW, feel free to make BindTag support nested tags. You're generally
invited to extend the tag suite if you like to, as that is low on my
personal priority list. Regarding a ListController: Sounds interesting,
but I'd suggest to discuss prototypical code before committing anything
to the main source tree.
=20
Juergen
=20
=20
-----Urspr=FCngliche Nachricht-----=20
Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
Gesendet: Mi 23.07.2003 18:54=20
An: j=FCrgen h=F6ller [werk3AT];
spr...@li...=20
Cc:=20
Betreff: RE: [Springframework-developer] Tags using expression
language??
=09
=09
Hi Juergen (I still can't find the ALT-code for u-umlaut),
=09
There's a slight bug in the ExpressionEvaluationUtils.
Expressionlanguage supports partial expressions combined with
strings.
Something like this: <i21:bind path=3D"Account.${item}"/>...
=09
The isExpressionLanguage()-method says: 'value.startsWith("${")'
while
it should read 'value.indexOf("${") !=3D -1'. This will fix the
tag in
order to make the example above work...
=09
Cheers,
=09
Alef
=09
P.s. In one of your replies, you stated that it might be handier
for me
(and some other people I'm constantly bothering ;-) to become a
developer. I kind of agree with and since I'm currently
developing kind
of a large application using Spring, I'll probably run into some
more
minor things I would be able to commit myself directly... So if
nobody
objects...
=09
=09
=09
|
|
From: <jue...@we...> - 2003-07-24 07:56:47
|
You've just been promoted to a Spring Framework developer :-)
As long as its about added getters or convenience methods or the like, =
you can simply go ahead as far as I'm concerned. I see a need for =
discussion mainly when you intend to introduce completely new classes.
Juergen
-----Original Message-----
From: Alef Arendsen (JTeam) [mailto:al...@jt...]
Sent: Thursday, July 24, 2003 9:38 AM
To: j=FCrgen h=F6ller [werk3AT];
spr...@li...
Subject: RE: [Springframework-developer] Tags using expression
language??
Yeah, of course prototypes will be discussed, I'm not even into the
framework enough to see the best possible option for some things I have
to do... I'm working on a partially publicly available version of the
site we're building that'll show the listcontroller... But I'll mention
that when it's done.
Thanx for the fix in EL-stuff...
Alef
Ah, before I forget, The unixname: 'aarendsen'
Just fixed - ExpressionEvaluationUtils supports partial expressions now!
And as I've already hinted at, you're welcome to become a developer -
just tell me your SourceForge Unix username... :-)
=20
BTW, feel free to make BindTag support nested tags. You're generally
invited to extend the tag suite if you like to, as that is low on my
personal priority list. Regarding a ListController: Sounds interesting,
but I'd suggest to discuss prototypical code before committing anything
to the main source tree.
=20
Juergen
=20
=20
-----Urspr=FCngliche Nachricht-----=20
Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
Gesendet: Mi 23.07.2003 18:54=20
An: j=FCrgen h=F6ller [werk3AT];
spr...@li...=20
Cc:=20
Betreff: RE: [Springframework-developer] Tags using expression
language??
=09
=09
Hi Juergen (I still can't find the ALT-code for u-umlaut),
=09
There's a slight bug in the ExpressionEvaluationUtils.
Expressionlanguage supports partial expressions combined with
strings.
Something like this: <i21:bind path=3D"Account.${item}"/>...
=09
The isExpressionLanguage()-method says: 'value.startsWith("${")'
while
it should read 'value.indexOf("${") !=3D -1'. This will fix the
tag in
order to make the example above work...
=09
Cheers,
=09
Alef
=09
P.s. In one of your replies, you stated that it might be handier
for me
(and some other people I'm constantly bothering ;-) to become a
developer. I kind of agree with and since I'm currently
developing kind
of a large application using Spring, I'll probably run into some
more
minor things I would be able to commit myself directly... So if
nobody
objects...
=09
=09
=09
|
|
From: Alef A. <al...@jt...> - 2003-07-08 17:41:53
|
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 |
