Bug 147489

Description Peter Centgraf 2006-06-16 13:48:54 EDT

I've been thinking about how client code might interact with validation.  I have a rough outline of a solution, but it requires significant adjustments to the current design.

The validation logic for an individual binding often combines default behavior with additional application-specific constraints.  E.g. "string should convert cleanly to int" + "string should not be more than 5 digits long".  In this situation, composition is much preferred over inheritance, to avoid coupling.  There are several ways to accomplish this.  In both cases, the framework provides the composition behavior.

1. Provide a standard CompositeValidator that chains two IValidators, where isValid() == (A.isValid() && B.isValid()).  Client code would look like:

setValidator(new CompositeValidator(getValidator(), myValidator));

2. Modify the BindSpec API to provide addValidator and removeValidator, in addition to setValidator.  Client code would look like:

addValidator(myValidator);


The tricky part about composing IValidators involves ValidationError.  There is no straightforward or universal way to compose two error messages.  This is necessarily application-specific, or at least should be customizable.  Currently, the DBC provides simplistic composition of ValidationErrors, accumulating them into a List.  This isn't always good enough, though, because some applications want to relate errors to specific Bindings.

AFAIK, both Spring MVC and Struts solve this problem by providing a context object along with the input to be validated.  Rather than returning an error object, the validators modify the state of the shared context object.  The context object exposes a mapping from bindings to errors.  It might also define a special class for "global" errors.  A particular validator may produce any number of errors, including zero.  (This eliminates the unintuitive ValidationError.SUCCESS state.)

I suggest that JFace bindings take a similar approach.  The new API would be:

IErrors ...
public void addWarning(String msg, boolean global);
public void addError(String msg, boolean global);
// @return List<String>
public List getWarnings();
public List getErrors();

IValidator <ValueType> ...
// @param input <ValueType>
public boolean isValid(Object input, IErrors context);

DataBindingContext ...
// @param a specific Binding, or null to get global errors
public IErrors getValidationErrors(Binding b);
// @return Map<Binding, IErrors> -- use null as key for global errors
public Map getAllValidationErrors();