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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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