Bug 147489 - [DataBinding] CompositeValidator and ValidationError
Summary: [DataBinding] CompositeValidator and ValidationError
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Boris Bokowski CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-16 13:48 EDT by Peter Centgraf CLA
Modified: 2019-11-27 07:28 EST (History)
2 users (show)

See Also:


Attachments
AndValidator and test (10.88 KB, patch)
2007-02-07 01:28 EST, Peter Centgraf CLA
no flags Details | Diff
AndValidator and test, updated copyright (11.48 KB, patch)
2007-02-07 01:34 EST, Peter Centgraf CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Centgraf CLA 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();
Comment 1 Peter Centgraf CLA 2007-02-07 01:20:07 EST
Now that IValidator operates in terms of IStatus, option 1 (above) seems to make the most sense.  A composite IValidator could then return a MultiStatus containing the accumulated result list.  The message could be any reasonable default, e.g. the message from the first or last child.  Client code that cares to dig deeper can use the existing MultiStatus API.
Comment 2 Peter Centgraf CLA 2007-02-07 01:28:30 EST
Created attachment 58423 [details]
AndValidator and test

Patch with a minimal test case to implement the ideas above.  I also added a few static convenience methods for wrapping the validators already configured on a BindSpec.
Comment 3 Peter Centgraf CLA 2007-02-07 01:34:40 EST
Created attachment 58424 [details]
AndValidator and test, updated copyright
Comment 4 Nigel Westbury CLA 2013-02-07 10:44:57 EST
The proposed new API for e4 should take care of this.  We should be sure that we take into consideration all the issues Peter has come up with and Peter's suggestions will be useful when putting together the details of the new databinding API for e4.
Comment 5 Lars Vogel CLA 2019-11-27 07:28:22 EST
This bug hasn't had any activity in quite some time. Maybe the problem got
resolved, was a duplicate of something else, or became less pressing for some
reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it.
The information can be, for example, that the problem still occurs, that you
still want the feature, that more information is needed, or that the bug is
(for whatever reason) no longer relevant.

If the bug is still relevant, please remove the stalebug whiteboard tag.