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

[Sam N. <sam...@ma...>]

Keith,

At present can validation rules only be configured from in code 
attributes? Many people will not be happy using this quite new (and 
relatively non-standard) technique. I appreciate this might become more 
widespread with the metadata support in 1.5 but it will be a while 
before this is universally being used. As it stands, many people dislike 
the need for tools like XDoclet. Is there currently support for reading 
validation rules from a config file?

Keith Donald wrote:

> 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.
>  
> Within 'validation', you'll find the following interfaces:
> 
>     BeanValidationService
>         (the main client interface, extends
>     org.springframework.validation.Validator)
>      
>     BeanValidatorSource
>         (encapsulates logic for loading validator configuration
>     information from a specific source.)
>      
>     PropertyValidator
>         (encapsulates the validation of all PropertyValidationRules that
>     apply to a particular property.)
>      
>     PropertyValidationRule
>         (encapsulates a single validation rule and typing-hint/error
>     message building logic.)
>      
>     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.
>  
> 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.
>  
> To use with a commons-attributes source, declare the following in a 
> spring-context definition:
>  
> <bean id="beanValidationService" 
> class="org.springframework.validation.support.DefaultBeanValidationService"/>
>     <constructor-arg index="0">
>                     <description>The source providing validator 
> configuration information.</description>
>         <bean id="attributesSource" 
> class="org.springframework.validation.support.AttributesValidatorSource"/>
>     </constructor-arg>
> </bean>
>  
> Again, beanValidationService is just a regular Spring validator, so you 
> can treat it as such.
>  
> 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.)
>  
> 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.
>  
> 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!
>  
> Keith


-- 
sam
http://www.magpiebrain.com/