We also setup lots of global {Key}
replacements for your messages and also several that the core constraint validators offer as well. This is great for adding these customizations on your custom messages and also your i18n messages (Keep Reading):
{rejectedValue}
- The rejected value
{field or property}
- The property or field that was validated
{validationType}
- The name of the constraint validator
{validationData}
- The value of the constraint definition, e.g size=5..10, then this value is 5..10
{DiscreteValidator}
- operation, operationValue
{InListValidator}
- inList
{MaxValidator}
- max
{MinValidator}
- min
{RangeValidator}
- range, min, max
{RegexValidator}
- regex
{SameAsValidator}
, {SameAsNoCaseValidator}
- sameas
{SizeValidator}
- size, min, max
{TypeValidator}
- type
Defining nested struct or array item validation can create very nested code. cbvalidation allows for a shortcut to define these structures using a custom field name instead.
For a nested struct, this is done by defining the field as a dot-delimited field name following the nested structure.
This can be continued as many levels deep as necessary.
For a nested array, this is done by defining the field as a dot-delimited field name following the nested structure using an asterisk (*
) to represent the items of the array.
The struct and array shorthand can be combined, as well.
By default if a constraint fails an error message will be set in the result objects for you in English. If you would like to have your own custom messages for specific constraints you can do so by following the constraint message convention:
Just add the name of the constraint you like and append to it the word Message and you are ready to roll:
Below are all the currently supported constraints. If you need more you can create your own Custom validators as well.
The field must be yes, on, 1, or true. This is useful for validating "Terms of Service" acceptance.
The field under validation must be a value after a given date. The dates will be passed into the dateCompare()
function in order to be converted and tested.
Instead of passing a date, you may specify another field to compare against the date as well:
The field under validation must be a value after or equal a given date. The dates will be passed into the dateCompare()
function in order to be converted and tested.
The field must be alphabetical ONLY
This validator is used to validate an array's items. It will iterate through each of the array's items and validate each item against the validationData
constraints you pass in.
You may also specify items
as an alias to arrayItem
.
Any validation errors found will be named using the parent field name and array index.
You can validate nested structs by nesting a constraints
validator.
There is a shortcut notation available for arrayItem
that uses a specialized field name to skip nesting the constraints.
The field under validation must be a value before a given date. The dates will be passed into the dateCompare()
function in order to be converted and tested.
Instead of passing a date, you may specify another field to compare against the date as well:
The field under validation must be a value before or equal a given date. The dates will be passed into the dateCompare()
function in order to be converted and tested.
This validator is used to validate a nested struct. The value of this validator are the constraints for the nested struct.
Any validation errors found will be named using the parent field name and the child field name.
constraints
can be used as many levels deep as you need to go.
constraints
can also be combined with items
to validate an array of structs.
There is a shortcut notation available for constraints
that uses a specialized field name to skip nesting the constraints.
The field under validation must be a value that is the same as the given date. The dates will be passed into the dateCompare()
function in order to be converted and tested.
Instead of passing a date, you may specify another field to compare against the date as well:
The field must pass certain discrete math operations using the format: operator:value
gt
- Greater than the value
gte
- Greater than or equal to the value
lt
- Less than the value
lte
- Less than or equal to the value
eq
- Equal to the value
neq
- Not equal to the value
The field is not required but if it exists it cannot be empty.
This is needed since required validators allow empty strings when false
while type validators ignore empty values as valid. This means we can have a situation as follows:
With these validation rules passing in startDate = ""
would pass the validation! The empty validator helps us ensure that the value passed in is not empty (and, in this case, a date).
The field still isn't required, but if it is passed the value must be a non-empty value and it must be parseable as a date.
The field must be in the included list
See arrayItem.
The field must be less than or equal to the defined value
The methodName
will be called on the target object and it will pass in validationData, targetValue, and metadata. It must return a boolean response: true = pass, false = fail.
Any data you place in the metadata
structure will be set in the validation result object for later retrieval.
The field must be greater than or equal to the defined value
See constraints.
The field must be within the range values and the validation data must follow the range pattern: min..max
The field must pass the regular expression match with no case sensitivity
The field must have some type of value and not null.
The field under validation must be present and not empty if the anotherfield
field is equal to the passed value
. The validation data can be a struct
or a string
representing the field to check.
The field under validation must be present and not empty unless the anotherfield
field is equal to the passed value
. The validation data can be a struct
or a string
representing the field to check.
The field must be the same as another field with no case sensitivity
The field must be the same as another field with case sensitivity
The field value size must be within the range values and the validation data must follow the range pattern: min..max.
Value can be a (struct,string,array,query)
One of the most versatile validators. It can test if the value is of the following specific types:
alpha
array
binary
boolean
component
creditcard
date
eurodate
float
GUID
integer
ipaddress
json
numeric
query
ssn
string
struct
telephone
url
usdate
UUID
xml
zipcode
The field value, the target object, and an empty metadata structure will be passed to the declared closure/lambda to use for validation. The UDF must return boolean, validate( value, target, metadata ):boolean
. NOTE: The target object passed in is actually an instance of "GenericObject", not a struct. To access the underlying struct, use the getMemento() function and perfom any comparisons on that. See the example below.
Any data you place in the metadata
structure will be set in the validation result object for later retrieval.
The field must be a unique value in a specific database table. The validation data is a struct with the following keys:
table
: The name of the table to check
column
: The column to check, defaults to the property field in check
The field value will be passed to the validator CFC to be used for validation. Please see Custom Validators