|
From: Keith D. <kd...@cs...> - 2004-03-04 15:30:50
|
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:
=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 use =
it
and have a ValidationService implementation that uses a
AttributesValidatorSource to load individual validators using
commons-attributes.
=20
This provides:
=20
- 100% backwards compatablility since the core interface is exactly what =
we
deal with now for 'programmatic' validators.
=20
- 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.
=20
- 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.
=20
Then, for the spring-rcp, where I need a richer results collector =
interface:
--
=20
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);
}
=20
... and of course I'll leverage a lot of the common classes between =
us...
=20
So you get a simple interface, backwards compatability, and I can extend =
it
for the spring-rcp stuff. Keith
=20
=20
|