[Springframework-developer] Spring bean factory XML format

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

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