RE: [Springframework-developer] declarative validation rules interfaces

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

Sam,

Yea, your interceptor could use the source to lookup a validator by =
command
class, which would return you a BeanValidator instance for that command.
Each BeanValidator has the workflow to validate the entire bean, =
including
all properties, and nested beans.  Or you could just use the
ValidationService, where you directly pass in the command bean instance =
and
it'll look up the BeanValidator for you and use it (which I would
recommend.)  The service is basically just a thin fa=E7ade that =
abstracts that
lookup API away from you and lets you vary where validators are loaded
from...

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
sam...@ma...
Sent: Thursday, March 04, 2004 10:32 AM
To: spr...@li...
Subject: Re: [Springframework-developer] declarative validation rules
interfaces


Looks fantastic Keith. I guess I just have to write a simple
ValidationInterceptor to call the ValidationSource....with that in mind =
I've
posted a simple overview diagram showing how my commands get executed =
and
invoked at my blog here: =
http://www.magpiebrain.com/archives/000189.html. We
could do with a Wiki or website for this stuff perhaps - would make
documenting spring-rcp a little easier...

sam

Quoting Keith Donald <kd...@cs...>:

> How does this look -  I propose one interface you have to deal with to =

> the entire declarative validation subsystem.  Let me know what you=20
> think:
> =20
> public interface Validator {
>     public boolean supports(Class beanClass);
>     public void validate(Object bean, Errors errors);
> }
> =20
> Look familiar? It's the existing spring Validator interface! We can=20
> use it and have a ValidationService implementation that uses a=20
> AttributesValidatorSource to load individual validators using=20
> commons-attributes.
> =20
> This provides:
> =20
> - 100% backwards compatablility since the core interface is exactly=20
> what we deal with now for 'programmatic' validators.
> =20
> - A single implementation -- ValidationService -- that encapsulates=20
> the workflow for invoking the various declarative validators and=20
> collecting the results.  This implementation is independent of any=20
> source of validation rules (like via attributes.)  This allows us to=20
> vary the source without impacting the processing algorithm, and it=20
> keeps a good separation of concerns.
> =20
> - A ValidatorSource interface (very DAO like) which loads validators=20
> processed (and optionally cached) by ValidationService.  Source=20
> implementations can use commons attributes, programmatic builder-style =

> via Spring IoC or a scripting technology or by hand, a config file,=20
> whatever.
> =20
> Then, for the spring-rcp, where I need a richer results collector=20
> interface:
> --
> =20
> public interface RichClientValidationService {
>     public void validateBean(Object bean, ValidationResultsCollector=20
> results);
>     public void validatePropertyValue(Object bean, String =
propertyName,
>             Object value, ValidationResultsCollector results);
>     public void validatePropertyValues(Object bean, String[] =
properties,
>             Object[] values, ValidationResultsCollector results); }
> =20
> ... and of course I'll leverage a lot of the common classes between=20
> us...
> =20
> So you get a simple interface, backwards compatability, and I can=20
> extend it for the spring-rcp stuff.  Keith
> =20
> =20
>=20


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