Menu
▾
▴
Re: [Springframework-developer] Spring bean factory XML format
|
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
|
