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

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

Sam,

Up until some design changes this weekend, I had a working source
implementation that would let you build validation configuration information
programatically (either java or a scripting shell like groovy/beanshell) or
by using a Spring context (xml.)  I haven't checked it back in yet, but I
will do so ASAP.  Thanks for pointing that out, Keith

----- Original Message ----- 
From: "Sam Newman" <sam...@ma...>
To: <spr...@li...>
Sent: Monday, March 08, 2004 5:31 PM
Subject: Re: [Springframework-developer] declarative rules-based bean
validator w/ attributes in sandbox


> 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/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer