RE: [Springframework-developer] declarative validation rules inte rfaces

[Kopylenko, D. <dko...@ac...>]

Yes, we could wait for Confluence (coming soon...) and collaborate there !

-----Original Message-----
From: sam...@ma... [mailto: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 
> think:
>  
> public interface Validator {
>     public boolean supports(Class beanClass);
>     public void validate(Object bean, Errors errors);
> }
>  
> Look familiar? It's the existing spring Validator interface! We can 
> use it and have a ValidationService implementation that uses a 
> AttributesValidatorSource to load individual validators using 
> commons-attributes.
>  
> This provides:
>  
> - 100% backwards compatablility since the core interface is exactly 
> what we deal with now for 'programmatic' validators.
>  
> - A single implementation -- ValidationService -- that encapsulates 
> the workflow for invoking the various declarative validators and 
> collecting the results.  This implementation is independent of any 
> source of validation rules (like via attributes.)  This allows us to 
> vary the source without impacting the processing algorithm, and it 
> keeps a good separation of concerns.
>  
> - A ValidatorSource interface (very DAO like) which loads validators 
> processed (and optionally cached) by ValidationService.  Source 
> implementations can use commons attributes, programmatic builder-style 
> via Spring IoC or a scripting technology or by hand, a config file, 
> whatever.
>  
> Then, for the spring-rcp, where I need a richer results collector 
> interface:
> --
>  
> public interface RichClientValidationService {
>     public void validateBean(Object bean, ValidationResultsCollector 
> results);
>     public void validatePropertyValue(Object bean, String propertyName,
>             Object value, ValidationResultsCollector results);
>     public void validatePropertyValues(Object bean, String[] properties,
>             Object[] values, ValidationResultsCollector results); }
>  
> ... and of course I'll leverage a lot of the common classes between 
> us...
>  
> So you get a simple interface, backwards compatability, and I can 
> extend it for the spring-rcp stuff.  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