[Springframework-developer] declarative rules-based bean validator w/ attributes in sandbox

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

I just committed the rules-based bean validator Seth and I have been =
working
on to the spring/sandbox under the 'org.springframework.validation' =
package.
The design has now gone through several internal iterations and is =
waiting
for your review and feedback.
=20
Within 'validation', you'll find the following interfaces:

BeanValidationService
    (the main client interface, extends
org.springframework.validation.Validator)
=20
BeanValidatorSource
    (encapsulates logic for loading validator configuration information =
from
a specific source.)
=20
PropertyValidator
    (encapsulates the validation of all PropertyValidationRules that =
apply
to a particular property.)
=20
PropertyValidationRule
    (encapsulates a single validation rule and typing-hint/error message
building logic.)
=20
ValidationResultsCollector
    (data-collector with callbacks to track validation progress.  Is =
also
used to populate an Errors object.)

Within 'validation.rules', you'll find the out-of-the-box rules built
to-date.  Obviously we want to build up a rich library of commonly-used
rules.
=20
Within  'validation.support', you'll find implementations for the above
interfaces, as well as the "AttributesValidatorSource" implementation =
which
is responsible for loading validators declaratively defined in
source-metadata using commons-attributes.
=20
To use with a commons-attributes source, declare the following in a
spring-context definition:
=20
<bean id=3D"beanValidationService"
class=3D"org.springframework.validation.support.DefaultBeanValidationServ=
ice"/
>
    <constructor-arg index=3D"0">
                    <description>The source providing validator
configuration information.</description>
        <bean id=3D"attributesSource"
class=3D"org.springframework.validation.support.AttributesValidatorSource=
"/>
    </constructor-arg>
</bean>
=20
Again, beanValidationService is just a regular Spring validator, so you =
can
treat it as such.
=20
Internally, the design leverages the java-beans BeanInfo paradigm to =
store
validators loaded from a particular source.  If a bean is validateable, =
it's
associated BeanInfo.BeanDescriptor will have a property called =
"isValidated"
set to true.  In addition, each PropertyDescriptor will also have a
"isValidated" property, and if true will have a PropertyValidator =
reference
stored under the "validator" property.  I thought this was a good way to
leverage the existing javabeans metadata API (and the good thing is it
removes us from having to cache anything ourselves or maintain some =
parallel
hierarchy of bean validators...)  The generic validation algorithm =
simply
iterates over each BeanInfo and PropertyDescriptor looking for attached
validators... (which could've been populated by any source.)
=20
As a result of these commits, some common (small) utility classes were =
also
commited to sandbox/util.  All of these relocated straight from
spring-rcp.util.  Tests are also in sandbox/test, but I admit right now =
the
Validation stuff is in need of better tests.
=20
This framework should work equally well in web and rich-client =
environments.
I think once we get a iteration or two more we'll be there!
=20
Keith