Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-10-29 22:27:59
|
RllJLCB3ZSd2ZSBub3cgZ290IGFjdHVhbCByZXF1aXJlbWVudHMgZm9yIGluZGV4ZWQgcHJvcGVy dGllcyBpbiBhIHdlcmszQVQgcHJvZHVjdCAtLSB0byBiZSBpbXBsZW1lbnRlZCBieSB0aGUgZW5k IG9mIG5leHQgd2Vlay4gU28gSSdtIGdvbm5hIHdvcmsgb24gaXQgZWFybHkgbmV4dCB3ZWVrLCBz dWdnZXN0aW9ucyBhbmQgaGVscCBhcmUgd2VsY29tZSBvZiBjb3Vyc2UuIEl0IHNob3VsZG4ndCBi ZSB0b28gaGFyZCB0byBkbyBldmVuIGlmIGZ1bGx5IGltcGxlbWVudGVkIG9uIG91ciBvd247IHRo ZSBoYXJkZXIgcGFydCBpcyB0byBzZXR0bGUgb24gYSBjZXJ0YWluIHN5bnRheC4NCiANCkp1ZXJn ZW4NCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBSb2Qg Sm9obnNvbiBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0gDQoJR2VzZW5kZXQ6 IERvIDIzLjEwLjIwMDMgMTc6MzIgDQoJQW46IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0gDQoJ Q2M6IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUJl dHJlZmY6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBSZTogW3NwcmluZ2ZyYW1ld29yayAt IEhlbHBdIEluZGV4IHByb3BlcnRpZXMgaW4gZm9ybXMNCgkNCgkNCg0KCUp1ZXJnZW4sDQoJDQoJ SSB0aGluayB3ZSBzaG91bGQgcHJvdmlkZSBpbmRleGVkIHByb3BlcnR5IHN1cHBvcnQgZm9yIE0z LiAgSSB0aGluayB5b3Ugd2VyZQ0KCXJpZ2h0IHRvIHJlbW92ZSB0aGUgaW5hZGVxdWF0ZSBzdXBw b3J0IGZvciBub3cuDQoJDQoJSSB0aGluayBzdXBwb3J0aW5nIHRoZSBDb21tb25zIHN5bnRheCBt YWtlcyBzZW5zZS4gSSB0aGluayBhdCBvbmUgcG9pbnQgSQ0KCWVudmlzYWdlZCBoYXZpbmcgYW4g SW5kZXhlZFByb3BlcnR5VmFsdWUgY2xhc3MsIGJ1dCB0aGF0J3MgcHJvYmFibHkNCgl1bm5lY2Vz c2FyeS4NCgkNCglSZWdhcmRzLA0KCVJvZA0KCQ0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQoJRnJvbTogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXQ0KCVNlbnQ6IFRodXJzZGF5LCBPY3Rv YmVyIDIzLCAyMDAzIDQ6NTAgUE0NCglUbzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0 cy5zb3VyY2Vmb3JnZS5uZXQNCglTdWJqZWN0OiBGVzogW3NwcmluZ2ZyYW1ld29yayAtIEhlbHBd IEluZGV4IHByb3BlcnRpZXMgaW4gZm9ybXMNCgkNCgkNCglFdmVyeWJvZHksDQoJDQoJU2VlbXMg bGlrZSB3ZSd2ZSBnb3QgdHdvIHBlb3BsZSBpbnF1aXJpbmcgZm9yIGluZGV4ZWQgcHJvcGVydHkg c3VwcG9ydC4gVGhlDQoJc2Vjb25kIGFscmVhZHkgZGF0ZXMgYmFjayB0byBtaWQtU2VwdGVtYmVy IDotKA0KCQ0KCUkndmUganVzdCByZWNoZWNrZWQgdGhlIEJlYW5XcmFwcGVyIGltcGxlbWVudGF0 aW9uIGFuZCBkaXNjb3ZlcmVkIHRoYXQgdGhlcmUNCglpcyBubyBwcm9wZXIgc3VwcG9ydCBmb3Ig aW5kZXhlZCBwcm9wZXJ0aWVzIHlldC4gVGhlIGV4aXN0aW5nDQoJZ2V0SW5kZXhlZFByb3BlcnR5 IG1ldGhvZCB3YXMgbm90IGNvbXBsZXRlIChlLmcuIG5vIHN1cHBvcnQgZm9yIG5lc3RpbmcpIGFu ZA0KCXVudGVzdGVkIChubyB1bml0IHRlc3QgY292ZXJlZCBpdCksIHNvIEkndmUgZGVjaWRlZCB0 byByZW1vdmUgaXQgZm9yIHRoZQ0KCXRpbWUgYmVpbmcgKGZvciAxLjAgTTIpLiBJdCBqdXN0IGNv bmZ1c2VkIGJvdGggb2YgdGhvc2UgZ3V5cyB0aGF0IHdlcmUNCglsb29raW5nIGZvciBpbmRleGVk IHByb3BlcnR5IHN1cHBvcnQuDQoJDQoJSmFrYXJ0YSBDb21tb25zIEJlYW5VdGlscyBkb2VzIHN1 cHBvcnQgbmVzdGVkIGFuZCBtYXBwZWQgcHJvcGVydGllcywgcXVvdGluZw0KCWZyb20gdGhlIGph dmFkb2NzIG9mIHRoZWlyIFByb3BlcnR5VXRpbHMgY2xhc3M6DQoJDQoJPHF1b3RlPg0KCUZvciB0 aGUgcHVycG9zZXMgb2YgdGhpcyBjbGFzcywgZml2ZSBmb3JtYXRzIGZvciByZWZlcmVuY2luZyBh IHBhcnRpY3VsYXINCglwcm9wZXJ0eSB2YWx1ZSBvZiBhIGJlYW4gYXJlIGRlZmluZWQsIHdpdGgg dGhlIGxheW91dCBvZiBhbiBpZGVudGlmeWluZw0KCVN0cmluZyBpbiBwYXJlbnRoZXNlczoNCgkN CgkqIFNpbXBsZSAobmFtZSkgLSBUaGUgc3BlY2lmaWVkIG5hbWUgaWRlbnRpZmllcyBhbiBpbmRp dmlkdWFsIHByb3BlcnR5IG9mIGENCglwYXJ0aWN1bGFyIEphdmFCZWFuLiBUaGUgbmFtZSBvZiB0 aGUgYWN0dWFsIGdldHRlciBvciBzZXR0ZXIgbWV0aG9kIHRvIGJlDQoJdXNlZCBpcyBkZXRlcm1p bmVkIHVzaW5nIHN0YW5kYXJkIEphdmFCZWFucyBpbnN0cm9zcGVjdGlvbiwgc28gdGhhdCAodW5s ZXNzDQoJb3ZlcnJpZGRlbiBieSBhIEJlYW5JbmZvIGNsYXNzLCBhIHByb3BlcnR5IG5hbWVkICJ4 eXoiIHdpbGwgaGF2ZSBhIGdldHRlcg0KCW1ldGhvZCBuYW1lZCBnZXRYeXooKSBvciAoZm9yIGJv b2xlYW4gcHJvcGVydGllcyBvbmx5KSBpc1h5eigpLCBhbmQgYSBzZXR0ZXINCgltZXRob2QgbmFt ZWQgc2V0WHl6KCkuDQoJDQoJKiBOZXN0ZWQgKG5hbWUxLm5hbWUyLm5hbWUzKSBUaGUgZmlyc3Qg bmFtZSBlbGVtZW50IGlzIHVzZWQgdG8gc2VsZWN0IGENCglwcm9wZXJ0eSBnZXR0ZXIsIGFzIGZv ciBzaW1wbGUgcmVmZXJlbmNlcyBhYm92ZS4gVGhlIG9iamVjdCByZXR1cm5lZCBmb3INCgl0aGlz IHByb3BlcnR5IGlzIHRoZW4gY29uc3VsdGVkLCB1c2luZyB0aGUgc2FtZSBhcHByb2FjaCwgZm9y IGEgcHJvcGVydHkNCglnZXR0ZXIgZm9yIGEgcHJvcGVydHkgbmFtZWQgbmFtZTIsIGFuZCBzbyBv bi4gVGhlIHByb3BlcnR5IHZhbHVlIHRoYXQgaXMNCgl1bHRpbWF0ZWx5IHJldHJpZXZlZCBvciBt b2RpZmllZCBpcyB0aGUgb25lIGlkZW50aWZpZWQgYnkgdGhlIGxhc3QgbmFtZQ0KCWVsZW1lbnQu DQoJDQoJKiBJbmRleGVkIChuYW1lW2luZGV4XSkgLSBUaGUgdW5kZXJseWluZyBwcm9wZXJ0eSB2 YWx1ZSBpcyBhc3N1bWVkIHRvIGJlIGFuDQoJYXJyYXksIG9yIHRoaXMgSmF2YUJlYW4gaXMgYXNz dW1lZCB0byBoYXZlIGluZGV4ZWQgcHJvcGVydHkgZ2V0dGVyIGFuZA0KCXNldHRlciBtZXRob2Rz LiBUaGUgYXBwcm9wcmlhdGUgKHplcm8tcmVsYXRpdmUpIGVudHJ5IGluIHRoZSBhcnJheSBpcw0K CXNlbGVjdGVkLiBMaXN0IG9iamVjdHMgYXJlIG5vdyBhbHNvIHN1cHBvcnRlZCBmb3IgcmVhZC93 cml0ZS4gWW91IHNpbXBseQ0KCW5lZWQgdG8gZGVmaW5lIGEgZ2V0dGVyIHRoYXQgcmV0dXJucyB0 aGUgTGlzdA0KCQ0KCSogTWFwcGVkIChuYW1lKGtleSkpIC0gVGhlIEphdmFCZWFuIGlzIGFzc3Vt ZWQgdG8gaGF2ZSBhbiBwcm9wZXJ0eSBnZXR0ZXINCglhbmQgc2V0dGVyIG1ldGhvZHMgd2l0aCBh biBhZGRpdGlvbmFsIGF0dHJpYnV0ZSBvZiB0eXBlIGphdmEubGFuZy5TdHJpbmcuDQoJDQoJKiBD b21iaW5lZCAobmFtZTEubmFtZTJbaW5kZXhdLm5hbWUzKGtleSkpIC0gQ29tYmluaW5nIG1hcHBl ZCwgbmVzdGVkLCBhbmQNCglpbmRleGVkIHJlZmVyZW5jZXMgaXMgYWxzbyBzdXBwb3J0ZWQNCgk8 L3F1b3RlPg0KCQ0KCVRoZSBxdWVzdGlvbiBpczogV2hlbiBhbmQgaG93IHRvIHdlIGFkZCBzdXBw b3J0IGZvciBpbmRleGVkIGFuZCBtYXBwZWQNCglwcm9wZXJ0aWVzPyBJIGd1ZXNzIHRoYXQgaWYg d2UgZG8sIHdlIHNob3VsZCBhZG9wdCB0aGUgQ29tbW9ucyBCZWFuVXRpbHMNCglzdHlsZSBvZiBz cGVjaWZ5aW5nIHByb3BlcnR5IHBhdGhzIGZvciBpbmRleCBhbmQgbWFwIGFjY2Vzcy4gVGhpcyBt ZWFucyB0aGF0DQoJd2Ugd291bGRuJ3QgbmVlZCBhZGRpdGlvbmFsIG1ldGhvZHMgaW4gdGhlIEJl YW5XcmFwcGVyIGludGVyZmFjZSBidXQgcmF0aGVyDQoJanVzdCBzdXBwb3J0IGZvciByZXNwZWN0 aXZlIHByb3BlcnR5IHBhdGhzIGluIHRoZSBCZWFuV3JhcHBlckltcGwNCglpbXBsZW1lbnRhdGlv bi4NCgkNCglBbnkgdGhvdWdodHMgb24gdGhpcz8gSSd2ZSBjb21wbGV0ZWx5IGZvcmdvdHRlbiBh Ym91dCB0aGVzZSB0aGluZ3MgaW4gZmFjZQ0KCW9mIGFsbCB0aGUgZW50ZXJwcmlzZSBzdHVmZiB3 ZSd2ZSBiZWVuIGFkZHJlc3NpbmcgbGF0ZWx5IDstKQ0KCQ0KCUp1ZXJnZW4NCgkNCgkNCglodHRw czovL3NvdXJjZWZvcmdlLm5ldC9mb3J1bS9tZXNzYWdlLnBocD9tc2dfaWQ9MjI1MTc3NQ0KCUJ5 OiBicmVpZGVucg0KCQ0KCUkgYW0gdXNpbmcgYSBTaW1wbGVGb3JtQ29udHJvbGxlciB0byBoZWxw IGNyZWF0ZSBhbiBvYmplY3QgdXNpbmcgYW4gSFRUUA0KCWZvcm0uDQoJT2J2aW91c2x5LCBpZiBt eSBmb3JtIG9iamVjdCBpcyBhIFZlbmRvciwgdGhhdCBvYmplY3QgaGFzIGEgc2V0TmFtZShTdHJp bmcpDQoJbWV0aG9kLCBhbmQgbXkgSFRUUCBmb3JtIGhhcyBhIGZpZWxkIG5hbWVkICJuYW1lIiwg dGhlIENvbnRyb2xsZXIgd2lsbCB0cnkNCgljYWxsDQoJVmVuZG9yLnNldE5hbWUoU3RyaW5nKSBh bmQgcGFzcyBpbiB0aGUgdmFsdWUgZnJvbSB0aGUgZm9ybS4gVGhpcyBhbHNvIGdvZXMNCglmb3IN CgluZXN0ZWQgcHJvcGVydGllczogYWRkcmVzcy5zZXRDaXR5IC0+IHZlbmRvci5nZXRBZGRyZXNz KCkuc2V0Q2l0eShTdHJpbmcpLg0KCQ0KCU15IHF1ZXN0aW9uIGlzLCBpcyB0aGVyZSBhbnkgc3Vw cG9ydCBmb3IgKmluZGV4ZWQqIHByb3BlcnRpZXM/IEJ5IHRoYXQsIEkNCgltZWFuDQoJcHVyY2hh c2VPcmRlclswXS5udW1iZXIgLT4gKCAoUHVyY2hhc2VPcmRlcikNCgl2ZW5kb3IuZ2V0UHVyY2hh c2VPcmRlcnMoKS5nZXQoMCkpLnNldE51bWJlcigpLiBJIGtub3cgdGhhdCBzb21lIGV4cHJlc3Np b24NCglsYW5ndWFnZXMgc3VwcG9ydCBzb21ldGhpbmcgbGlrZSB0aGlzLiBJSVJDLCBTdHJ1dHMg aGFzIHNvbWV0aGluZyBsaWtlIHRoaXMsDQoJYnV0IGl0IGhhcyBhIGxpdHRsZSBrbHVkZ3kuDQoJ DQoJRnJvbSB3aGF0IEkgY2FuIHRlbGwsIG5lc3RlZCBwb3JwZXJpZXMgYXJlIHN1cHBvcnRlZCBi eSB0aGUgU3ByaW5nDQoJQmVhbldyYXBwZXJJbXBsLA0KCWJ1dCB0aGF0IGlzIGl0LiBJZiB0aGlz IGlzIGNvcnJlY3QgYW5kIEkgd2FudCB0byBpbXBsZW1lbnQgbmVzdGVkDQoJcHJvcGVydGllcywN Cglhbnkgc3VnZ2VzdGlvbiBhcyB0byB0aGUgYmVzdCByb3V0ZS4NCgkNCglUaGFua3MuDQoJDQoJ Unlhbg0KCQ0KCQ0KCQ0KCVJlYWQgYW5kIHJlc3BvbmQgdG8gdGhpcyBtZXNzYWdlIGF0Og0KCWh0 dHBzOi8vc291cmNlZm9yZ2UubmV0L2ZvcnVtL21lc3NhZ2UucGhwP21zZ19pZD0yMTkzOTg0DQoJ Qnk6IGhvZ2llDQoJDQoJSGksDQoJDQoJDQoJDQoJSWYgSSBoYXZlIGEgY29tbWFuZCBvYmplY3Qg dGhhdCBzdG9yZXMgYSBjb2xsZWN0aW9uIGFuZCBJIHdhbnQgdGhlIGRhdGENCgliaW5kZXINCgl0 byBwb3B1bGF0ZSB0aGF0IGNvbGxlY3Rpb24gZnJvbSB0aGUgc2VydmxldCByZXF1ZXN0LCBob3cg c2hvdWxkIEkgbmFtZSB0aGUNCglwYXJhbWV0ZXJzIGluIG15IHNlcnZsZXQgcmVxdWVzdD8NCgkN CgkNCglJbiBTdHJ1dHMgSSBjYW4gZG8gZmllbGRbaW5kZXhdLCBidXQgSSBjYW4ndCBzZWUgaWYg dGhlIHNhbWUgaXMgcG9zc2libGUgaW4NCglTcHJpbmcuICBJIHNlZSBCZWFuV3JhcHBlci5nZXRJ bmRleGVkUHJvcGVydHlWYWx1ZSgpICwgYnV0IG5vIHNldCgpDQoJZXF1aXZhbGVudC4NCgkNCgkN CglNYW55IHRoYW5rcywNCgkNCglNaWtlLg0KCQ0KCQ0KCQ0KCQ0KCS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlzIFNGLm5ldCBlbWFp bCBpcyBzcG9uc29yZWQgYnk6IFRoZSBTRi5uZXQgRG9uYXRpb24gUHJvZ3JhbS4NCglEbyB5b3Ug bGlrZSB3aGF0IFNvdXJjZUZvcmdlLm5ldCBpcyBkb2luZyBmb3IgdGhlIE9wZW4NCglTb3VyY2Ug Q29tbXVuaXR5PyAgTWFrZSBhIGNvbnRyaWJ1dGlvbiwgYW5kIGhlbHAgdXMgYWRkIG5ldw0KCWZl YXR1cmVzIGFuZCBmdW5jdGlvbmFsaXR5LiBDbGljayBoZXJlOiBodHRwOi8vc291cmNlZm9yZ2Uu bmV0L2RvbmF0ZS8NCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJh bWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNv dXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJ DQoNCg== |
|
From: Rod J. <rod...@in...> - 2003-10-25 15:20:48
|
Juergen, I think we should provide indexed property support for M3. I think you were right to remove the inadequate support for now. I think supporting the Commons syntax makes sense. I think at one point I envisaged having an IndexedPropertyValue class, but that's probably unnecessary. Regards, Rod -----Original Message----- From: jürgen höller [werk3AT] Sent: Thursday, October 23, 2003 4:50 PM To: spr...@li... Subject: FW: [springframework - Help] Index properties in forms Everybody, Seems like we've got two people inquiring for indexed property support. The second already dates back to mid-September :-( I've just rechecked the BeanWrapper implementation and discovered that there is no proper support for indexed properties yet. The existing getIndexedProperty method was not complete (e.g. no support for nesting) and untested (no unit test covered it), so I've decided to remove it for the time being (for 1.0 M2). It just confused both of those guys that were looking for indexed property support. Jakarta Commons BeanUtils does support nested and mapped properties, quoting from the javadocs of their PropertyUtils class: <quote> For the purposes of this class, five formats for referencing a particular property value of a bean are defined, with the layout of an identifying String in parentheses: * Simple (name) - The specified name identifies an individual property of a particular JavaBean. The name of the actual getter or setter method to be used is determined using standard JavaBeans instrospection, so that (unless overridden by a BeanInfo class, a property named "xyz" will have a getter method named getXyz() or (for boolean properties only) isXyz(), and a setter method named setXyz(). * Nested (name1.name2.name3) The first name element is used to select a property getter, as for simple references above. The object returned for this property is then consulted, using the same approach, for a property getter for a property named name2, and so on. The property value that is ultimately retrieved or modified is the one identified by the last name element. * Indexed (name[index]) - The underlying property value is assumed to be an array, or this JavaBean is assumed to have indexed property getter and setter methods. The appropriate (zero-relative) entry in the array is selected. List objects are now also supported for read/write. You simply need to define a getter that returns the List * Mapped (name(key)) - The JavaBean is assumed to have an property getter and setter methods with an additional attribute of type java.lang.String. * Combined (name1.name2[index].name3(key)) - Combining mapped, nested, and indexed references is also supported </quote> The question is: When and how to we add support for indexed and mapped properties? I guess that if we do, we should adopt the Commons BeanUtils style of specifying property paths for index and map access. This means that we wouldn't need additional methods in the BeanWrapper interface but rather just support for respective property paths in the BeanWrapperImpl implementation. Any thoughts on this? I've completely forgotten about these things in face of all the enterprise stuff we've been addressing lately ;-) Juergen https://sourceforge.net/forum/message.php?msg_id=2251775 By: breidenr I am using a SimpleFormController to help create an object using an HTTP form. Obviously, if my form object is a Vendor, that object has a setName(String) method, and my HTTP form has a field named "name", the Controller will try call Vendor.setName(String) and pass in the value from the form. This also goes for nested properties: address.setCity -> vendor.getAddress().setCity(String). My question is, is there any support for *indexed* properties? By that, I mean purchaseOrder[0].number -> ( (PurchaseOrder) vendor.getPurchaseOrders().get(0)).setNumber(). I know that some expression languages support something like this. IIRC, Struts has something like this, but it has a little kludgy. From what I can tell, nested porperies are supported by the Spring BeanWrapperImpl, but that is it. If this is correct and I want to implement nested properties, any suggestion as to the best route. Thanks. Ryan Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2193984 By: hogie Hi, If I have a command object that stores a collection and I want the data binder to populate that collection from the servlet request, how should I name the parameters in my servlet request? In Struts I can do field[index], but I can't see if the same is possible in Spring. I see BeanWrapper.getIndexedPropertyValue() , but no set() equivalent. Many thanks, Mike. |
|
From: Colin S. <col...@ex...> - 2003-10-30 17:09:05
|
Depending on how the expression language is implemented (or rather, what syntax the expression language has), I think there is a bit of a potential conflict with PropertyOverrideConfigurer and PropertyPlaceHolderConfigurer, so this is one area that maybe has to be thought about. I think I wrote about this before, but my other suggestion is to make the impl. pluggable, with a namespace prefix to indicate which impl. to actually use, e.g. "ognl:bean1.bean2['key']" would use the ognl impl. Lack of a prefix would default to something. I would suggest that one good approach is to go pluggable like this, but have only a basic implementation in Spring, which wouldn't add much to the size of Spring, and then people could add in support for other expression languages if they wanted to. I would probably add OGNL for example, since I think its great. OGNL btw is at: http://www.ognl.org http://www.ognl.org/2.6.3/Documentation/html/UsersGuide.html. Regards, Colin jürgen höller [werk3AT] wrote: >FYI, we've now got actual requirements for indexed properties in a werk3AT product -- to be implemented by the end of next week. So I'm gonna work on it early next week, suggestions and help are welcome of course. It shouldn't be too hard to do even if fully implemented on our own; the harder part is to settle on a certain syntax. > >Juergen > > > -----Ursprüngliche Nachricht----- > Von: Rod Johnson [mailto:rod...@in...] > Gesendet: Do 23.10.2003 17:32 > An: jürgen höller [werk3AT] > Cc: spr...@li... > Betreff: [Springframework-developer] Re: [springframework - Help] Index properties in forms > > > > Juergen, > > I think we should provide indexed property support for M3. I think you were > right to remove the inadequate support for now. > > I think supporting the Commons syntax makes sense. I think at one point I > envisaged having an IndexedPropertyValue class, but that's probably > unnecessary. > > Regards, > Rod > > -----Original Message----- > From: jürgen höller [werk3AT] > Sent: Thursday, October 23, 2003 4:50 PM > To: spr...@li... > Subject: FW: [springframework - Help] Index properties in forms > > > Everybody, > > Seems like we've got two people inquiring for indexed property support. The > second already dates back to mid-September :-( > > I've just rechecked the BeanWrapper implementation and discovered that there > is no proper support for indexed properties yet. The existing > getIndexedProperty method was not complete (e.g. no support for nesting) and > untested (no unit test covered it), so I've decided to remove it for the > time being (for 1.0 M2). It just confused both of those guys that were > looking for indexed property support. > > Jakarta Commons BeanUtils does support nested and mapped properties, quoting > from the javadocs of their PropertyUtils class: > > <quote> > For the purposes of this class, five formats for referencing a particular > property value of a bean are defined, with the layout of an identifying > String in parentheses: > > * Simple (name) - The specified name identifies an individual property of a > particular JavaBean. The name of the actual getter or setter method to be > used is determined using standard JavaBeans instrospection, so that (unless > overridden by a BeanInfo class, a property named "xyz" will have a getter > method named getXyz() or (for boolean properties only) isXyz(), and a setter > method named setXyz(). > > * Nested (name1.name2.name3) The first name element is used to select a > property getter, as for simple references above. The object returned for > this property is then consulted, using the same approach, for a property > getter for a property named name2, and so on. The property value that is > ultimately retrieved or modified is the one identified by the last name > element. > > * Indexed (name[index]) - The underlying property value is assumed to be an > array, or this JavaBean is assumed to have indexed property getter and > setter methods. The appropriate (zero-relative) entry in the array is > selected. List objects are now also supported for read/write. You simply > need to define a getter that returns the List > > * Mapped (name(key)) - The JavaBean is assumed to have an property getter > and setter methods with an additional attribute of type java.lang.String. > > * Combined (name1.name2[index].name3(key)) - Combining mapped, nested, and > indexed references is also supported > </quote> > > The question is: When and how to we add support for indexed and mapped > properties? I guess that if we do, we should adopt the Commons BeanUtils > style of specifying property paths for index and map access. This means that > we wouldn't need additional methods in the BeanWrapper interface but rather > just support for respective property paths in the BeanWrapperImpl > implementation. > > Any thoughts on this? I've completely forgotten about these things in face > of all the enterprise stuff we've been addressing lately ;-) > > Juergen > > > https://sourceforge.net/forum/message.php?msg_id=2251775 > By: breidenr > > I am using a SimpleFormController to help create an object using an HTTP > form. > Obviously, if my form object is a Vendor, that object has a setName(String) > method, and my HTTP form has a field named "name", the Controller will try > call > Vendor.setName(String) and pass in the value from the form. This also goes > for > nested properties: address.setCity -> vendor.getAddress().setCity(String). > > My question is, is there any support for *indexed* properties? By that, I > mean > purchaseOrder[0].number -> ( (PurchaseOrder) > vendor.getPurchaseOrders().get(0)).setNumber(). I know that some expression > languages support something like this. IIRC, Struts has something like this, > but it has a little kludgy. > > From what I can tell, nested porperies are supported by the Spring > BeanWrapperImpl, > but that is it. If this is correct and I want to implement nested > properties, > any suggestion as to the best route. > > Thanks. > > Ryan > > > > Read and respond to this message at: > https://sourceforge.net/forum/message.php?msg_id=2193984 > By: hogie > > Hi, > > > > If I have a command object that stores a collection and I want the data > binder > to populate that collection from the servlet request, how should I name the > parameters in my servlet request? > > > In Struts I can do field[index], but I can't see if the same is possible in > Spring. I see BeanWrapper.getIndexedPropertyValue() , but no set() > equivalent. > > > Many thanks, > > Mike. > > |
|
From: Rod J. <rod...@in...> - 2003-10-30 17:36:25
|
> I would suggest that one good approach is to go pluggable like this, but > have only a basic implementation in Spring, which wouldn't add much to > the size of Spring, and then people could add in support for other > expression languages if they wanted to. I would probably add OGNL for > example, since I think its great. +1 |
