|
From: Keith D. <kd...@cs...> - 2004-03-08 16:11:20
|
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
|
|
From: Seth L. <se...@eh...> - 2004-03-08 18:36:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Keith, I just got into work (crazy Hawaii time) and I saw this gem. Can't wait to check it out. Thanks for all your work, Seth ps I wrote some more validation rules in the meantime that might be useful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFATLkz5EIB1scRes8RAlFHAJ99GQ6ZUAgbc3oUvK4qq4jRkUFaCQCfYVhH 9+wdtuQbLs9AiotDpeQ+row= =oaz8 -----END PGP SIGNATURE----- |
|
From: Sam N. <sam...@ma...> - 2004-03-08 22:47:57
|
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/ |
|
From: Seth L. <se...@eh...> - 2004-03-08 23:10:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Newman wrote: | 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? Much of Keith's work is introducing new interfaces and classes to make writing validators easier. One possible implementation is an attributes based validator. Other options include an implementation based on commons-validator, which uses an external XML file for its rules. Daniel Miller is working on this exact code. If you are waiting for metadata support but don't want jdk 1.5 or xdoclet, look into commons-attributes. It's quite nice. In short, Keith is working on two things: new validation classes and interfaces /and/ an implementation of a commons-attributes validator. Daniel is working on the commons-validator implementation. As with Spring, there are many choices! :) Seth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFATPl05EIB1scRes8RAivsAJ4kZwNnppDhmrd3LJ+ctf+SGCKoVwCfXc6D AT8Eh5tib2QWx+hZBVsuf68= =odIu -----END PGP SIGNATURE----- |
|
From: Keith D. <kd...@cs...> - 2004-03-08 23:24:32
|
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 |
|
From: Keith D. <kd...@cs...> - 2004-03-10 01:10:28
|
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
|