Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
In this section you will find the release notes for each version we release under this major version. If you are looking for the release notes of previous major versions use the version switcher at the top left of this documentation book. Here is a breakdown of our major version releases.
feature
: Added constraintProfiles
to allow you to define which fields to validate according to defined profiles: https://github.com/coldbox-modules/cbvalidation/issues/37
feature
: Updated RequiredUnless
and RequiredIf
to use struct literal notation instead of the weird parsing we did.
feature
: Added the Unique
validator thanks to @elpete!
improvement
: Added null
support for the RequiredIf,RequiredUnless
validator values
Just drop into your modules folder or use CommandBox to install
box install cbvalidation
The module will register several objects into WireBox using the @cbvalidation
namespace. The validation manager is registered as ValidationManager@cbvalidation
. It will also register several helper methods that can be used throughout the ColdBox application.
The module will also register two methods in your handlers/interceptors/layouts/views
validate()
validateOrFail()
getValidationManager()
No more manual discovery of validators, automated registration and lookup process, cleaned lots of code on this one!
New Validator: Accepted
- The field under validation must be yes, on, 1, or true. This is useful for validating "Terms of Service" acceptance.
New Validator: Alpha
- Only allows alphabetic characters
New Validator: RequiredUnless
with validation data as a struct literal { anotherField:value, ... }
- The field under validation must be present and not empty unless the anotherfield
field is equal to the passed value
.
New Validator: RequiredIf
with validation data as a struct literal { anotherField:value, ... }
- The field under validation must be present and not empty if the anotherfield
field is equal to the passed value
.
Accelerated validation by removing type checks. ACF chokes on interface checks
Consistency on all validators to ignore null or empty values except the Required
validator
Formatting consistencies
Improve error messages to describe better validation
Get away from evaluate()
instead use invoke()
Bugs
: Fixed lots of wrong type exceptions
Compat
: Remove ACF11 support
A constraint is by definition the following:
The state of being restricted or confined within prescribed bounds.
That is exactly what you will create for specific fields. You will declare the constraints for one or more fields. Each constraint will be composed of one or more validators and validation data. The validation data is defined by the validator and can be of any
type, the default is an empty struct ({}
)
These constraints can then be defined in many locations where cbValidation can read them.
You can define constraints in several locations:
When validating using validate(), validateOrFail()
you have to specify a target, but specifying a constraint in your call is optional.
When you call the validation methods with NO constraints
passed explicitly, then the validation module will discover the constraints using the following:
Lookup your constraints in myTarget.constraints
struct in your target object or struct.
If you specify your constraint parameter as a string, the validator will lookup a shared constraint in your configuration file definitions.
If you specify your constraint parameter as a struct, this struct will directly serve as your set of constraints, so you can specify your constraints on the fly, or specify an alternative set of constraints in your model, e.g User.constraints
vs User.signInConstraints
You can also define constraints a-la-carte. Meaning you can create them on the fly or store them as JSON or somewhere in a service. As long as it is a struct of constraints, that's all the validation methods accept via the constraints
argument.
In this sample we validate the public request context rc
. This sample validates all fields in the rc
. If you need more control you can specify the fields
parameter (default all) or the includeFields
and excludeFields
parameters in your validate()
call.
Shared Constraints
You can optionally register constraints in your ColdBox configuration file under the validation
directive. This means you register them with a unique name of your choice and its value is a collection of constraints for fields in your objects or forms. These will be called lovingly Shared Constraints.
Here is an example:
As you can see, our constraints definition describes the set of rules for a property on ANY target object or form by unique key name.
You can then use the keys for those constraints in the validation calls:
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
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 must be alphabetical ONLY
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 must be in the included list
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 and targetValue. It must return a boolean response: true = pass, false = fail.
The field must be greater than or equal to the defined value
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 field under validation must be present and not empty unless the anotherfield
field is equal to the passed
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 will be passed to the declared closure/lambda to use for validation, must return boolean accept the incoming value and target object, validate(value,target):boolean
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
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:
Within any domain object you can define a public variable called this.constraints
that is a assigned an implicit structure of validation rules for any fields or properties in your object.
We can then create the validation rules for the properties it will apply to it:
That easy! You can just declare these validation rules and ColdBox will validate your properties according to the rules. In this case you can see that a password must be between 6 and 10 characters long, and it cannot be blank.
By default all properties are of type string and not required
You can then use them implicitly when calling our validation methods:
validate(), validateOrFail()
Most likely you will be validating your objects at the controller layer in your ColdBox event handlers. All event handlers, layouts, views and interceptors have some new methods thanks to our module mixins.
You pass in your target object or structure, an optional list of fields or properties to validate only (by default it does all of them), and an optional constraints argument which can be the shared name or an actual constraints structure a-la-carte. If no constraints are passed, then we will look for the constraints in the target object as a public property called constraints
. The validate()
method returns a cbvalidation.models.results.IValidationResult
type object, which you can then use for evaluating the validation.
The return of validate model is our results interface which has cool methods like and can be found under cbvalidation.models.result.IValidationResult
Some of these methods return error objects which adhere to our Error Interface: cbvalidation.models.result.IValidationError
, which can quickly tell you what field had the exception, what was the rejected value and the validation message:
We also have the ability to validate a target object or form with shared constraints from our configuration file. Just use the name of the key in the configuration form as the name of the constraints
argument.
This will validate the object and rc
using the sharedUser
constraints defined in the configuration file: config/Coldbox.cfc
We also have the ability to validate a target object with custom a-la-carte constraints by passing the constraints inline as an struct of structs. This way you can store these constraint rules anywhere you like.
This will validate the object using the inline constraints that you built.
Luis Majano is a Computer Engineer that has been developing and designing software systems since the year 2000. He was born in San Salvador, El Salvador in the late 70’s, during a period of economical instability and civil war. He lived in El Salvador until 1995 and then moved to Miami, Florida where he completed his Bachelors of Science in Computer Engineering at Florida International University. Luis resides in Houston, Texas with his beautiful wife Veronica, baby girl Alexia and baby boy Lucas!
He is the CEO of Ortus Solutions, a consulting firm specializing in web development, ColdFusion (CFML), Java development and all open source professional services under the ColdBox and ContentBox stack. He is the creator of ColdBox, ContentBox, WireBox, MockBox, LogBox and anything “BOX”, and contributes to many open source ColdFusion/Java projects. You can read his blog at www.luismajano.com
Luis has a passion for Jesus, tennis, golf, volleyball and anything electronic. Random Author Facts:
He played volleyball in the Salvadorean National Team at the tender age of 17
The Lord of the Rings and The Hobbit is something he reads every 5 years. (Geek!)
His first ever computer was a Texas Instrument TI-86 that his parents gave him in 1986. After some time digesting his very first BASIC book, he had written his own tic-tac-toe game at the age of 9. (Extra geek!)
He has a geek love for circuits, microcontrollers and overall embedded systems.
He has of late (during old age) become a fan of organic gardening.
Keep Jesus number one in your life and in your heart. I did and it changed my life from desolation, defeat and failure to an abundant life full of love, thankfulness, joy and overwhelming peace. As this world breathes failure and fear upon any life, Jesus brings power, love and a sound mind to everybody!
“Trust in the LORD with all your heart, and do not lean on your own understanding.” Proverbs 3:5
The source code for this book is hosted in GitHub: https://github.com/ortus-docs/cbvalidation-docs. You can freely contribute to it and submit pull requests. The contents of this book is copyright by Ortus Solutions, Corp and cannot be altered or reproduced without author's consent. All content is provided "As-Is" and can be freely distributed.
The majority of code examples in this book are done in cfscript
.
The majority of code generation and running of examples are done via CommandBox: The ColdFusion (CFML) CLI, Package Manager, REPL - https://www.ortussolutions.com/products/commandbox
Flash, Flex, ColdFusion, and Adobe are registered trademarks and copyrights of Adobe Systems, Inc.
The information in this book is distributed “as is”, without warranty. The author and Ortus Solutions, Corp shall not have any liability to any person or entity with respect to loss or damage caused or alleged to be caused directly or indirectly by the content of this training book, software and resources described in it.
We highly encourage contribution to this book and our open source software. The source code for this book can be found in our GitHub repository where you can submit pull requests.
10% of the proceeds of this book will go to charity to support orphaned kids in El Salvador - https://www.harvesting.org/. So please donate and purchase the printed version of this book, every book sold can help a child for almost 2 months.
Shalom Children’s Home is one of the ministries that is dear to our hearts located in El Salvador. During the 12 year civil war that ended in 1990, many children were left orphaned or abandoned by parents who fled El Salvador. The Benners saw the need to help these children and received 13 children in 1982. Little by little, more children came on their own, churches and the government brought children to them for care, and the Shalom Children’s Home was founded.
Shalom now cares for over 80 children in El Salvador, from newborns to 18 years old. They receive shelter, clothing, food, medical care, education and life skills training in a Christian environment. The home is supported by a child sponsorship program.
We have personally supported Shalom for over 6 years now; it is a place of blessing for many children in El Salvador that either have no families or have been abandoned. This is good earth to seed and plant.
This module is a server side rules validation engine that can provide you with a unified approach to object, struct and form validation. You can construct validation constraint rules and then tell the engine to validate them accordingly. You can also create validation profiles to create a more complex validation schema for fields.
Lucee 5+
ColdFusion 2016+
ColdBox validation is based on a way to declaratively specify validation rules for properties or fields in an object or form. The constraints can exist inside of the target object or you can define object and form constraints in your ColdBox configuration file so you can reuse validation constraints or as we call them: shared constraints. You can also create validation constraints on the fly or store them pretty much anywhere you like.
You can then use 2 simple validation methods and report on the results: validate(), validateOrFail()
The ColdBox ORM Module is a professional open source software backed by Ortus Solutions, Corp offering services like:
Custom Development
Professional Support & Mentoring
Training
Server Tuning
Security Hardening
Code Reviews
Because of His grace, this project exists. If you don't like this, then don't read it, it's not for you.
"Therefore being justified by faith, we have peace with God through our Lord Jesus Christ: By whom also we have access by faith into this grace wherein we stand, and rejoice in hope of the glory of God." Romans 5:5
Here are the module settings you can place in your ColdBox.cfc
by using the validation
settings structure:
Important: The module will register several objects into WireBox using the @cbvalidation
namespace. The validation manager is registered as ValidationManager@cbvalidation
In cbValidation 1.5 we introduced the validateOrFail()
function. This function works in similar manner to the validate()
method, but instead of giving you the results object, it throws an exception of type ValidationException
.
So your validation fails, where are the results? In the exception structure under the extendedInfo
key. We store the validation results as JSON in the extended info and then you can use them for display purposes:
Key
Type
Required
Default
Description
manager
instantiation path or WireBox ID
false
cbValidation.models.ValidationManager
You can override the module manager with your own implementation. Just use an instantiation path or a valid WireBox object id.
sharedConstraints
struct
false
{}
This structure will hold all of your shared constraints for forms or/and objects.
Incoming Target
Validation Fails
Result
Object
false
Returns the same object
Object
true
Throws ValidationException
Struct
false
Returns the structure with ONLY the fields that were validated from the constraints
Struct
true
Throws ValidationException
cbValidation 2.x series introduced the ability to validate using field profiles
. This will allow you to define all your constraints but also define field profiles where you can define only certain fields to be validated if the profile name is used.
This is using the this.constraintProfiles
struct literal:
The key is the name of the profile and the value is a list of the fields to validate if the profile is targeted for validation.
Every validation method: validate(), validateOrFail()
has a profiles
argument. You can then pass one or more to the argument so you can validate 1 or more profiles:
The unique
validator is part of the cborm module. So make sure that the cborm
module is installed first.
The validator is mapped into WireBox as UniqueValidator@cborm
so you can use in your constraints like so:
If you will be using this validator, then the name of the property has to be EXACTLY the same case as the constraint name. To do this, use single or double quotes to declare the constraint name. Please see example below.
This is done because we build the appropriate SQL to make sure the property name and the field name match.
If you are using i18n (Internationalization and Localization) in your ColdBox applications you can also localize your validation error messages from the ColdBox validators.
Info You do not need to install the cbi18n
module. This module is already a dependency of the cbvalidation
module.
You will do this by our lovely conventions for you resource bundle keys:
We also setup lots of global {Key}
replacements for your messages and also several that the core constraint validators offer as well:
{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
{targetName}
- The name of the user, shared constraint or form
{DiscreteValidator}
- operation, operationValue
{InListValidator}
- inList
{MaxValidator}
- max
{MinValidator}
- min
{RangeValidator}
- range, min, max
{RegexValidator}
- regex
{SameAsValidator}
, {SameAsNoCaseValidator}
- SameAs
{SizeValidator}
- size, min, max
{TypeValidator}
- type
The module will register several objects into WireBox using the @cbvalidation
namespace. The validation manager is registered as ValidationManager@cbvalidation
, which is the one you can inject and use anywhere you like.
Remember you have the mixins available to you in your handlers/interceptors/layouts and views
You can also tell the validation manager to ONLY validate on certain fields and not all the fields declared in the validation constraints.
This will only validate the login
and password
fields.
You can also use the following arguments:
includeFields
: The fields to include in the validation ONLY
excludeFields
: The fields to exclude in the validation
After validation you can use the same results object and use it to display the validation errors in your client side:
If you want more control you can use the hasErrors()
and iterate over the errors to display:
You can even use the results object in your views to get specific field errors, messagesbox, etc.
The following are some common methods from the validation result object for dealing with errors:
getResultMetadata()
getFieldErrors( [field] )
getAllErrors( [field] )
getAllErrorsAsJSON( [field] )
getAllErrorsAsStruct( [field] )
getErrorCount( [field] )
hasErrors( [field] )
getErrors()
The API Docs in the module (once installed) will give you the latest information about these methods and arguments.
If the core validators are not sufficient for you, then you can create your own custom validators. You can either leverage the udf
validator and create your own closure/lambda to validate inline or create a reusable validator CFC
If you use the udf
validator, then you can declare your validation inline. Just create a closure/lambda that will be called for you at the time of validation. This closure/lambda will receive all the following arguments and MUST return a boolean indicator: true => passed, false => invalid
value
: The value to validate, can be null
target
: The object that is the target of validation
You can also create a reusable CFC that can be shared in any ColdBox app as a validator. Create the CFC and it should implement our interface which can be found here: cbvalidation.models.validators.IValidator
and it specifies just two functions your own validator must implement: getName(), validate():
Here is a sample validator:
You can use them in two approaches when defining them in your constraints:
Use the validator
constraints which points to the Wirebox ID of your own custom validator object. Please note that if you use this approach you will not be able to pass validation data into the validator.
Use the WireBox ID as they key of your validator. Then you can pass your own validation data into the validator.
Approach number 2 is much more flexible as it will allow you to declare multiple custom validators and each of those validators can receive validation data as well.
If you don't have any validation data to pass to a validator, just pass an empty struct ({}
) or an empty string
If you would like to adapt your own validation engines to work with ANY ColdBox application you can do this by implementing the following interfaces:
Validation Manager : Implement the cbvalidation.models.IValidationManager
. Then use the class path in your configuration file so it uses your validation manager instead of ours.
Validation Results : Implement the cbvalidation.models.result.IValidationResult
, which makes it possible for any ColdBox application to use your validation results.
Validation Error : Implement the cbvalidation.models.result.IValidationError
, which makes it possible for any ColdBox application to use your validation error representations.
Then map it in your configuration file: