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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I checked in a "BeanValidatorBuilder" class in the sandbox under
validation.support that allows you to declaratively assign
PropertyValidationRules to bean properties via Spring-IoC, through a
scripting environment such as Groovy/Beanshell, or programatically in =
plain
java.  This is in addition to support for defining validation rules on =
beans
via source markup.

Here's an example on how to use it:

Spring IoC configuration

	<bean id=3D"validatorBuilder"
class=3D"org.springframework.validation.support.ValidatorBuilder"/>
		<constructor-arg index=3D"0">
			<description>The validated bean type (class or
interface) aka 'root entity'</description>
			<value>org.springframework.validation.Pet</value>
		</constructor-arg>
		<map>
			<description>
				A map of property name keys to one or more
governing property validation rules.
				Nested bean property names from the 'root
entity' are supported.
				Rule instances may be reused across
properties if desired.
			</description>
			<entry key=3D"name.lastName">
				<value><bean
class=3D"org.springframework.validation.rules.Required"/></value>
			</entry>
			<entry key=3D"favoriteToy">
				<value>
					<set>
						<bean
class=3D"org.springframework.validation.rules.Required"/>
						<bean
class=3D"org.springframework.validation.rules.MaxLength">
=09
<constructor-arg>25</constructor-arg>

						</bean>
					</set>
				</value>
			</entry>
		</map>
	</bean>

Java

        BeanValidatorBuilder builder =3D new =
BeanValidatorBuilder(Pet.class);

        builder.setPropertyValidator("name.lastName", new Required());

        Set toyRules =3D new HashSet();
        toyRules.add(new Required());
        toyRules.add(new MaxLength(255));
        builder.setPropertyValidator("favoriteToy", toyRules);

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Keith Donald
Sent: Monday, March 08, 2004 6:08 PM
To: spr...@li...
Subject: Re: [Springframework-developer] declarative rules-based bean
validator w/ attributes in sandbox

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 -----=20
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=20
> attributes? Many people will not be happy using this quite new (and=20
> relatively non-standard) technique. I appreciate this might become=20
> more widespread with the metadata support in 1.5 but it will be a=20
> while before this is universally being used. As it stands, many people =

> dislike the need for tools like XDoclet. Is there currently support=20
> 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=20
> > 'org.springframework.validation' package.  The design has now gone=20
> > through several internal iterations and is waiting for your review=20
> > 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=20
> > built to-date.  Obviously we want to build up a rich library of=20
> > commonly-used rules.
> >
> > Within  'validation.support', you'll find implementations for the=20
> > above interfaces, as well as the "AttributesValidatorSource"=20
> > implementation which is responsible for loading validators=20
> > declaratively defined in source-metadata using commons-attributes.
> >
> > To use with a commons-attributes source, declare the following in a=20
> > spring-context definition:
> >
> > <bean id=3D"beanValidationService"
> >
class=3D"org.springframework.validation.support.DefaultBeanValidationServ=
ice"/
>
> >     <constructor-arg index=3D"0">
> >                     <description>The source providing validator=20
> > configuration information.</description>
> >         <bean id=3D"attributesSource"
> >
class=3D"org.springframework.validation.support.AttributesValidatorSource=
"/>
> >     </constructor-arg>
> > </bean>
> >
> > Again, beanValidationService is just a regular Spring validator, so=20
> > 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=20
> > validateable, it's associated BeanInfo.BeanDescriptor will have a=20
> > property called "isValidated" set to true.  In addition, each=20
> > PropertyDescriptor will also have a "isValidated" property, and if=20
> > true will have a PropertyValidator reference stored under the=20
> > "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=20
> > 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=20
> > were also commited to sandbox/util.  All of these relocated straight =

> > from spring-rcp.util.  Tests are also in sandbox/test, but I admit=20
> > right now the Validation stuff is in need of better tests.
> >
> > This framework should work equally well in web and rich-client=20
> > 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=20
> GenToo technologies. Learn everything from fundamentals to system=20
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

-------------------------------------------------------
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=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer