[Springframework-developer] flexible configuration schemas (beyond javabeans)

[Keith D. <kd...@cs...>]

A recent post to the user list got me thinking about an idea for extending
Springs support for configuration beyond that of java beans in certain,
frequently-used circumstances with the goals of:
    1. Reducing configuration complexity by requiring less configuration XML
overall.
    2. Tailoring a custom configuration schema to a specific problem domain,
making the XML 'easier to understand' and more abstract (perhaps by allowing
the creation of a xml schema definition.)

What I am suggesting is something similiar to how Eclipse -- and now
Hivemind -- does it.  In the post I am referring to the Spring-webmvc
developer wanted to simplify configuration information for his web
controllers to in effect make the configuration xml look a lot like
WebWorks.  I've found in developing a data validation framework for
rich-clients I would also like a similiar flexible xml-schema capability,
because I could simplify what the user needs to fool with in order to
define/tweak validation rules.

I know all this may sound a bit abstract so I'll try to illustrate what I'm
talking about with an example--here's how the definition of a set of data
validation rules for a bean class looks with Spring today:

Note: what this configuration says is "for instances of
"MyValidateableBean", apply a <mandatory>, <maxlength>, and <uniqueName>
rule to the 'name' property."

 <bean id="myValidateableBean"
class="com.csi.commons.utils.validator.BeanValidatorImpl">
     <property
name="beanClass"><value>com.MyValidateableBean</value></property>
     <property
name="objectName"><value>myValidateableBean</value></property>
     <property name="propertyValidators">
         <set>
              <bean id="validateableProperty"
class="com.csi.commons.utils.validator.PropertyValidatorImpl">
                  <constructor-arg index="0">
                        <description>The name of the property with
validation rules attached</description>
                        <value>validateableProperty</value>
                  </constructor-arg>
                  <constructor-arg index="1">
                        <description>The validation rules for this
property</description>
                       <set>
                             <ref bean="mandatory"/>
                             <bean id="nameMaxLength"
class="com.csi.commons.utils.validator.MaxLengthValidationRule">
                                  <constructor-arg
index="0">25</constructor-arg>
                             </bean>
                             <ref bean="uniqueName"/>
                       </set>
                   </constructor-arg>
                  <property
name="continueOnError"><value>false</value></property>
               </bean>
         </set>
     </property>
 </bean>

A couple of things--obviously the XML is littered with property, set,
constructor-arg, and class declarations, which bloats the XML and couples
configuration with implementation.  Don't get me wrong, I very much like
javabeans-based configuration because it's so generically flexible (and
quite powerful), but in some cases I would love to be able to simplify the
xml schema for validation because these validation rules are frequently
defined and might be tweaked by end users.  Here's how I'd like it to look
(this configuration schema would scream):

<validator class="com.MyValidateableBean" objectName="myValidateableBean">
    <property name="validateableProperty" continueOnError="false">
        <rule type="mandatory"/>
        <rule type="maxLength"/>
            <parameter name="value" value="25"/>
        </rule>
        <rule type="uniqueName"/>
    </property>
</validator>

Much less xml.  No constructor/set/class references.  All that is abstracted
away and what remains is just configuration information.

Now, to support this you'd need:
    1. An xml schema definition so the XML could be validated.
    2. A way to map the XML above into some generic java
ConfigurationElements that could then be processed by code that would then
instantiate what is basically declared in the first 'Spring today'
definition above.  For example, rule "type" strings above would needed to be
mapped to classes using a RuleFactory or something.

Basically complexity is pushed into custom processing code at the gain of
greatly simplifying the XML for the configuring user.  Again this is very
similiar to how Eclipe's plugin model -- and now Hivemind -- works.

What do you guys think?

Keith