(Quick Reference)
validator
Purpose
Adds custom validation to a field.
Examples
// Simple validator appending an 'invalid' error to the error object
even validator: {
return (it % 2) == 0
}// is equivalent to
even validator: { val ->
return (val % 2) == 0
}// Closure with two arguments, the second being the object itself
password1 validator: { val, obj ->
obj.password2 == val
}// Closure with three arguments, the third being the errors object
password1 validator: { val, obj, errors ->
if (!(obj.password2 == val)) errors.rejectValue('password1', 'noMatch')
}// Examples that pass arguments to the error message in message.properties// Example 1: Using the "implicit" argument 0 (property name)class Person { String name static constraints = {
name validator: {
if (!it) return ['entryMissing']
}
}// This maps to a message
// person.name.entryMissing=Please enter a name in the field {0}// Example 2: Using the "implicit" arguments 0 (property name) and 2 (property value)class Person { Integer yearOfBirth static constraints = {
yearOfBirth validator: {
if (yearOfBirth>2013) return ['yearTooBig']
}
}// This maps to a message
// person.name.entryMissing=The value {2} entered in the field {0} is not valid because it lies in the future.
// You will note when using this kind of message on Integers that years are displayed as 1,990 instead of 1990.
// This is addressed in the next example.// Example 3: Much more complexclass Astronaut { Integer yearOfBirth
Integer yearOfFirstSpaceTravel yearOfFirstSpaceTravel validator: { val, obj ->
if (val < obj.yearOfBirth) ['datePriorTo', val.toString(), obj.yearOfBirth]
else if (val < (obj.yearOfBirth+18)) ['maybeABitTooYoung', val-obj.yearOfBirth]
}
}// Respective messages
// Note that argument 3 is the property value converted toString to avoid the unwanted formatting as described before.
astronaut.yearOfFirstSpaceTravel.datePriorTo=The value {3} entered for the year of the first space travel is prior to the year of birth ({4}). Please correct the value.
astronaut.yearOfFirstSpaceTravel.maybeABitTooYoung={3} years seems a bit young for travelling to space, dude!Description
A custom validator is implemented by a Closure that takes up to three parameters. If the Closure accepts zero or one parameter, the parameter value will be the one being validated ("it" in the case of a zero-parameter Closure). If it accepts two parameters the first is the value and the second is the domain class instance being validated. This is useful when your validation needs access to other fields, for example when checking that two entered passwords are the same. If it accepts three parameters the first is the value, the second is the instance, and the third is the Spring
Errors object.
The closure can return:
null or true (or no return value) to indicate that the value is validfalse to indicate an invalid value and use the default message code- a string to indicate the error code to append to the "classname.propertyName." string used to resolve the error message. If a field-specific message cannot be resolved, the error code itself will be resolved allowing for global error messages.
- a list containing a string as above, and then any number of arguments following it, which are used as formatted message arguments in the
grails-app/i18n/message.properties file. The mapping of the arguments is as follows: Parameters 0 to 2 are automatically mapped to 0: property name, 1: class name, 2: property value. Additional parameters are mapped starting at parameter 3.
Please note that in the final error message, the label for this property will be used if it is defined in the message.properties file. Otherwise, the property name as defined in the class is used.
When explicitly passing error codes, it is usually not necessary to return the error code using the "return" keyword, because if the validator returns from the closure, it will check if any errors have been attached to the errors object.
This can be especially seen in the case of a three-parameter Closure where it is expected that the
Errors object will be updated directly.
