Type constraints error messages

bodrin · **Joined:** Thu Apr 17, 2008 5:47 pm **Posts:** 26

I think there is a problem with the error messages a type (class level) constraint can generate.
The field/property constraint usually has a single error message template, but a type constraint can validate more than one thing (multiple sub-constraints), so it will need to generate more then one error message.
With the current API this seems to be impossible.

I think I have seen how this can be done from the agimatec guys (http://code.google.com/p/agimatec-validation/ ).
A constraint can implement:

Code:

package com.agimatec.utility.validation;

/**
 * Description: Interface for a single validation <br/>
 * User: roman.stumm <br/>
 * Date: 06.07.2007 <br/>
 * Time: 10:04:39 <br/>
 *
 */
public interface Validation {
  /**
   * Perform a single validation routine
   * Validate the object or property according to the current ValidationContext.
   * @param context - to access the property, value, constraints
   * @param listener  - to write results to
   */
  void validate(ValidationContext context, ValidationListener listener);
}

And then it can generate arbitrary error message (reason) calling the listener:

Code:

package com.agimatec.utility.validation;
/**
 * Description: The interface to collect errors found during validation<br/>
 * User: roman.stumm <br/>
 * Date: 06.07.2007 <br/>
 * Time: 13:18:24 <br/>
 *
 */
public interface ValidationListener {
    /**
     * Error notification sent by a Validation.
     *
     * @param reason    a constant describing the reason. This is normally the key of the
     * feature that was violated in the object 'owner' for property 'propertyName'
     * @param context   - contains
     *      bean =         the object that contains the error (owner)
     *      propertyName = the Name of the attribute that caused the error
     */
    void addError(String reason, ValidationContext context);
}

Also it looks like it will be very useful to have the validation context passed to each constraint. This way one constraint can delegate the validation to other constraints.

What do you think?

FroMage · **Joined:** Tue Apr 01, 2008 11:10 am **Posts:** 69

I vote in favour of being able to not only specify _multiple_ error messages per bean-level validation, but also in favour of being able to associate errors and error messages to properties in the process (possibly multiple properties too). When declaring an error, it is crucial to be able to associate the faulty property (-ies) so that the error-handling layer will be able to know what went wrong.

bodrin · **Joined:** Thu Apr 17, 2008 5:47 pm **Posts:** 26

Could you express the idea with this property error associations in a code example?

FroMage · **Joined:** Tue Apr 01, 2008 11:10 am **Posts:** 69

public isValid(Object bean, ValidationListener listener){
if((bean.getFoo() % 2) != 0)
listener.addError(bean, "foo", "{foo.invalid}");

if(bean.getBar() == null || bean.getBar().hasChildren())
listener.addError(bean, "bar", "{bar.invalid}");

if(bean.getMailAddress() == null && bean.getPostAddress() == null)
listener.addError(bean, new String[]{"postAddress", "mailAddress"}, "{one.address.must.be.specified}");
}

This is needed so that the view layer will know what properties are the cause for errors.

Now that I stop to think for a second, I think it should also be possible to access the validator in order to programatically trigger a validation of the bean's properties, in order to be able to do anything that is doable with property-level validation. In other words, we need the counter-part of @Valid for subproperties.

bodrin · **Joined:** Thu Apr 17, 2008 5:47 pm **Posts:** 26

So, may be it is better to send a whole InvalidConstraint object instead of String reason:

Code:

package com.agimatec.utility.validation;
/**
 * Description: The interface to collect errors found during validation<br/>
 * User: roman.stumm <br/>
 * Date: 06.07.2007 <br/>
 * Time: 13:18:24 <br/>
 *
 */
public interface ValidationListener {
    /**
     * Error notification sent by a Validation.
     *
     * @param reason    a constant describing the reason. This is normally the key of the
     * feature that was violated in the object 'owner' for property 'propertyName'
     * @param context   - contains
     *      bean =         the object that contains the error (owner)
     *      propertyName = the Name of the attribute that caused the error
     */
    void addError(InvalidConstraint reason, ValidationContext context);
} 

And eventually extending the InvalidConstraint definition if it does not provides all the needed information?

Also a better method name may be is addInvalidConstraint instead of addError.

What do you think?

emmanuel · **Posted:** Thu Jun 05, 2008 6:05 pm

FroMage wrote:

Now that I stop to think for a second, I think it should also be possible to access the validator in order to programatically trigger a validation of the bean's properties, in order to be able to do anything that is doable with property-level validation. In other words, we need the counter-part of @Valid for subproperties.

can you expand your idea ehre, I am not sure I follow :)

bodrin · **Joined:** Thu Apr 17, 2008 5:47 pm **Posts:** 26

Quote:

This way one constraint can delegate the validation to other constraints.

It is usefull in order to programatically implement (sub-)graph validation without using @Valid.
A graph/sub-graph could be validated against different validation policies and some of these policies could be available only runtime (unavailable during design/compile time) so that no helper metada like @Valid is present or the metada is present in some third-party format and should be processed via some custom logic.
So this API gives more freedom when validating graphs, because of the validation delegation feature.

The other thing is that it looks like we better shift the responsibility of building the InvalidConstraint objects to the constraint validators itself.
Currently the constraint validators provide information (isValid=true/false) and the framework builds the InvalidConstraint objects with the help of its internal context (bean, ppropertyName, propertyValue, annotation,...).
It is better to provide this context explicitly to the constraint validator, so that it could itself build the InvalidConstraint object(s) instead of returning true/false (isValid).

Also the proposed API gives the freedom to the constraint validator to generate multiple InvalidConstraint objects which is required for the type level constraints.