RE : [Springframework-developer] Spring bean factory XML format

[JP P. <jp....@ti...>]

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