Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-05-28 05:31:27
|
SGkgUm9kLA0KIA0KSSBhZ3JlZSB0aGF0IHRoZSBuZXcgZm9ybWF0IG1ha2VzIHNlbnNlLiBJIGRp ZG4ndCB0aGluayBhYm91dCB2YWxpZGF0aW5nIHRoZSBYTUwgYmVmb3JlLCBidXQgdG8gbXkgdW5k ZXJzdGFuZGluZyB5b3UncmUgcmlnaHQgYWJvdXQgdGhlIHBpdGZhbGxzLiBLZWVwaW5nIGJhY2t3 YXJkcyBjb21wYXRpYmlsaXR5IGZvciB0aGUgbW9tZW50IG1ha2VzIHNlbnNlLCBhcyBlYWNoIGFu ZCBldmVyeSBhcHBsaWNhdGlvbiBjb250ZXh0IGRlZmluaXRpb24gd2lsbCBiZSBhZmZlY3RlZCAo YWRtaXR0ZWRseSBpbiBhIHN0cmFpZ2h0Zm9yd2FyZCB3YXkpLg0KIA0KU28gYmVzaWRlcyB0aGUg PHJlZj4gdGFnLCB0aGVyZSdzIGEgPHZhbHVlPiB0YWcgbm93LCBmb3IgbWl4ZWQgY29sbGVjdGlv bnMuIEkgZ3Vlc3MgaXQgY2FuIGFsc28gYmUgdXNlZCB3aXRoIGEgc2luZ2xlIHZhbHVlIHByb3Bl cnR5IGxpa2UgdGhpczoNCiANCjxwcm9wZXJ0eSBuYW1lPSJuYW1lIj48dmFsdWU+Um9kPC92YWx1 ZT48L3Byb3BlcnR5Pg0KDQpEbyB5b3UgcmVjb21tZW5kIHRoaXMgc3ludGF4IGZvciBzdWNoIHBy b3BlcnRpZXMgdG9vPyBEb2VzIGl0IGFkZCBhbnkgdmFsdWUgaW4gdGVybXMgb2YgdmFsaWRhdGlv bj8gV2Ugc2hvdWxkIGRlZmluaXRlbHkgc3RpY2sgdG8gb25lIHJlY29tbWVuZGVkIHN5bnRheCwg dG8gYXZvaWQgY29uZnVzaW9uLg0KDQpSZWdhcmRpbmcgYmVhbnMgdGhhdCBleHBvc2UgQ1NWIHBy b3BlcnRpZXM6IEkndmUgYWxyZWFkeSB0cmllZCB0byBjbGVhbiBtYW55IG9mIHRoZSBleHBvc2Vk IGJlYW4gcHJvcGVydGllcyB3aXRoaW4gU3ByaW5nIChlLmcuIGJvdGggY29tbWFuZENsYXNzIGFu ZCBjb21tYW5kQ2xhc3NOYW1lLCBub3cgb25seSB0aGUgZm9ybWVyIGJlY2F1c2Ugb2YgdGhlIENs YXNzRWRpdG9yKSwgd2Ugc2hvdWxkIHRyeSB0byBjb250aW51ZSB0aGlzIGZvciBtdWx0aXBsZSB2 YWx1ZSBwcm9wZXJ0aWVzLiBJIGd1ZXNzIGlmIGNob2ljZSBkb2Vzbid0IGFkZCByZWFsIHZhbHVl LCBpdCByYXRoZXIgY2F1c2VzIGNvbmZ1c2lvbi4NCiANCkknbSBub3QgYW4gWE1MIGV4cGVydCwg c28gSSBjYW4ndCByZWFsbHkgaGVscCBpbiB0ZXJtcyBvZiBmdXJ0aGVyIGltcHJvdmVtZW50cy4g RG9lcyBhbnlvbmUgZWxzZSBoYXZlIHNvbWUgdGhvdWdodHMgb24gdGhpcz8NCg0KUmVnYXJkcywN Ckp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJ Vm9uOiBSb2QgSm9obnNvbiBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0gDQoJ R2VzZW5kZXQ6IERpIDI3LjA1LjIwMDMgMjI6MTkgDQoJQW46IHNwcmluZ2ZyYW1ld29yay1kZXZl bG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglCZXRyZWZmOiBSZTogW1Nwcmlu Z2ZyYW1ld29yay1kZXZlbG9wZXJdIFNwcmluZyBiZWFuIGZhY3RvcnkgWE1MIGZvcm1hdA0KCQ0K CQ0KDQoJSSd2ZSBzdWNjZXNzZnVsbHkgcHJvdG90eXBlZCB0aGlzIGlkZWEuDQoJDQoJVGhlIG5l dyBmb3JtYXQgbG9va3MgbGlrZToNCgkNCgk8YmVhbiBuYW1lPSJyb2QiIGNsYXNzPSJjb20uaW50 ZXJmYWNlMjEuYmVhbnMuVGVzdEJlYW4iPg0KCSA8cHJvcGVydHkgbmFtZT0ibmFtZSI+Um9kPC9w cm9wZXJ0eT4NCgkgPHByb3BlcnR5IG5hbWU9ImFnZSI+MzI8L3Byb3BlcnR5Pg0KCSA8cHJvcGVy dHkgbmFtZT0iZnJpZW5kcyI+DQoJICA8cmVmIG5hbWU9Implbm55Ii8+DQoJICA8cmVmIG5hbWU9 ImRhdmlkIi8+DQoJIDwvcHJvcGVydHk+DQoJPC9iZWFuPg0KCQ0KCTwhLS0NCgkgVHJ5IHNldHRp bmcgYSBjb2xsZWN0aW9uIHByb3BlcnR5IHRvIGEgc2luZ2xlIHZhbHVlDQoJLS0+DQoJPGJlYW4g bmFtZT0ibG9uZXIiIGNsYXNzPSJjb20uaW50ZXJmYWNlMjEuYmVhbnMuVGVzdEJlYW4iPg0KCSA8 cHJvcGVydHkgbmFtZT0ibmFtZSI+bG9uZXI8L3Byb3BlcnR5Pg0KCSA8cHJvcGVydHkgbmFtZT0i YWdlIj4yNjwvcHJvcGVydHk+DQoJIDxwcm9wZXJ0eSBuYW1lPSJmcmllbmRzIj4NCgkgIDxyZWYg bmFtZT0iZGF2aWQiLz4NCgkgPC9wcm9wZXJ0eT4NCgk8L2JlYW4+DQoJDQoJPGJlYW4gbmFtZT0i anVtYmxlIg0KCWNsYXNzPSJjb20uaW50ZXJmYWNlMjEuYmVhbnMuZmFjdG9yeS54bWwuTWl4ZWRD b2xsZWN0aW9uQmVhbiI+DQoJIDxwcm9wZXJ0eSBuYW1lPSJqdW1ibGUiPg0KCSAgIDxyZWYgbmFt ZT0iZGF2aWQiLz4NCgkgICA8dmFsdWU+bGl0ZXJhbDwvdmFsdWU+DQoJICAgPHJlZiBuYW1lPSJq ZW5ueSIgLz4NCgkgPC9wcm9wZXJ0eT4NCgk8L2JlYW4+DQoJDQoJSSBoYXZlbid0IGRyb3BwZWQg YmFja3dhcmQgY29tcGF0aWJpbGl0eSwgb3IgY2hlY2tlZCBhbnl0aGluZyBpbi4NCgkNCglJZiB3 ZSBhZ3JlZSB0aGlzIGlzIGFuIGltcHJvdmVtZW50LCBJJ2xsIGNoZWNrIGluIHRoZXNlIGNoYW5n ZXMgdGhpcyB3ZWVrLiBJDQoJZ3Vlc3MgSSBkb24ndCBuZWVkIHRvIGRyb3AgYmFja3dhcmQgY29t cGF0aWJpbGl0eSByaWdodCBub3cgKGJlYW5SZWYpLCBidXQNCglJIHRoaW5rIGl0IHNob3VsZCBi ZSBkcm9wcGVkIGJlZm9yZSAxLjAuDQoJDQoJSSdtIG9wZW4gdG8gc3VnZ2VzdGlvbnMgYXMgdG8g aG93IHRvIGltcHJvdmUgdGhlIFhNTCBmdXJ0aGVyLg0KCQ0KCVJlZ2FyZHMsDQoJUm9kDQoJDQoJ LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KCUZyb206ICJSb2QgSm9obnNvbiIgPHJvZC5q b2huc29uQGludGVyZmFjZTIxLmNvbT4NCglUbzogPHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJA bGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KCVNlbnQ6IFR1ZXNkYXksIE1heSAyNywgMjAwMyA2OjIw IFBNDQoJU3ViamVjdDogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFNwcmluZyBiZWFuIGZh Y3RvcnkgWE1MIGZvcm1hdA0KCQ0KCQ0KCT4gR3V5cywNCgk+DQoJPiBJJ3ZlIGp1c3QgYmVlbiB0 aGlua2luZyBhYm91dCBhbiBpbXBvcnRhbnQgcG90ZW50aWFsIGlzc3VlLg0KCT4NCgk+IFRoZSBj dXJyZW50IFhNTCBiZWFuLXJlZmVyZW5jZSBzeW50YXggbG9va3MgbGlrZToNCgk+IDxwcm9wZXJ0 eSBuYW1lPSJmb28iIGJlYW5SZWY9InRydWUiPm15Rm9vQmVhbjwvcHJvcGVydHk+DQoJPg0KCT4g YW5kLCBmb3IgbGlzdHMgZXRjICh3aGVyZSBhIGJlYW4gZXhwb3NlcyBhICJDU1YiIHByb3BlcnR5 KQ0KCT4gPHByb3BlcnR5IG5hbWU9ImZvb3MiPmEsYixjPC9wcm9wZXJ0eT4NCgk+DQoJPiBXaGls ZSB0aGlzIHN5bnRheCBpcyBjb25jaXNlLCBJIHRoaW5rIHRoZXJlIGFyZSBzb21lIGlzc3VlcyB3 ZSBzaG91bGQNCgk+IGRpc2N1c3MuDQoJPg0KCT4gYS4gSXQncyBoYXJkIHRvIHZhbGlkYXRlIHRo aXMuIFRoZXJlJ3Mgbm8gdmFsaWRhdGFibGUgcmVmZXJlbmNlIHRvIGFub3RoZXINCgk+IGJlYW4g ZWxlbWVudCBpZC4gSXQgd291bGQgYmUgZ3JlYXQgaWYgYW4gWE1MIGVkaXRvciBjb3VsZCBoZWxw IHVzIGluIHRoaXMNCgk+IHJlZ2FyZC4NCgk+IGIuIEl0J3MgaW5lbGVnYW50LiBUaGUgdXNlIG9m IHRoZSBDREFUQSBpbiB0aGUgcHJvcGVydHkgZWxlbWVudCBhcyBhDQoJc3RyaW5nDQoJPiB2YWx1 ZSBvciBhIHJlZmVyZW5jZSAoZGVwZW5kaW5nIG9uIHRoZSBwcmVzZW5jZSBvZiBhbiBhdHRyaWJ1 dGUpIGlzIGEgYml0DQoJPiBtZXNzeS4NCgk+IGMuIFRoZSBDU1YgZm9ybWF0IGlzIHJlYWxseSBh IGhhY2ssIHRoYXQgSSB1c2VkIG9uY2UgYW5kIHRoZW4gcmV1c2VkLiBOb3QNCgk+IG9ubHkgZG9l cyB0aGUgQ1NWIG1ha2Ugbm8gc2Vuc2UgdG8gYW4gWE1MIGVkaXRvciAoYW5hbG9nb3VzIHRvIHB1 dHRpbmcgQ1NWDQoJPiBkYXRhIGluIGFuIFJEQk1TKSwgaXQgcGxhY2VzIHRoZSBvbnVzIG9uIGVh Y2ggY2xhc3MgdG8gcGFyc2UgdGhlIENTViBhbmQNCgk+IGxvb2sgdXAgdGhlIG5lY2Vzc2FyeSBi ZWFucy4gVGhpcyBtYWtlcyBjbGFzc2VzIGV4cG9zaW5nIENTViBwcm9wZXJ0aWVzDQoJPiBkZXBl bmRlbnQgb24gdGhlIG93bmluZyBCZWFuRmFjdG9yeSwgbGVzc2VuaW5nIHRoZSB2YWx1ZSBvZiBT cHJpbmcncw0KCT4gdHJhbnNwYXJlbmNlLiAoQWRtaXR0ZWRseSB0aGlzIGlzIGNvbmNlYWxlZCBp biBmcmFtZXdvcmsgY2xhc3Nlcywgc28gaXQNCgk+IGRvZXNuJ3QgcmVhbGx5IGFmZmVjdCBkZXZl bG9wZXJzLikgV2l0aCB0aGUgcHJvcG9zZWQgbmV3IHdheSwgYW55DQoJPiBhcHBsaWNhdGlvbiBj b2RlIGNvdWxkIGJlbmVmaXQgZnJvbSBjb2xsZWN0aW9uICYgYXJyYXkgc3VwcG9ydC4NCgk+IGQu IFRoZSBuZXcgd2F5IHdvdWxkIG1ha2UgaXQgZWFzeSB0byB3cml0ZSBYU0xUIHRoYXQgc2hvd2Vk IHJlbGF0aW9uc2hpcHMNCgk+IGFtb25nIFNwcmluZyBiZWFucy4gVGhpcyBjb3VsZCBiZSBoYW5k eSBmb3IgZ2VuZXJhdGluZyBkb2N1bWVudGF0aW9uIGFib3V0DQoJPiBTcHJpbmcgYXBwcy4NCgk+ DQoJPiBTbyBJJ3ZlIGJlZW4gdGhpbmtpbmcgb2YgY2hhbmdlcyBhbG9uZyB0aGUgbGluZXMgb2Y6 DQoJPg0KCT4gPHByb3BlcnR5IG5hbWU9ImZvbyI+DQoJPiAgICAgPHJlZiBuYW1lPSJteUZvb0Jl YW4iIC8+DQoJPiA8L3Byb3BlcnR5Pg0KCT4NCgk+IGFuZA0KCT4NCgk+IDxwcm9wZXJ0eSBuYW1l PSJmb29zIj4NCgk+ICAgICA8cmVmIG5hbWU9ImEiIC8+DQoJPiAgICAgPHJlZiBuYW1lPSJiIi8+ DQoJPiAgICAgPHJlZiBuYW1lPSJjIi8+DQoJPiA8L3Byb3BlcnR5Pg0KCT4NCgk+IEluIHRoaXMg Y2FzZSB0aGUgZm9vcyBiZWFuIGNsYXNzIHdvdWxkIGV4cG9zZSBhIENvbGxlY3Rpb24gb3IgYXJy YXkNCgk+IHByb3BlcnR5LCBhbmQgdGhlIGJlYW4gZmFjdG9yeSB3b3VsZCBubyBob3cgdG8gcG9w dWxhdGUgdGhhdCBmcm9tIHRoZQ0KCT4gcnVudGltZSByZWZlcmVuY2VzLiBObyBkZXBlbmRlbmNl IG9uIHRoZSBmdyBldmVuIGZvciBtYW5hZ2luZyBjb2xsZWN0aW9uDQoJPiBwcm9wZXJ0aWVzLg0K CT4NCgk+IEkndmUgYWxyZWFkeSBwcm90b3R5cGVkIHRoZSBpZGVhIG9mIGEgPHJlZj4gc3ViZWxl bWVudCwgYW5kIHRoYXQgd2FzDQoJcHJldHR5DQoJPiBzaW1wbGUgdG8gaW1wbGVtZW50LiAgSSds bCBleHBlcmltZW50IHdpdGggY29sbGVjdGlvbnMgdG9uaWdodC4NCgk+DQoJPiBBcGFydCBmcm9t IGNoYW5naW5nIFhNTCBmaWxlcywgdGhlIGZsb3ctb24gZWZmZWN0IHdvdWxkIG1lYW4gdGhhdCBh bnl0aGluZw0KCT4gdGhhdCBleHBvc2VkIGEgQ1NWIHByb3BlcnR5IChsaWtlIHRoZSBBT1AgaW50 ZXJjZXB0b3IgcHJveHkpIHdvdWxkIGNoYW5nZQ0KCXRvDQoJPiBleHBvc2luZyBhIENvbGxlY3Rp b24gb3IgYXJyYXkuDQoJPg0KCT4gV2hhdCBkbyB5b3UgdGhpbms/IEknZCBsaWtlIHRob3VnaHRz IG9uIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOg0KCT4NCgk+IDEuIERvZXMgZXZlcnlvbmUgYWdy ZWUgdGhhdCB0aGlzIGlzIHdvcnRoIGRvaW5nPw0KCT4NCgk+IDIuIFRvIHN1cHBvcnQgYSBjb2xs ZWN0aW9uIGluY2x1ZGluZyBsaXRlcmFsIHZhbHVlcywgc2hvdWxkIHdlIGludHJvZHVjZSBhDQoJ PiBuZXcgPHZhbHVlPiBlbGVtZW50LCBtZWFuaW5nIHRoYXQgc2ltcGxlIHByb3BlcnRpZXMgd291 bGQgYmVjb21lDQoJPiA8cHJvcGVydHkgbmFtZT0iZm9vIj48dmFsdWU+Y2FuQ29udmVydCB0aGlz IHN0cmluZzwvdmFsdWU+PC9wcm9wZXJ0eT4uDQoJTW9yZQ0KCT4gdmVyYm9zZSwgYnV0IG1vcmUg ZWxlZ2FudC4NCgk+DQoJPiAzLiBJcyB0aGVyZSBhIHdheSB0byBoZWxwIFhNTCBlbmZvcmNlIHRo ZSByZWZlcmVuY2VzIGF1dG9tYXRpY2FsbHk/IEUuZy4NCgk+IGNoYW5nZSBiZWFuICJuYW1lIiB0 byAiaWQiIGFuZCB1c2UgYSA8aHJlZj4gaW5zdGVhZCBvZiBhIDxyZWY+PyBJIGhhdmVuJ3QNCgk+ IGhhZCBhIGNoYW5jZSB0byBleHBsb3JlIHRoaXMgeWV0LCBidXQgaG9wZWZ1bGx5IHNvbWVvbmUg a25vd3MgWE1MIGJldHRlcg0KCT4gdGhhbiBJIGRvLg0KCT4NCgk+IDQuIElmIHRoaXMgaXMgd29y dGggZG9pbmcsIHNob3VsZCB3ZSBkbyBpdCBpbiAwLjgsIGV2ZW4gaWYgaXQgZGVsYXlzIHRoZQ0K CT4gcmVsZWFzZSAgKGFzIGl0IHdvdWxkKT8gT24gdGhlIG9uZSBoYW5kLCB3ZSBzaG91bGQgdHJ5 IHRvIHJlbGVhc2UgQVNBUC4gT24NCgk+IHRoZSBvdGhlciBoYW5kLCB0aGlzIGNoYW5nZSB3b3Vs ZCBicmVhayBhbGwgZXhpc3RpbmcgYXBwbGljYXRpb25zLiBFdmVuDQoJPiB0aG91Z2ggdGhleSdk IGJlIGVhc3kgdG8gZml4LCBpdCBtaWdodCBpcnJpdGF0ZSB1c2Vycy4gU28gdGhlIGNob2ljZSBp czoNCgk+IC0gcmVsZWFzZSBub3cgd2l0aCBhIGxpa2VseSBpbmNvbXBhdGlibGUgY2hhbmdlIGlu IHN0b3JlDQoJPiAtIGFjY2VwdCBhIGRlbGF5DQoJPg0KCT4gV2UnZCBhbHNvIGhhdmUgdG8gaW50 cm9kdWNlIGFuYWxvZ291cyBzdXBwb3J0IGZvciB0aGUgcHJvcGVydGllcyBmb3JtYXQsDQoJPiB3 aGljaCBjb3VsZG4ndCBiZW5lZml0IGZyb20gWE1MIGNhcGFiaWxpdGllcy4gVGhlIHByb3BlcnRp ZXMgZm9ybWF0IHdvdWxkDQoJPiBwcm9iYWJseSBjaGFuZ2UgdmVyeSBsaXR0bGUuDQoJPg0KCT4g UmVnYXJkcywNCgk+IFJvZA0KCT4NCgk+DQoJPg0KCT4NCgk+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCgk+IFRoaXMgU0YubmV0IGVtYWls IGlzIHNwb25zb3JlZCBieTogT2JqZWN0U3RvcmUuDQoJPiBJZiBmbGF0dGVuaW5nIG91dCBDKysg b3IgSmF2YSBjb2RlIHRvIG1ha2UgeW91ciBhcHBsaWNhdGlvbiBmaXQgaW4gYQ0KCT4gcmVsYXRp b25hbCBkYXRhYmFzZSBpcyBwYWluZnVsLCBkb24ndCBkbyBpdCEgQ2hlY2sgb3V0IE9iamVjdFN0 b3JlLg0KCT4gTm93IHBhcnQgb2YgUHJvZ3Jlc3MgU29mdHdhcmUuIGh0dHA6Ly93d3cub2JqZWN0 c3RvcmUubmV0L3NvdXJjZWZvcmdlDQoJPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KCT4gU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxp c3QNCgk+IFNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJ PiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFt ZXdvcmstZGV2ZWxvcGVyDQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YubmV0IGVtYWlsIGlzIHNwb25z b3JlZCBieTogT2JqZWN0U3RvcmUuDQoJSWYgZmxhdHRlbmluZyBvdXQgQysrIG9yIEphdmEgY29k ZSB0byBtYWtlIHlvdXIgYXBwbGljYXRpb24gZml0IGluIGENCglyZWxhdGlvbmFsIGRhdGFiYXNl IGlzIHBhaW5mdWwsIGRvbid0IGRvIGl0ISBDaGVjayBvdXQgT2JqZWN0U3RvcmUuDQoJTm93IHBh cnQgb2YgUHJvZ3Jlc3MgU29mdHdhcmUuIGh0dHA6Ly93d3cub2JqZWN0c3RvcmUubmV0L3NvdXJj ZWZvcmdlDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0KCVNwcmluZ2ZyYW1ld29y ay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0cHM6Ly9saXN0cy5zb3VyY2Vm b3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0KCQ0KDQo= |
|
From: <rod...@in...> - 2003-05-28 10:17:57
|
Isabelle, OK, we can change name -> id when defining all beans, and use refid for references. The only problem I see with your syntax below... <property name="thefoo" refid="foo/> <property name="moo">moo</property> ...is that I can't see how it would support collections. I see this as a major enhancement, possible with the original proposal, that had <value> and <ref> subelements. I can easily change the XML parsing for whatever we agree. Regards, Rod > Hi Rod, > > There is one thing I do not like about your proposed syntax: you use <ref > name="xxx"> is used in two different contexts, one when you define a bean > that can serve as a reference, and once when you refer to such a bean from > another bean. > That's confusing. It would be better to define with for ex. an id attribute, > and reference with a refid attribute: > > <bean name="foo" id="foo"/> > <bean name="bar" id="bar"> > <property name="thefoo" refid="foo/> > <property name="moo">moo</property> > </bean> > <bean name=baz> > <property name="bla">blabla</property> > </bean> > > Note that bean bar can in turn be referenced from other beans, thanks to its > id attribute. Bean baz cannot be referenced, because it doesn't have an id > attribute. > > A validating parser will not help you make sure that bean foo really exists > when referenced, and neither will a DTD. > > Isabelle |
|
From: Isabelle M. <isa...@me...> - 2003-05-28 10:32:56
|
HI Rod, Do it the way JP suggested : <bean id="foo"> <property name="moo">moo</property> <property name="coll"> <element refid="alpha"> <element refid="beta> </property> </bean> Isabelle On Wed, May 28, 2003 at 06:17:54AM -0400, rod...@in... wrote: > Isabelle, > > OK, we can change name -> id when defining all beans, and use > refid for references. > > The only problem I see with your syntax below... > > <property name="thefoo" refid="foo/> > <property name="moo">moo</property> > > ...is that I can't see how it would support collections. I > see this as a major enhancement, possible with the original > proposal, that had <value> and <ref> subelements. > > I can easily change the XML parsing for whatever we agree. > > Regards, > Rod > > > Hi Rod, > > > > There is one thing I do not like about your proposed > syntax: you use <ref > > name="xxx"> is used in two different contexts, one when you > define a bean > > that can serve as a reference, and once when you refer to > such a bean from > > another bean. > > That's confusing. It would be better to define with for ex. > an id attribute, > > and reference with a refid attribute: > > > > <bean name="foo" id="foo"/> > > <bean name="bar" id="bar"> > > <property name="thefoo" refid="foo/> > > <property name="moo">moo</property> > > </bean> > > <bean name=baz> > > <property name="bla">blabla</property> > > </bean> > > > > Note that bean bar can in turn be referenced from other > beans, thanks to its > > id attribute. Bean baz cannot be referenced, because it > doesn't have an id > > attribute. > > > > A validating parser will not help you make sure that bean > foo really exists > > when referenced, and neither will a DTD. > > > > Isabelle > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: <jue...@we...> - 2003-05-28 10:40:06
|
What about mixing references and values in a collection? Would it look = as follows: <bean id=3D"foo"> <property name=3D"moo">moo</property> <property name=3D"coll"> <element refid=3D"alpha"/> <element refid=3D"beta"/> <element>gamma</element> </property> </bean> Rod's proposed syntax would be like this: <bean id=3D"foo"> <property name=3D"moo">moo</property> <property name=3D"coll"> <ref refid=3D"alpha"/> <ref refid=3D"beta"/> <value>gamma</value> </property> </bean> I tend to prefer the latter, as it clearly separates references and = values. Juergen -----Original Message----- From: Isabelle Muszynski [mailto:isa...@me...] Sent: Wednesday, May 28, 2003 12:33 PM To: rod...@in... Cc: spr...@li... Subject: Re: [Springframework-developer] Spring bean factory XML format HI Rod, Do it the way JP suggested : <bean id=3D"foo"> <property name=3D"moo">moo</property> <property name=3D"coll"> <element refid=3D"alpha"> <element refid=3D"beta> </property> </bean> Isabelle On Wed, May 28, 2003 at 06:17:54AM -0400, rod...@in... = wrote: > Isabelle,=20 >=20 > OK, we can change name -> id when defining all beans, and use=20 > refid for references. >=20 > The only problem I see with your syntax below... >=20 > <property name=3D"thefoo" refid=3D"foo/> > <property name=3D"moo">moo</property> >=20 > ...is that I can't see how it would support collections. I=20 > see this as a major enhancement, possible with the original=20 > proposal, that had <value> and <ref> subelements. >=20 > I can easily change the XML parsing for whatever we agree.=20 >=20 > Regards, > Rod >=20 > > Hi Rod, > >=20 > > There is one thing I do not like about your proposed=20 > syntax: you use <ref > > name=3D"xxx"> is used in two different contexts, one when you=20 > define a bean > > that can serve as a reference, and once when you refer to=20 > such a bean from > > another bean. > > That's confusing. It would be better to define with for ex.=20 > an id attribute, > > and reference with a refid attribute: > >=20 > > <bean name=3D"foo" id=3D"foo"/> > > <bean name=3D"bar" id=3D"bar"> > > <property name=3D"thefoo" refid=3D"foo/> > > <property name=3D"moo">moo</property> > > </bean> > > <bean name=3Dbaz> > > <property name=3D"bla">blabla</property> > > </bean> > >=20 > > Note that bean bar can in turn be referenced from other=20 > beans, thanks to its > > id attribute. Bean baz cannot be referenced, because it=20 > doesn't have an id > > attribute. > >=20 > > A validating parser will not help you make sure that bean=20 > foo really exists > > when referenced, and neither will a DTD. > >=20 > > Isabelle >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 --=20 Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2003-05-28 19:13:27
|
RmluZSwgYXMgZmFyIGFzIEknbSBjb25jZXJuZWQgOi0pDQogDQpKdWVyZ2VuDQogDQoNCgktLS0t LVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogUm9kIEpvaG5zb24gW21haWx0 bzpyb2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb21dIA0KCUdlc2VuZGV0OiBNaSAyOC4wNS4yMDAz IDE4OjE2IA0KCUFuOiBqcC5wYXdsYWtAdGlzY2FsaS5mciANCglDYzogaXNhYmVsbGU7IHNwcmlu Z2ZyYW1ld29yay1kZXZlbG9wZXIgDQoJQmV0cmVmZjogUmU6IFJlOiBbU3ByaW5nZnJhbWV3b3Jr LWRldmVsb3Blcl0gU3ByaW5nIGJlYW4gZmFjdG9yeSBYTUwgZm9ybWF0DQoJDQoJDQoNCglMZXQn cyB0YWtlIHRoZSBmb2xsb3dpbmcgKHdoaWNoIEkgcG9zdGVkIGVhcmxpZXIgdG9kYXkpIGFzIHRo ZSBiYXNpcyBmb3INCglkaXNjdXNzaW9uLg0KCQ0KCUpQIGlzIGhhcHB5LiAgSXMgZXZlcnlvbmUg ZWxzZSBoYXBweSB3aXRoIHRoaXMsIG9yIGhhdmUgYW55IHN1Z2dlc3Rpb25zPw0KCQ0KCUkndmUg d3JpdHRlbiBhIERURCwgd2hpY2ggbWFrZXMgYXV0aG9yaW5nIGZhaXJseSBlYXN5IChhbHRob3Vn aCB0aGUgRWNsaXBzZQ0KCVhNTCBlZGl0b3IgaXNuJ3QgZW5mb3JjaW5nIGNvcnJlY3QgcmVmZXJl bmNpbmcpOg0KCQ0KCQ0KCTxiZWFuIGNsYXNzPSJNeUNsYXNzIiBpZD0iZm9vcyIgc2luZ2xldG9u PSJmYWxzZT4NCgk8cHJvcGVydHkgbmFtZT0iZm9vIj48dmFsdWU+Rk9PPC92YWx1ZT48L3Byb3Bl cnR5Pg0KCQ0KCTxwcm9wZXJ0eSBuYW1lPSJmb28zIj4NCgkgIDxyZWYgcmVmaWQ9ImZvbzMiLz4N Cgk8L3Byb3BlcnR5Pg0KCTxwcm9wZXJ0eSBuYW1lPSJmb280Ij4NCgkgICA8dmFsdWU+Rk9PNC4x PC92YWx1ZT4NCgkgICA8dmFsdWU+Rk9PNC4yPC92YWx1ZT4NCgkgICA8cmVmIHJlZmlkPSJmb280 LjMiLz4NCgk8L3Byb3BlcnR5Pg0KCTwvYmVhbj4NCgkNCglBbHdheXMgY29uc2lzdGVudDogYWx3 YXlzIGF0IGxlYXN0IG9uZSB2YWx1ZSBvciByZWYNCglzdWJlbGVtZW50IG9mIGEgcHJvcGVydHkg ZWx0OyA8dmFsdWU+IGNvbnRhaW5zIG9ubHkgdGV4dA0KCWRhdGE7IHJlZiBib2R5IG11c3QgYmUg ZW1wdHkuDQoJDQoJU2xpZ2h0bHkgbW9yZSB2ZXJib3NlLCBidXQgcHJvYmFibHkgZWFzaWVyIHRv IGF1dGhvciB3aXRoIGFuDQoJWE1MIGVkaXRvciAoZXZlbiB0aGUgYmFzaWMgRWNsaXBzZSBYTUwg ZWRpdG9yIEkgdXNlIG1vc3Qgb2YNCgl0aGUgdGltZSkuDQoJDQoJSSBkb24ndCBjYXJlIHdoZXRo ZXIgaXQncyBjYWxsZWQgdmFsdWUgb3IgZGF0YSwgb3IgYW55dGhpbmcNCgllbHNlLi4uYW55IGlk ZWFzPw0KCQ0KCVJlZ2FyZHMsDQoJUm9kDQoJDQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YubmV0IGVt YWlsIGlzIHNwb25zb3JlZCBieTogT2JqZWN0U3RvcmUuDQoJSWYgZmxhdHRlbmluZyBvdXQgQysr IG9yIEphdmEgY29kZSB0byBtYWtlIHlvdXIgYXBwbGljYXRpb24gZml0IGluIGENCglyZWxhdGlv bmFsIGRhdGFiYXNlIGlzIHBhaW5mdWwsIGRvbid0IGRvIGl0ISBDaGVjayBvdXQgT2JqZWN0U3Rv cmUuDQoJTm93IHBhcnQgb2YgUHJvZ3Jlc3MgU29mdHdhcmUuIGh0dHA6Ly93d3cub2JqZWN0c3Rv cmUubmV0L3NvdXJjZWZvcmdlDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0KCVNw cmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0cHM6Ly9s aXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVs b3Blcg0KCQ0KDQo= |
|
From: Rod J. <rod...@in...> - 2003-05-28 06:37:07
|
Juergen, > I agree that the new format makes sense. I didn't think about validating the XML before, but to my understanding you're right about the pitfalls. Keeping backwards compatibility for the moment makes sense, as each and every application context definition will be affected (admittedly in a straightforward way). Unless there are objections, I'll just check in the changes today. It's 100% backward compatible, so all existing tests pass, and the existing test suite covers all XML functionality. I'll have to introduce support in properties format as well, but that's really an enhancement, and doesn't affect existing use. > So besides the <ref> tag, there's a <value> tag now, for mixed collections. I guess it can also be used with a single value property like this: > > <property name="name"><value>Rod</value></property> > > Do you recommend this syntax for such properties too? Does it add any value in terms of validation? We should definitely stick to one recommended syntax, to avoid confusion. The new version accepts this, as well as the old form. I can't see great validation superiority in the more verbose form. I agree it's best to have only one approach. The only downside is the verbosity. I don't have any strong views on this verbosity/consistency tradeoff. The <value> syntax might be better in XML editors: you can see that you can have multiple choices of ref or value elements within a property. Also, Isabelle asked for a DTD. With the new format (overall) this should be more meaningful. > Regarding beans that expose CSV properties: I've already tried to clean many of the exposed bean properties within Spring (e.g. both commandClass and commandClassName, now only the former because of the ClassEditor), we should try to continue this for multiple value properties. I guess if choice doesn't add real value, it rather causes confusion. Yes. CSV properties should go. I'll start with the AOP stuff. > I'm not an XML expert, so I can't really help in terms of further improvements. Does anyone else have some thoughts on this? I think the "name" attribute may need to become "id" for validation, and my new "ref" element maybe should be "href"? Anyway, it's trivial to change the names of the XML, so I don't need to do this all at once. Regards, Rod |
|
From: JP P. <jp....@ti...> - 2003-05-28 06:56:21
|
Hi Rod, J=C3=BCrgen, I agree that formalism gains to be changed. Mapping properties and CSV looked always strange.=20 We can keep compatibility, but release 0.8=20 before fixing the new one would be a bad beginning. I'm not an XML expert, but worked with. I have some remarks: First, attributes "name", "class" and "singleton" are straightforward = and clean. The "beanref" as a boolean had poor value and changed the meaning of the = body! Avoiding this will be safer. The main isuue is with organizing the "value" part. Single values: If anything is allowed in the body, the meaning shall always be the = same. We can consider it will be the litteral value. My proposition will be: <property name=3D"xxx">yyy</bean> An alternative could be accepted: <property name=3D"xxx" value=3D"yyy"/> If the unique value is a bean reference, the body has to be empty: <property name=3D"xxx" ref=3D"zzz"/> Multiple values: I don't like=20 <property name=3D"jumble"> <ref name=3D"david"/> <value>literal</value> <ref name=3D"jenny" /> </property> The ref name=3D"xxx" has a poor value, we have two entities for only one = information. Because of different tag names. "ref" and "value" are both data in the = collection. I prefer such as: <property name=3D"jumble"> <data ref=3D"david"/> <data value=3D"literal"/> <data>literal2</data> <data ref=3D"jenny" /> </property> The "data" element could have a better name. So we could have a consistent definition, both in property and data: The value is either the body either the value attribute. The bean reference is always the ref attribute. The property element could only have in its body a text(the sole = litteral value) or a data elements collection. Regards, Jean-Pierre > -----Message d'origine----- > De : spr...@li...=20 > [mailto:spr...@li...] > De la part de j=C3=BCrgen h=C3=B6ller [werk3AT] > Envoy=C3=A9 : mercredi 28 mai 2003 07:33 > =C3=80 : Rod Johnson; spr...@li... > Objet : Re: [Springframework-developer] Spring bean factory XML format >=20 >=20 > Hi Rod, > =20 > I agree that the new format makes sense. I didn't think about=20 > validating the XML before, but to my understanding you're=20 > right about the pitfalls. Keeping backwards compatibility for=20 > the moment makes sense, as each and every application context=20 > definition will be affected (admittedly in a straightforward way). > =20 > So besides the <ref> tag, there's a <value> tag now, for=20 > mixed collections. I guess it can also be used with a single=20 > value property like this: > =20 > <property name=3D"name"><value>Rod</value></property> >=20 > Do you recommend this syntax for such properties too? Does it=20 > add any value in terms of validation? We should definitely=20 > stick to one recommended syntax, to avoid confusion. >=20 > Regarding beans that expose CSV properties: I've already=20 > tried to clean many of the exposed bean properties within=20 > Spring (e.g. both commandClass and commandClassName, now only=20 > the former because of the ClassEditor), we should try to=20 > continue this for multiple value properties. I guess if=20 > choice doesn't add real value, it rather causes confusion. > =20 > I'm not an XML expert, so I can't really help in terms of=20 > further improvements. Does anyone else have some thoughts on this? >=20 > Regards, > Juergen > =20 > =20 >=20 > -----Urspr=C3=BCngliche Nachricht-----=20 > Von: Rod Johnson [mailto:rod...@in...]=20 > Gesendet: Di 27.05.2003 22:19=20 > An: spr...@li...=20 > Cc:=20 > Betreff: Re: [Springframework-developer] Spring bean=20 > factory XML format > =09 > =09 >=20 > I've successfully prototyped this idea. > =09 > The new format looks like: > =09 > <bean name=3D"rod" class=3D"com.interface21.beans.TestBean"> > <property name=3D"name">Rod</property> > <property name=3D"age">32</property> > <property name=3D"friends"> > <ref name=3D"jenny"/> > <ref name=3D"david"/> > </property> > </bean> > =09 > <!-- > Try setting a collection property to a single value > --> > <bean name=3D"loner" class=3D"com.interface21.beans.TestBean"> > <property name=3D"name">loner</property> > <property name=3D"age">26</property> > <property name=3D"friends"> > <ref name=3D"david"/> > </property> > </bean> > =09 > <bean name=3D"jumble" > class=3D"com.interface21.beans.factory.xml.MixedCollectionBean"> > <property name=3D"jumble"> > <ref name=3D"david"/> > <value>literal</value> > <ref name=3D"jenny" /> > </property> > </bean> > =09 > I haven't dropped backward compatibility, or checked=20 > anything in. > =09 > If we agree this is an improvement, I'll check in these=20 > changes this week. I > guess I don't need to drop backward compatibility right=20 > now (beanRef), but > I think it should be dropped before 1.0. > =09 > I'm open to suggestions as to how to improve the XML further. > =09 > Regards, > Rod > =09 > ----- Original Message ----- > From: "Rod Johnson" <rod...@in...> > To: <spr...@li...> > Sent: Tuesday, May 27, 2003 6:20 PM > Subject: [Springframework-developer] Spring bean=20 > factory XML format > =09 > =09 > > Guys, > > > > I've just been thinking about an important potential issue. > > > > The current XML bean-reference syntax looks like: > > <property name=3D"foo" beanRef=3D"true">myFooBean</property> > > > > and, for lists etc (where a bean exposes a "CSV" property) > > <property name=3D"foos">a,b,c</property> > > > > While this syntax is concise, I think there are some=20 > issues we should > > discuss. > > > > a. It's hard to validate this. There's no validatable=20 > reference to another > > bean element id. It would be great if an XML editor=20 > could help us in this > > regard. > > b. It's inelegant. The use of the CDATA in the=20 > property element as a > string > > value or a reference (depending on the presence of an=20 > attribute) is a bit > > messy. > > c. The CSV format is really a hack, that I used once=20 > and then reused. Not > > only does the CSV make no sense to an XML editor=20 > (analogous to putting CSV > > data in an RDBMS), it places the onus on each class=20 > to parse the CSV and > > look up the necessary beans. This makes classes=20 > exposing CSV properties > > dependent on the owning BeanFactory, lessening the=20 > value of Spring's > > transparence. (Admittedly this is concealed in=20 > framework classes, so it > > doesn't really affect developers.) With the proposed=20 > new way, any > > application code could benefit from collection &=20 > array support. > > d. The new way would make it easy to write XSLT that=20 > showed relationships > > among Spring beans. This could be handy for=20 > generating documentation about > > Spring apps. > > > > So I've been thinking of changes along the lines of: > > > > <property name=3D"foo"> > > <ref name=3D"myFooBean" /> > > </property> > > > > and > > > > <property name=3D"foos"> > > <ref name=3D"a" /> > > <ref name=3D"b"/> > > <ref name=3D"c"/> > > </property> > > > > In this case the foos bean class would expose a=20 > Collection or array > > property, and the bean factory would no how to=20 > populate that from the > > runtime references. No dependence on the fw even for=20 > managing collection > > properties. > > > > I've already prototyped the idea of a <ref>=20 > subelement, and that was > pretty > > simple to implement. I'll experiment with=20 > collections tonight. > > > > Apart from changing XML files, the flow-on effect=20 > would mean that anything > > that exposed a CSV property (like the AOP interceptor=20 > proxy) would change > to > > exposing a Collection or array. > > > > What do you think? I'd like thoughts on the following=20 > questions: > > > > 1. Does everyone agree that this is worth doing? > > > > 2. To support a collection including literal values,=20 > should we introduce a > > new <value> element, meaning that simple properties=20 > would become > > <property name=3D"foo"><value>canConvert this=20 > string</value></property>. > More > > verbose, but more elegant. > > > > 3. Is there a way to help XML enforce the references=20 > automatically? E.g. > > change bean "name" to "id" and use a <href> instead=20 > of a <ref>? I haven't > > had a chance to explore this yet, but hopefully=20 > someone knows XML better > > than I do. > > > > 4. If this is worth doing, should we do it in 0.8,=20 > even if it delays the > > release (as it would)? On the one hand, we should=20 > try to release ASAP. On > > the other hand, this change would break all existing=20 > applications. Even > > though they'd be easy to fix, it might irritate=20 > users. So the choice is: > > - release now with a likely incompatible change in store > > - accept a delay > > > > We'd also have to introduce analogous support for the=20 > properties format, > > which couldn't benefit from XML capabilities. The=20 > properties format would > > probably change very little. > > > > Regards, > > Rod > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: ObjectStore. > > If flattening out C++ or Java code to make your=20 > application fit in a > > relational database is painful, don't do it! Check=20 > out ObjectStore. > > Now part of Progress Software.=20 > http://www.objectstore.net/sourceforge > >=20 > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > >=20 > > = https://lists.sourceforge.net/lists/listinfo/springframework-developer > =09 > =09 > =09 > =09 > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your=20 > application fit in a > relational database is painful, don't do it! Check out=20 > ObjectStore. > Now part of Progress Software.=20 > http://www.objectstore.net/sourceforge > =09 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > =09 > > = https://lists.sourceforge.net/lists/listinfo/springframework-developer > =09 >=20 > N=18HYX=E9=8A=B2un7+~V=20 > /u=EB=99=A9=CA=8Bj=C6=8Aj=D8=B7j=D8=9Djj vv > =17=E8=92=8B9r=D4=A2 > >=DA=BAJ y=CB=B6=EB=B2=8Bq =E7=AE=A6 G j) =D4=AE)~{ > zZz=D7=B9=DB=A2y =1B=E9=B6=A6=CF=96+=CA=AD=C7=A2+=EB=96=B3 ~ G >=20 |
|
From: Rod J. <rod...@in...> - 2003-05-28 07:16:18
|
I've checked in the changes (backward compatible for now). I'll tidy it up
after we decide on a definitive strategy.
JP, thanks for your comments on the XML. The XML certainly can be changed at
this stage if we agree on an alternative.
Regards,
Rod
----- Original Message -----
From: "JP Pawlak" <jp....@ti...>
To: "'jürgen höller [werk3AT]'" <jue...@we...>; "'Rod
Johnson'" <rod...@in...>;
<spr...@li...>
Sent: Wednesday, May 28, 2003 7:56 AM
Subject: RE : [Springframework-developer] Spring bean factory XML format
Hi Rod, Jürgen,
I agree that formalism gains to be changed.
Mapping properties and CSV looked always strange.
We can keep compatibility, but release 0.8
before fixing the new one would be a bad beginning.
I'm not an XML expert, but worked with. I have some remarks:
First, attributes "name", "class" and "singleton" are straightforward and
clean.
The "beanref" as a boolean had poor value and changed the meaning of the
body! Avoiding this will be safer.
The main isuue is with organizing the "value" part.
Single values:
If anything is allowed in the body, the meaning shall always be the same. We
can consider it will be the litteral value.
My proposition will be:
<property name="xxx">yyy</bean>
An alternative could be accepted:
<property name="xxx" value="yyy"/>
If the unique value is a bean reference, the body has to be empty:
<property name="xxx" ref="zzz"/>
Multiple values:
I don't like
<property name="jumble">
<ref name="david"/>
<value>literal</value>
<ref name="jenny" />
</property>
The ref name="xxx" has a poor value, we have two entities for only one
information.
Because of different tag names. "ref" and "value" are both data in the
collection.
I prefer such as:
<property name="jumble">
<data ref="david"/>
<data value="literal"/>
<data>literal2</data>
<data ref="jenny" />
</property>
The "data" element could have a better name.
So we could have a consistent definition, both in property and data:
The value is either the body either the value attribute.
The bean reference is always the ref attribute.
The property element could only have in its body a text(the sole litteral
value) or a data elements collection.
Regards,
Jean-Pierre
> -----Message d'origine-----
> De : spr...@li...
> [mailto:spr...@li...]
> De la part de jürgen höller [werk3AT]
> Envoyé : mercredi 28 mai 2003 07:33
> À : Rod Johnson; spr...@li...
> Objet : Re: [Springframework-developer] Spring bean factory XML format
>
>
> Hi Rod,
>
> I agree that the new format makes sense. I didn't think about
> validating the XML before, but to my understanding you're
> right about the pitfalls. Keeping backwards compatibility for
> the moment makes sense, as each and every application context
> definition will be affected (admittedly in a straightforward way).
>
> So besides the <ref> tag, there's a <value> tag now, for
> mixed collections. I guess it can also be used with a single
> value property like this:
>
> <property name="name"><value>Rod</value></property>
>
> Do you recommend this syntax for such properties too? Does it
> add any value in terms of validation? We should definitely
> stick to one recommended syntax, to avoid confusion.
>
> Regarding beans that expose CSV properties: I've already
> tried to clean many of the exposed bean properties within
> Spring (e.g. both commandClass and commandClassName, now only
> the former because of the ClassEditor), we should try to
> continue this for multiple value properties. I guess if
> choice doesn't add real value, it rather causes confusion.
>
> I'm not an XML expert, so I can't really help in terms of
> further improvements. Does anyone else have some thoughts on this?
>
> Regards,
> Juergen
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rod Johnson [mailto:rod...@in...]
> Gesendet: Di 27.05.2003 22:19
> An: spr...@li...
> Cc:
> Betreff: Re: [Springframework-developer] Spring bean
> factory XML format
>
>
>
> I've successfully prototyped this idea.
>
> The new format looks like:
>
> <bean name="rod" class="com.interface21.beans.TestBean">
> <property name="name">Rod</property>
> <property name="age">32</property>
> <property name="friends">
> <ref name="jenny"/>
> <ref name="david"/>
> </property>
> </bean>
>
> <!--
> Try setting a collection property to a single value
> -->
> <bean name="loner" class="com.interface21.beans.TestBean">
> <property name="name">loner</property>
> <property name="age">26</property>
> <property name="friends">
> <ref name="david"/>
> </property>
> </bean>
>
> <bean name="jumble"
> class="com.interface21.beans.factory.xml.MixedCollectionBean">
> <property name="jumble">
> <ref name="david"/>
> <value>literal</value>
> <ref name="jenny" />
> </property>
> </bean>
>
> I haven't dropped backward compatibility, or checked
> anything in.
>
> If we agree this is an improvement, I'll check in these
> changes this week. I
> guess I don't need to drop backward compatibility right
> now (beanRef), but
> I think it should be dropped before 1.0.
>
> I'm open to suggestions as to how to improve the XML further.
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "Rod Johnson" <rod...@in...>
> To: <spr...@li...>
> Sent: Tuesday, May 27, 2003 6:20 PM
> Subject: [Springframework-developer] Spring bean
> factory XML format
>
>
> > Guys,
> >
> > I've just been thinking about an important potential issue.
> >
> > The current XML bean-reference syntax looks like:
> > <property name="foo" beanRef="true">myFooBean</property>
> >
> > and, for lists etc (where a bean exposes a "CSV" property)
> > <property name="foos">a,b,c</property>
> >
> > While this syntax is concise, I think there are some
> issues we should
> > discuss.
> >
> > a. It's hard to validate this. There's no validatable
> reference to another
> > bean element id. It would be great if an XML editor
> could help us in this
> > regard.
> > b. It's inelegant. The use of the CDATA in the
> property element as a
> string
> > value or a reference (depending on the presence of an
> attribute) is a bit
> > messy.
> > c. The CSV format is really a hack, that I used once
> and then reused. Not
> > only does the CSV make no sense to an XML editor
> (analogous to putting CSV
> > data in an RDBMS), it places the onus on each class
> to parse the CSV and
> > look up the necessary beans. This makes classes
> exposing CSV properties
> > dependent on the owning BeanFactory, lessening the
> value of Spring's
> > transparence. (Admittedly this is concealed in
> framework classes, so it
> > doesn't really affect developers.) With the proposed
> new way, any
> > application code could benefit from collection &
> array support.
> > d. The new way would make it easy to write XSLT that
> showed relationships
> > among Spring beans. This could be handy for
> generating documentation about
> > Spring apps.
> >
> > So I've been thinking of changes along the lines of:
> >
> > <property name="foo">
> > <ref name="myFooBean" />
> > </property>
> >
> > and
> >
> > <property name="foos">
> > <ref name="a" />
> > <ref name="b"/>
> > <ref name="c"/>
> > </property>
> >
> > In this case the foos bean class would expose a
> Collection or array
> > property, and the bean factory would no how to
> populate that from the
> > runtime references. No dependence on the fw even for
> managing collection
> > properties.
> >
> > I've already prototyped the idea of a <ref>
> subelement, and that was
> pretty
> > simple to implement. I'll experiment with
> collections tonight.
> >
> > Apart from changing XML files, the flow-on effect
> would mean that anything
> > that exposed a CSV property (like the AOP interceptor
> proxy) would change
> to
> > exposing a Collection or array.
> >
> > What do you think? I'd like thoughts on the following
> questions:
> >
> > 1. Does everyone agree that this is worth doing?
> >
> > 2. To support a collection including literal values,
> should we introduce a
> > new <value> element, meaning that simple properties
> would become
> > <property name="foo"><value>canConvert this
> string</value></property>.
> More
> > verbose, but more elegant.
> >
> > 3. Is there a way to help XML enforce the references
> automatically? E.g.
> > change bean "name" to "id" and use a <href> instead
> of a <ref>? I haven't
> > had a chance to explore this yet, but hopefully
> someone knows XML better
> > than I do.
> >
> > 4. If this is worth doing, should we do it in 0.8,
> even if it delays the
> > release (as it would)? On the one hand, we should
> try to release ASAP. On
> > the other hand, this change would break all existing
> applications. Even
> > though they'd be easy to fix, it might irritate
> users. So the choice is:
> > - release now with a likely incompatible change in store
> > - accept a delay
> >
> > We'd also have to introduce analogous support for the
> properties format,
> > which couldn't benefit from XML capabilities. The
> properties format would
> > probably change very little.
> >
> > Regards,
> > Rod
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your
> application fit in a
> > relational database is painful, don't do it! Check
> out ObjectStore.
> > Now part of Progress Software.
> http://www.objectstore.net/sourceforge
> >
> _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> >
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your
> application fit in a
> relational database is painful, don't do it! Check out
> ObjectStore.
> Now part of Progress Software.
> http://www.objectstore.net/sourceforge
>
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> NHYX銲un7+~V
> /u뙩ʋjƊjطj؝jj vv
> 蒋9rԢ
> >ںJ y˶벋q 箦 G j) Ԯ)~{
> zZzۢy 鶦ϖ+ʭǢ+떳 ~ G
>
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Isabelle M. <isa...@me...> - 2003-05-28 08:10:50
|
Hi Rod, There is one thing I do not like about your proposed syntax: you use <ref n= ame=3D"xxx"> is used in two different contexts, one when you define a bean = that can serve as a reference, and once when you refer to such a bean from = another bean. That's confusing. It would be better to define with for ex. an id attribute= , and reference with a refid attribute: <bean name=3D"foo" id=3D"foo"/> <bean name=3D"bar" id=3D"bar"> <property name=3D"thefoo" refid=3D"foo/> <property name=3D"moo">moo</property> </bean> <bean name=3Dbaz> <property name=3D"bla">blabla</property> </bean> Note that bean bar can in turn be referenced from other beans, thanks to it= s id attribute. Bean baz cannot be referenced, because it doesn't have an i= d attribute. A validating parser will not help you make sure that bean foo really exists= when referenced, and neither will a DTD. Isabelle On Wed, May 28, 2003 at 08:16:10AM +0100, Rod Johnson wrote: > I've checked in the changes (backward compatible for now). I'll tidy it = up > after we decide on a definitive strategy. >=20 > JP, thanks for your comments on the XML. The XML certainly can be changed= at > this stage if we agree on an alternative. >=20 > Regards, > Rod >=20 > ----- Original Message ----- > From: "JP Pawlak" <jp....@ti...> > To: "'j=C3=BCrgen h=C3=B6ller [werk3AT]'" <jue...@we...>; = "'Rod > Johnson'" <rod...@in...>; > <spr...@li...> > Sent: Wednesday, May 28, 2003 7:56 AM > Subject: RE : [Springframework-developer] Spring bean factory XML format >=20 >=20 > Hi Rod, J=C3=BCrgen, >=20 > I agree that formalism gains to be changed. > Mapping properties and CSV looked always strange. > We can keep compatibility, but release 0.8 > before fixing the new one would be a bad beginning. >=20 > I'm not an XML expert, but worked with. I have some remarks: >=20 > First, attributes "name", "class" and "singleton" are straightforward and > clean. > The "beanref" as a boolean had poor value and changed the meaning of the > body! Avoiding this will be safer. > The main isuue is with organizing the "value" part. >=20 > Single values: > If anything is allowed in the body, the meaning shall always be the same.= We > can consider it will be the litteral value. > My proposition will be: > <property name=3D"xxx">yyy</bean> > An alternative could be accepted: > <property name=3D"xxx" value=3D"yyy"/> >=20 > If the unique value is a bean reference, the body has to be empty: > <property name=3D"xxx" ref=3D"zzz"/> >=20 > Multiple values: > I don't like > <property name=3D"jumble"> > <ref name=3D"david"/> > <value>literal</value> > <ref name=3D"jenny" /> > </property> >=20 > The ref name=3D"xxx" has a poor value, we have two entities for only one > information. >=20 > Because of different tag names. "ref" and "value" are both data in the > collection. > I prefer such as: > <property name=3D"jumble"> > <data ref=3D"david"/> > <data value=3D"literal"/> > <data>literal2</data> > <data ref=3D"jenny" /> > </property> >=20 > The "data" element could have a better name. >=20 > So we could have a consistent definition, both in property and data: > The value is either the body either the value attribute. > The bean reference is always the ref attribute. >=20 > The property element could only have in its body a text(the sole litteral > value) or a data elements collection. >=20 >=20 > Regards, > Jean-Pierre >=20 >=20 > > -----Message d'origine----- > > De : spr...@li... > > [mailto:spr...@li...] > > De la part de j=C3=BCrgen h=C3=B6ller [werk3AT] > > Envoy=C3=A9 : mercredi 28 mai 2003 07:33 > > =C3=80 : Rod Johnson; spr...@li... > > Objet : Re: [Springframework-developer] Spring bean factory XML format > > > > > > Hi Rod, > > > > I agree that the new format makes sense. I didn't think about > > validating the XML before, but to my understanding you're > > right about the pitfalls. Keeping backwards compatibility for > > the moment makes sense, as each and every application context > > definition will be affected (admittedly in a straightforward way). > > > > So besides the <ref> tag, there's a <value> tag now, for > > mixed collections. I guess it can also be used with a single > > value property like this: > > > > <property name=3D"name"><value>Rod</value></property> > > > > Do you recommend this syntax for such properties too? Does it > > add any value in terms of validation? We should definitely > > stick to one recommended syntax, to avoid confusion. > > > > Regarding beans that expose CSV properties: I've already > > tried to clean many of the exposed bean properties within > > Spring (e.g. both commandClass and commandClassName, now only > > the former because of the ClassEditor), we should try to > > continue this for multiple value properties. I guess if > > choice doesn't add real value, it rather causes confusion. > > > > I'm not an XML expert, so I can't really help in terms of > > further improvements. Does anyone else have some thoughts on this? > > > > Regards, > > Juergen > > > > > > > > -----Urspr=C3=BCngliche Nachricht----- > > Von: Rod Johnson [mailto:rod...@in...] > > Gesendet: Di 27.05.2003 22:19 > > An: spr...@li... > > Cc: > > Betreff: Re: [Springframework-developer] Spring bean > > factory XML format > > > > > > > > I've successfully prototyped this idea. > > > > The new format looks like: > > > > <bean name=3D"rod" class=3D"com.interface21.beans.TestBean"> > > <property name=3D"name">Rod</property> > > <property name=3D"age">32</property> > > <property name=3D"friends"> > > <ref name=3D"jenny"/> > > <ref name=3D"david"/> > > </property> > > </bean> > > > > <!-- > > Try setting a collection property to a single value > > --> > > <bean name=3D"loner" class=3D"com.interface21.beans.TestBean"> > > <property name=3D"name">loner</property> > > <property name=3D"age">26</property> > > <property name=3D"friends"> > > <ref name=3D"david"/> > > </property> > > </bean> > > > > <bean name=3D"jumble" > > class=3D"com.interface21.beans.factory.xml.MixedCollectionBean"> > > <property name=3D"jumble"> > > <ref name=3D"david"/> > > <value>literal</value> > > <ref name=3D"jenny" /> > > </property> > > </bean> > > > > I haven't dropped backward compatibility, or checked > > anything in. > > > > If we agree this is an improvement, I'll check in these > > changes this week. I > > guess I don't need to drop backward compatibility right > > now (beanRef), but > > I think it should be dropped before 1.0. > > > > I'm open to suggestions as to how to improve the XML further. > > > > Regards, > > Rod > > > > ----- Original Message ----- > > From: "Rod Johnson" <rod...@in...> > > To: <spr...@li...> > > Sent: Tuesday, May 27, 2003 6:20 PM > > Subject: [Springframework-developer] Spring bean > > factory XML format > > > > > > > Guys, > > > > > > I've just been thinking about an important potential issue. > > > > > > The current XML bean-reference syntax looks like: > > > <property name=3D"foo" beanRef=3D"true">myFooBean</property> > > > > > > and, for lists etc (where a bean exposes a "CSV" property) > > > <property name=3D"foos">a,b,c</property> > > > > > > While this syntax is concise, I think there are some > > issues we should > > > discuss. > > > > > > a. It's hard to validate this. There's no validatable > > reference to another > > > bean element id. It would be great if an XML editor > > could help us in this > > > regard. > > > b. It's inelegant. The use of the CDATA in the > > property element as a > > string > > > value or a reference (depending on the presence of an > > attribute) is a bit > > > messy. > > > c. The CSV format is really a hack, that I used once > > and then reused. Not > > > only does the CSV make no sense to an XML editor > > (analogous to putting CSV > > > data in an RDBMS), it places the onus on each class > > to parse the CSV and > > > look up the necessary beans. This makes classes > > exposing CSV properties > > > dependent on the owning BeanFactory, lessening the > > value of Spring's > > > transparence. (Admittedly this is concealed in > > framework classes, so it > > > doesn't really affect developers.) With the proposed > > new way, any > > > application code could benefit from collection & > > array support. > > > d. The new way would make it easy to write XSLT that > > showed relationships > > > among Spring beans. This could be handy for > > generating documentation about > > > Spring apps. > > > > > > So I've been thinking of changes along the lines of: > > > > > > <property name=3D"foo"> > > > <ref name=3D"myFooBean" /> > > > </property> > > > > > > and > > > > > > <property name=3D"foos"> > > > <ref name=3D"a" /> > > > <ref name=3D"b"/> > > > <ref name=3D"c"/> > > > </property> > > > > > > In this case the foos bean class would expose a > > Collection or array > > > property, and the bean factory would no how to > > populate that from the > > > runtime references. No dependence on the fw even for > > managing collection > > > properties. > > > > > > I've already prototyped the idea of a <ref> > > subelement, and that was > > pretty > > > simple to implement. I'll experiment with > > collections tonight. > > > > > > Apart from changing XML files, the flow-on effect > > would mean that anything > > > that exposed a CSV property (like the AOP interceptor > > proxy) would change > > to > > > exposing a Collection or array. > > > > > > What do you think? I'd like thoughts on the following > > questions: > > > > > > 1. Does everyone agree that this is worth doing? > > > > > > 2. To support a collection including literal values, > > should we introduce a > > > new <value> element, meaning that simple properties > > would become > > > <property name=3D"foo"><value>canConvert this > > string</value></property>. > > More > > > verbose, but more elegant. > > > > > > 3. Is there a way to help XML enforce the references > > automatically? E.g. > > > change bean "name" to "id" and use a <href> instead > > of a <ref>? I haven't > > > had a chance to explore this yet, but hopefully > > someone knows XML better > > > than I do. > > > > > > 4. If this is worth doing, should we do it in 0.8, > > even if it delays the > > > release (as it would)? On the one hand, we should > > try to release ASAP. On > > > the other hand, this change would break all existing > > applications. Even > > > though they'd be easy to fix, it might irritate > > users. So the choice is: > > > - release now with a likely incompatible change in store > > > - accept a delay > > > > > > We'd also have to introduce analogous support for the > > properties format, > > > which couldn't benefit from XML capabilities. The > > properties format would > > > probably change very little. > > > > > > Regards, > > > Rod > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: ObjectStore. > > > If flattening out C++ or Java code to make your > > application fit in a > > > relational database is painful, don't do it! Check > > out ObjectStore. > > > Now part of Progress Software. > > http://www.objectstore.net/sourceforge > > > > > _______________________________________________ > > > Springframework-developer mailing list > > > Spr...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: ObjectStore. > > If flattening out C++ or Java code to make your > > application fit in a > > relational database is painful, don't do it! Check out > > ObjectStore. > > Now part of Progress Software. > > http://www.objectstore.net/sourceforge > > > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > N=18HYX=E9=8A=B2un7+~V > > /u=EB=99=A9=CA=8Bj=C6=8Aj=D8=B7j=D8=9Djj vv > > =17=E8=92=8B9r=D4=A2 > > >=DA=BAJ y=CB=B6=EB=B2=8Bq =E7=AE=A6 G j) =D4=AE)~{ > > zZz=D7=B9=DB=A2y =1B=E9=B6=A6=CF=96+=CA=AD=C7=A2+=EB=96=B3 ~ G > > >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 --=20 Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: Rod J. <rod...@in...> - 2003-05-28 08:23:05
|
Why not replace "name" attribute with "id"? Why do we need a name attribute? ----- Original Message ----- From: "Isabelle Muszynski" <isa...@me...> To: "Rod Johnson" <rod...@in...> Cc: <spr...@li...> Sent: Wednesday, May 28, 2003 8:43 AM Subject: Re: [Springframework-developer] Spring bean factory XML format Hi Rod, There is one thing I do not like about your proposed syntax: you use <ref name="xxx"> is used in two different contexts, one when you define a bean that can serve as a reference, and once when you refer to such a bean from another bean. That's confusing. It would be better to define with for ex. an id attribute, and reference with a refid attribute: <bean name="foo" id="foo"/> <bean name="bar" id="bar"> <property name="thefoo" refid="foo/> <property name="moo">moo</property> </bean> <bean name=baz> <property name="bla">blabla</property> </bean> Note that bean bar can in turn be referenced from other beans, thanks to its id attribute. Bean baz cannot be referenced, because it doesn't have an id attribute. A validating parser will not help you make sure that bean foo really exists when referenced, and neither will a DTD. Isabelle On Wed, May 28, 2003 at 08:16:10AM +0100, Rod Johnson wrote: > I've checked in the changes (backward compatible for now). I'll tidy it up > after we decide on a definitive strategy. > > JP, thanks for your comments on the XML. The XML certainly can be changed at > this stage if we agree on an alternative. > > Regards, > Rod > > ----- Original Message ----- > From: "JP Pawlak" <jp....@ti...> > To: "'jürgen höller [werk3AT]'" <jue...@we...>; "'Rod > Johnson'" <rod...@in...>; > <spr...@li...> > Sent: Wednesday, May 28, 2003 7:56 AM > Subject: RE : [Springframework-developer] Spring bean factory XML format > > > Hi Rod, Jürgen, > > I agree that formalism gains to be changed. > Mapping properties and CSV looked always strange. > We can keep compatibility, but release 0.8 > before fixing the new one would be a bad beginning. > > I'm not an XML expert, but worked with. I have some remarks: > > First, attributes "name", "class" and "singleton" are straightforward and > clean. > The "beanref" as a boolean had poor value and changed the meaning of the > body! Avoiding this will be safer. > The main isuue is with organizing the "value" part. > > Single values: > If anything is allowed in the body, the meaning shall always be the same. We > can consider it will be the litteral value. > My proposition will be: > <property name="xxx">yyy</bean> > An alternative could be accepted: > <property name="xxx" value="yyy"/> > > If the unique value is a bean reference, the body has to be empty: > <property name="xxx" ref="zzz"/> > > Multiple values: > I don't like > <property name="jumble"> > <ref name="david"/> > <value>literal</value> > <ref name="jenny" /> > </property> > > The ref name="xxx" has a poor value, we have two entities for only one > information. > > Because of different tag names. "ref" and "value" are both data in the > collection. > I prefer such as: > <property name="jumble"> > <data ref="david"/> > <data value="literal"/> > <data>literal2</data> > <data ref="jenny" /> > </property> > > The "data" element could have a better name. > > So we could have a consistent definition, both in property and data: > The value is either the body either the value attribute. > The bean reference is always the ref attribute. > > The property element could only have in its body a text(the sole litteral > value) or a data elements collection. > > > Regards, > Jean-Pierre > > > > -----Message d'origine----- > > De : spr...@li... > > [mailto:spr...@li...] > > De la part de jürgen höller [werk3AT] > > Envoyé : mercredi 28 mai 2003 07:33 > > À : Rod Johnson; spr...@li... > > Objet : Re: [Springframework-developer] Spring bean factory XML format > > > > > > Hi Rod, > > > > I agree that the new format makes sense. I didn't think about > > validating the XML before, but to my understanding you're > > right about the pitfalls. Keeping backwards compatibility for > > the moment makes sense, as each and every application context > > definition will be affected (admittedly in a straightforward way). > > > > So besides the <ref> tag, there's a <value> tag now, for > > mixed collections. I guess it can also be used with a single > > value property like this: > > > > <property name="name"><value>Rod</value></property> > > > > Do you recommend this syntax for such properties too? Does it > > add any value in terms of validation? We should definitely > > stick to one recommended syntax, to avoid confusion. > > > > Regarding beans that expose CSV properties: I've already > > tried to clean many of the exposed bean properties within > > Spring (e.g. both commandClass and commandClassName, now only > > the former because of the ClassEditor), we should try to > > continue this for multiple value properties. I guess if > > choice doesn't add real value, it rather causes confusion. > > > > I'm not an XML expert, so I can't really help in terms of > > further improvements. Does anyone else have some thoughts on this? > > > > Regards, > > Juergen > > > > > > > > -----Ursprüngliche Nachricht----- > > Von: Rod Johnson [mailto:rod...@in...] > > Gesendet: Di 27.05.2003 22:19 > > An: spr...@li... > > Cc: > > Betreff: Re: [Springframework-developer] Spring bean > > factory XML format > > > > > > > > I've successfully prototyped this idea. > > > > The new format looks like: > > > > <bean name="rod" class="com.interface21.beans.TestBean"> > > <property name="name">Rod</property> > > <property name="age">32</property> > > <property name="friends"> > > <ref name="jenny"/> > > <ref name="david"/> > > </property> > > </bean> > > > > <!-- > > Try setting a collection property to a single value > > --> > > <bean name="loner" class="com.interface21.beans.TestBean"> > > <property name="name">loner</property> > > <property name="age">26</property> > > <property name="friends"> > > <ref name="david"/> > > </property> > > </bean> > > > > <bean name="jumble" > > class="com.interface21.beans.factory.xml.MixedCollectionBean"> > > <property name="jumble"> > > <ref name="david"/> > > <value>literal</value> > > <ref name="jenny" /> > > </property> > > </bean> > > > > I haven't dropped backward compatibility, or checked > > anything in. > > > > If we agree this is an improvement, I'll check in these > > changes this week. I > > guess I don't need to drop backward compatibility right > > now (beanRef), but > > I think it should be dropped before 1.0. > > > > I'm open to suggestions as to how to improve the XML further. > > > > Regards, > > Rod > > > > ----- Original Message ----- > > From: "Rod Johnson" <rod...@in...> > > To: <spr...@li...> > > Sent: Tuesday, May 27, 2003 6:20 PM > > Subject: [Springframework-developer] Spring bean > > factory XML format > > > > > > > Guys, > > > > > > I've just been thinking about an important potential issue. > > > > > > The current XML bean-reference syntax looks like: > > > <property name="foo" beanRef="true">myFooBean</property> > > > > > > and, for lists etc (where a bean exposes a "CSV" property) > > > <property name="foos">a,b,c</property> > > > > > > While this syntax is concise, I think there are some > > issues we should > > > discuss. > > > > > > a. It's hard to validate this. There's no validatable > > reference to another > > > bean element id. It would be great if an XML editor > > could help us in this > > > regard. > > > b. It's inelegant. The use of the CDATA in the > > property element as a > > string > > > value or a reference (depending on the presence of an > > attribute) is a bit > > > messy. > > > c. The CSV format is really a hack, that I used once > > and then reused. Not > > > only does the CSV make no sense to an XML editor > > (analogous to putting CSV > > > data in an RDBMS), it places the onus on each class > > to parse the CSV and > > > look up the necessary beans. This makes classes > > exposing CSV properties > > > dependent on the owning BeanFactory, lessening the > > value of Spring's > > > transparence. (Admittedly this is concealed in > > framework classes, so it > > > doesn't really affect developers.) With the proposed > > new way, any > > > application code could benefit from collection & > > array support. > > > d. The new way would make it easy to write XSLT that > > showed relationships > > > among Spring beans. This could be handy for > > generating documentation about > > > Spring apps. > > > > > > So I've been thinking of changes along the lines of: > > > > > > <property name="foo"> > > > <ref name="myFooBean" /> > > > </property> > > > > > > and > > > > > > <property name="foos"> > > > <ref name="a" /> > > > <ref name="b"/> > > > <ref name="c"/> > > > </property> > > > > > > In this case the foos bean class would expose a > > Collection or array > > > property, and the bean factory would no how to > > populate that from the > > > runtime references. No dependence on the fw even for > > managing collection > > > properties. > > > > > > I've already prototyped the idea of a <ref> > > subelement, and that was > > pretty > > > simple to implement. I'll experiment with > > collections tonight. > > > > > > Apart from changing XML files, the flow-on effect > > would mean that anything > > > that exposed a CSV property (like the AOP interceptor > > proxy) would change > > to > > > exposing a Collection or array. > > > > > > What do you think? I'd like thoughts on the following > > questions: > > > > > > 1. Does everyone agree that this is worth doing? > > > > > > 2. To support a collection including literal values, > > should we introduce a > > > new <value> element, meaning that simple properties > > would become > > > <property name="foo"><value>canConvert this > > string</value></property>. > > More > > > verbose, but more elegant. > > > > > > 3. Is there a way to help XML enforce the references > > automatically? E.g. > > > change bean "name" to "id" and use a <href> instead > > of a <ref>? I haven't > > > had a chance to explore this yet, but hopefully > > someone knows XML better > > > than I do. > > > > > > 4. If this is worth doing, should we do it in 0.8, > > even if it delays the > > > release (as it would)? On the one hand, we should > > try to release ASAP. On > > > the other hand, this change would break all existing > > applications. Even > > > though they'd be easy to fix, it might irritate > > users. So the choice is: > > > - release now with a likely incompatible change in store > > > - accept a delay > > > > > > We'd also have to introduce analogous support for the > > properties format, > > > which couldn't benefit from XML capabilities. The > > properties format would > > > probably change very little. > > > > > > Regards, > > > Rod > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: ObjectStore. > > > If flattening out C++ or Java code to make your > > application fit in a > > > relational database is painful, don't do it! Check > > out ObjectStore. > > > Now part of Progress Software. > > http://www.objectstore.net/sourceforge > > > > > _______________________________________________ > > > Springframework-developer mailing list > > > Spr...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: ObjectStore. > > If flattening out C++ or Java code to make your > > application fit in a > > relational database is painful, don't do it! Check out > > ObjectStore. > > Now part of Progress Software. > > http://www.objectstore.net/sourceforge > > > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > NHYX銲un7+~V > > /u뙩ʋjƊjطj؝jj vv > > 蒋9rԢ > > >ںJ y˶벋q 箦 G j) Ԯ)~{ > > zZzۢy 鶦ϖ+ʭǢ+떳 ~ G > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: Isabelle M. <isa...@me...> - 2003-05-28 08:59:54
|
Hi Rod, You're absolutely right, the name attribute can go away. Isabelle On Wed, May 28, 2003 at 09:22:04AM +0100, Rod Johnson wrote: > Why not replace "name" attribute with "id"? Why do we need a name attribu= te? >=20 > ----- Original Message ----- > From: "Isabelle Muszynski" <isa...@me...> > To: "Rod Johnson" <rod...@in...> > Cc: <spr...@li...> > Sent: Wednesday, May 28, 2003 8:43 AM > Subject: Re: [Springframework-developer] Spring bean factory XML format >=20 >=20 > Hi Rod, >=20 > There is one thing I do not like about your proposed syntax: you use <ref > name=3D"xxx"> is used in two different contexts, one when you define a be= an > that can serve as a reference, and once when you refer to such a bean from > another bean. > That's confusing. It would be better to define with for ex. an id attribu= te, > and reference with a refid attribute: >=20 > <bean name=3D"foo" id=3D"foo"/> > <bean name=3D"bar" id=3D"bar"> > <property name=3D"thefoo" refid=3D"foo/> > <property name=3D"moo">moo</property> > </bean> > <bean name=3Dbaz> > <property name=3D"bla">blabla</property> > </bean> >=20 > Note that bean bar can in turn be referenced from other beans, thanks to = its > id attribute. Bean baz cannot be referenced, because it doesn't have an id > attribute. >=20 > A validating parser will not help you make sure that bean foo really exis= ts > when referenced, and neither will a DTD. >=20 > Isabelle >=20 >=20 > On Wed, May 28, 2003 at 08:16:10AM +0100, Rod Johnson wrote: > > I've checked in the changes (backward compatible for now). I'll tidy it > up > > after we decide on a definitive strategy. > > > > JP, thanks for your comments on the XML. The XML certainly can be chang= ed > at > > this stage if we agree on an alternative. > > > > Regards, > > Rod > > > > ----- Original Message ----- > > From: "JP Pawlak" <jp....@ti...> > > To: "'j=C3=BCrgen h=C3=B6ller [werk3AT]'" <jue...@we...>= ; "'Rod > > Johnson'" <rod...@in...>; > > <spr...@li...> > > Sent: Wednesday, May 28, 2003 7:56 AM > > Subject: RE : [Springframework-developer] Spring bean factory XML format > > > > > > Hi Rod, J=C3=BCrgen, > > > > I agree that formalism gains to be changed. > > Mapping properties and CSV looked always strange. > > We can keep compatibility, but release 0.8 > > before fixing the new one would be a bad beginning. > > > > I'm not an XML expert, but worked with. I have some remarks: > > > > First, attributes "name", "class" and "singleton" are straightforward a= nd > > clean. > > The "beanref" as a boolean had poor value and changed the meaning of the > > body! Avoiding this will be safer. > > The main isuue is with organizing the "value" part. > > > > Single values: > > If anything is allowed in the body, the meaning shall always be the sam= e. > We > > can consider it will be the litteral value. > > My proposition will be: > > <property name=3D"xxx">yyy</bean> > > An alternative could be accepted: > > <property name=3D"xxx" value=3D"yyy"/> > > > > If the unique value is a bean reference, the body has to be empty: > > <property name=3D"xxx" ref=3D"zzz"/> > > > > Multiple values: > > I don't like > > <property name=3D"jumble"> > > <ref name=3D"david"/> > > <value>literal</value> > > <ref name=3D"jenny" /> > > </property> > > > > The ref name=3D"xxx" has a poor value, we have two entities for only one > > information. > > > > Because of different tag names. "ref" and "value" are both data in the > > collection. > > I prefer such as: > > <property name=3D"jumble"> > > <data ref=3D"david"/> > > <data value=3D"literal"/> > > <data>literal2</data> > > <data ref=3D"jenny" /> > > </property> > > > > The "data" element could have a better name. > > > > So we could have a consistent definition, both in property and data: > > The value is either the body either the value attribute. > > The bean reference is always the ref attribute. > > > > The property element could only have in its body a text(the sole litter= al > > value) or a data elements collection. > > > > > > Regards, > > Jean-Pierre > > > > > > > -----Message d'origine----- > > > De : spr...@li... > > > [mailto:spr...@li...] > > > De la part de j=C3=BCrgen h=C3=B6ller [werk3AT] > > > Envoy=C3=A9 : mercredi 28 mai 2003 07:33 > > > =C3=80 : Rod Johnson; spr...@li... > > > Objet : Re: [Springframework-developer] Spring bean factory XML format > > > > > > > > > Hi Rod, > > > > > > I agree that the new format makes sense. I didn't think about > > > validating the XML before, but to my understanding you're > > > right about the pitfalls. Keeping backwards compatibility for > > > the moment makes sense, as each and every application context > > > definition will be affected (admittedly in a straightforward way). > > > > > > So besides the <ref> tag, there's a <value> tag now, for > > > mixed collections. I guess it can also be used with a single > > > value property like this: > > > > > > <property name=3D"name"><value>Rod</value></property> > > > > > > Do you recommend this syntax for such properties too? Does it > > > add any value in terms of validation? We should definitely > > > stick to one recommended syntax, to avoid confusion. > > > > > > Regarding beans that expose CSV properties: I've already > > > tried to clean many of the exposed bean properties within > > > Spring (e.g. both commandClass and commandClassName, now only > > > the former because of the ClassEditor), we should try to > > > continue this for multiple value properties. I guess if > > > choice doesn't add real value, it rather causes confusion. > > > > > > I'm not an XML expert, so I can't really help in terms of > > > further improvements. Does anyone else have some thoughts on this? > > > > > > Regards, > > > Juergen > > > > > > > > > > > > -----Urspr=C3=BCngliche Nachricht----- > > > Von: Rod Johnson [mailto:rod...@in...] > > > Gesendet: Di 27.05.2003 22:19 > > > An: spr...@li... > > > Cc: > > > Betreff: Re: [Springframework-developer] Spring bean > > > factory XML format > > > > > > > > > > > > I've successfully prototyped this idea. > > > > > > The new format looks like: > > > > > > <bean name=3D"rod" class=3D"com.interface21.beans.TestBean"> > > > <property name=3D"name">Rod</property> > > > <property name=3D"age">32</property> > > > <property name=3D"friends"> > > > <ref name=3D"jenny"/> > > > <ref name=3D"david"/> > > > </property> > > > </bean> > > > > > > <!-- > > > Try setting a collection property to a single value > > > --> > > > <bean name=3D"loner" class=3D"com.interface21.beans.TestBean"> > > > <property name=3D"name">loner</property> > > > <property name=3D"age">26</property> > > > <property name=3D"friends"> > > > <ref name=3D"david"/> > > > </property> > > > </bean> > > > > > > <bean name=3D"jumble" > > > class=3D"com.interface21.beans.factory.xml.MixedCollectionBean"> > > > <property name=3D"jumble"> > > > <ref name=3D"david"/> > > > <value>literal</value> > > > <ref name=3D"jenny" /> > > > </property> > > > </bean> > > > > > > I haven't dropped backward compatibility, or checked > > > anything in. > > > > > > If we agree this is an improvement, I'll check in these > > > changes this week. I > > > guess I don't need to drop backward compatibility right > > > now (beanRef), but > > > I think it should be dropped before 1.0. > > > > > > I'm open to suggestions as to how to improve the XML further. > > > > > > Regards, > > > Rod > > > > > > ----- Original Message ----- > > > From: "Rod Johnson" <rod...@in...> > > > To: <spr...@li...> > > > Sent: Tuesday, May 27, 2003 6:20 PM > > > Subject: [Springframework-developer] Spring bean > > > factory XML format > > > > > > > > > > Guys, > > > > > > > > I've just been thinking about an important potential issue. > > > > > > > > The current XML bean-reference syntax looks like: > > > > <property name=3D"foo" beanRef=3D"true">myFooBean</property> > > > > > > > > and, for lists etc (where a bean exposes a "CSV" property) > > > > <property name=3D"foos">a,b,c</property> > > > > > > > > While this syntax is concise, I think there are some > > > issues we should > > > > discuss. > > > > > > > > a. It's hard to validate this. There's no validatable > > > reference to another > > > > bean element id. It would be great if an XML editor > > > could help us in this > > > > regard. > > > > b. It's inelegant. The use of the CDATA in the > > > property element as a > > > string > > > > value or a reference (depending on the presence of an > > > attribute) is a bit > > > > messy. > > > > c. The CSV format is really a hack, that I used once > > > and then reused. Not > > > > only does the CSV make no sense to an XML editor > > > (analogous to putting CSV > > > > data in an RDBMS), it places the onus on each class > > > to parse the CSV and > > > > look up the necessary beans. This makes classes > > > exposing CSV properties > > > > dependent on the owning BeanFactory, lessening the > > > value of Spring's > > > > transparence. (Admittedly this is concealed in > > > framework classes, so it > > > > doesn't really affect developers.) With the proposed > > > new way, any > > > > application code could benefit from collection & > > > array support. > > > > d. The new way would make it easy to write XSLT that > > > showed relationships > > > > among Spring beans. This could be handy for > > > generating documentation about > > > > Spring apps. > > > > > > > > So I've been thinking of changes along the lines of: > > > > > > > > <property name=3D"foo"> > > > > <ref name=3D"myFooBean" /> > > > > </property> > > > > > > > > and > > > > > > > > <property name=3D"foos"> > > > > <ref name=3D"a" /> > > > > <ref name=3D"b"/> > > > > <ref name=3D"c"/> > > > > </property> > > > > > > > > In this case the foos bean class would expose a > > > Collection or array > > > > property, and the bean factory would no how to > > > populate that from the > > > > runtime references. No dependence on the fw even for > > > managing collection > > > > properties. > > > > > > > > I've already prototyped the idea of a <ref> > > > subelement, and that was > > > pretty > > > > simple to implement. I'll experiment with > > > collections tonight. > > > > > > > > Apart from changing XML files, the flow-on effect > > > would mean that anything > > > > that exposed a CSV property (like the AOP interceptor > > > proxy) would change > > > to > > > > exposing a Collection or array. > > > > > > > > What do you think? I'd like thoughts on the following > > > questions: > > > > > > > > 1. Does everyone agree that this is worth doing? > > > > > > > > 2. To support a collection including literal values, > > > should we introduce a > > > > new <value> element, meaning that simple properties > > > would become > > > > <property name=3D"foo"><value>canConvert this > > > string</value></property>. > > > More > > > > verbose, but more elegant. > > > > > > > > 3. Is there a way to help XML enforce the references > > > automatically? E.g. > > > > change bean "name" to "id" and use a <href> instead > > > of a <ref>? I haven't > > > > had a chance to explore this yet, but hopefully > > > someone knows XML better > > > > than I do. > > > > > > > > 4. If this is worth doing, should we do it in 0.8, > > > even if it delays the > > > > release (as it would)? On the one hand, we should > > > try to release ASAP. On > > > > the other hand, this change would break all existing > > > applications. Even > > > > though they'd be easy to fix, it might irritate > > > users. So the choice is: > > > > - release now with a likely incompatible change in store > > > > - accept a delay > > > > > > > > We'd also have to introduce analogous support for the > > > properties format, > > > > which couldn't benefit from XML capabilities. The > > > properties format would > > > > probably change very little. > > > > > > > > Regards, > > > > Rod > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.net email is sponsored by: ObjectStore. > > > > If flattening out C++ or Java code to make your > > > application fit in a > > > > relational database is painful, don't do it! Check > > > out ObjectStore. > > > > Now part of Progress Software. > > > http://www.objectstore.net/sourceforge > > > > > > > _______________________________________________ > > > > Springframework-developer mailing list > > > > Spr...@li... > > > > > > > > https://lists.sourceforge.net/lists/listinfo/springframework-develo= per > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: ObjectStore. > > > If flattening out C++ or Java code to make your > > > application fit in a > > > relational database is painful, don't do it! Check out > > > ObjectStore. > > > Now part of Progress Software. > > > http://www.objectstore.net/sourceforge > > > > > > _______________________________________________ > > > Springframework-developer mailing list > > > Spr...@li... > > > > > > > https://lists.sourceforge.net/lists/listinfo/springframework-develo= per > > > > > > > > > N=18HYX=E9=8A=B2un7+~V > > > /u=EB=99=A9=CA=8Bj=C6=8Aj=D8=B7j=D8=9Djj vv > > > =17=E8=92=8B9r=D4=A2 > > > >=DA=BAJ y=CB=B6=EB=B2=8Bq =E7=AE=A6 G j) =D4=AE)~{ > > > zZz=D7=B9=DB=A2y =1B=E9=B6=A6=CF=96+=CA=AD=C7=A2+=EB=96=B3 ~ G > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: ObjectStore. > > If flattening out C++ or Java code to make your application fit in a > > relational database is painful, don't do it! Check out ObjectStore. > > Now part of Progress Software. http://www.objectstore.net/sourceforge > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: ObjectStore. > > If flattening out C++ or Java code to make your application fit in a > > relational database is painful, don't do it! Check out ObjectStore. > > Now part of Progress Software. http://www.objectstore.net/sourceforge > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > >=20 > -- > Isabelle Muszynski > Software Engineer > Zandweellaan 4 > 2660 Antwerpen > Belgium > Tel. 32-(0)3-830 18 54 > Mobile: 32-(0)485 49 50 89 > Email: isa...@me... > Website: www.meta-logix.com >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 --=20 Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
