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

[Rod J. <rod...@in...>]

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