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

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

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