[hibernate-dev] [Bean Validation] Relax property names in ConstraintValidatorContext

[Emmanuel Bernard]

Property names passed to
context.addError(message, "myProperty");
used to be limited to existing properties and could only be used if  
the constraint declaration was on the class-level.
Otherwise, an exception was raised.

I relaxed this rule as some people came with use cases involving  
validating property values by navigating properties hosted on the  
property value.

@SafeZipCodeAndCity
public Address getAddress() { ... }

Here is the new wording

Example 2.13. ConstraintValidatorContext interface passed to  
ConstraintValidator.isValid()

/**
  * Provide contextual data and operation when applying a given  
constraint validator implementation
  *
  * @author Emmanuel Bernard
  */
public interface ConstraintValidatorContext {
	/**
	 * Disable default error message and default ConstraintViolation  
object generation.
	 * Useful to set a different error message or generate an  
ConstraintViolation based on
	 * a different property
	 *
	 * @see #addError(String)
	 * @see #addError(String, String)
	 */
	void disableDefaultError();

	/**
	 * @return the current unexpanded default message
	 */
	String getDefaultErrorMessage();

	/**
	 * Add a new error message. This error message will be interpolated.
	 * <p/>
	 * If isValid returns false, a ConstraintViolation object will be  
built per error message
	 * including the default one unless #disableDefaultError() has been  
called.
	 * <p/>
	 * Aside from the error message, ConstraintViolation objects  
generated from such a call
	 * contains the same contextual information (root bean, path and so on)
	 * <p/>
	 * This method can be called multiple time. One ConstraintViolation  
instance per
	 * call is created.
	 *
	 * @param message new unexpanded error message
	 */
	void addError(String message);

	/**
	 * Add a new error message to a given sub property <code>property</ 
code>.
	 * This error message will be interpolated.
	 * <p/>
	 * If isValid returns false, a ConstraintViolation object will be built
	 * per error message including the default one unless  
#disableDefaultError()
	 * has been called.
	 * <p/>
	 *
	 * @param message new unexpanded error message
	 * @param property property name the ConstraintViolation is targeting
	 */
	void addError(String message, String property);
}

The ConstraintValidatorContext interface allows to redefine the  
default message error generated when a constraint is not valid. By  
default, each invalid constraint leads to the generation of one error  
object represented by a ConstraintViolation object. This object is  
build from the default error message as defined by the constraint  
declaration and the context in which the constraint declaration is  
placed on (bean, property, attribute).

The ConstraintValidatorContext methods let the constraint  
implementation disable the default error object generation and create  
one or more custom ones. The unexpanded message passed as a parameter  
is used to build the ConstraintViolation object (the message  
interpolation operation is applied to it). The property on which the  
error object is applied is defined as following:

if property is not overridden, the current context the constraint is  
declared on is used (bean or property)

if the property is overridden, the current context the constraint is  
declared on the property passed as a parameter relative to the  
constraint declaration being evaluated

The property can be overridden by calling  
ConstraintValidatorContext.addError(String, String).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090209/bd1279ad/attachment.html