Functional tests for Validate, LiveValidation, and LiveValidationForm classes (standalone version)
Presence will fail if there is no value entered in the field.
Enter the field then click somewhere else:
Format in its normal state will fail if the value DOES NOT match the regular expression.
Should contain the phrase “live”, anywhere, in any case:
Format with parameter negate set to false will fail if the value DOES match the regular expression (does the opposite of the normal Format).
Should NOT contain the phrase “live”, anywhere, in any case:
This kind of validation is concerned with numbers. It can handle scientific numbers (ie. 2e3, being 2000), floats (numbers with a decimal place), and negative numbers properly as you would expect it to throughout, both in values and parameters.
This example will check if the value provided is a number, or can be converted into a number successfully (ie from a string - the value of a text input is a string). This is performed on every type of Numericality validation automatically, but can be used in its simplest form like this, if you only want to make sure the value entered is a number.
Should be a number:
This example will check that the number supplied is, or equates to, an integer (ie. no decimal places).
Should be an integer:
This example will check that the value is the same as, or equates to, a specific number that you supply.
Should be 2000 (or scientific representation of it, 2e3):
This example will check that the value is more than or equal to a minimum number that you supply.
Should be 2000 or higher (or scientific representation of it, 2e3):
This example will check that the value is less than or equal to a maximum number that you supply.
Should be 2000 or lower (or scientific representation of it, 2e3):
This example will check that the value is a number that falls within a range that you supply. This is done supplying both a ‘minimum’ and ‘maximum’.
Should be between 2000 and 2003:
Most of the above parameters can be combined, the only execption being that you cannot combine ‘is’ with ‘minimum’ or ‘maximum’, if this is done ‘is’ will take precedence. This example will check that the value is a number that falls within a range that you supply, and that it is an integer. This is done supplying both a ‘minimum’ and ‘maximum’, and true for ‘onlyInteger’.
Should be between 2000 and 2003, and also be an integer:
Length is concerned with the number of characters in a value. You can do various validations on it, like check it is a specific length, less than or equal to a maximum length, greater than or equal to a minimum length, or falls within a range of lengths.
This example will check that the value is the exact length of which you supply.
Should be 4 characters in length:
This example will check that the value is more than or equal to a minimum length that you supply.
Should be 4 or more characters in length:
This example will check that the value is less than or equal to a maximum length that you supply.
Should be 4 or less characters in length:
This example will check that the value is a number that falls within a range that you supply. This is done supplying both a ‘minimum’ and ‘maximum’.
Should be between 4 and 8 characters in length:
Inclusion lets you validate against a list of allowed values. You can do an exact match or a partial match.
This example will check that the value is the same as any in your allowed values.
Should be “cow”, “pigeon”, or “giraffe”:
This example will check that the value is the same as any in your allowed values, treating strings as case insensitive. Allow case insensitivity by setting the ‘caseSensitive’ parameter to be false.
Should be “cow”, “pigeon”, or “giraffe”, using any case:
This example will check that any part of the value matches something in the allowed list. Allow this by setting the ‘partialMatch’ parameter to be true.
Should contain “cow”, “pigeon”, or “giraffe” somewhere in your entry:
This example will check that the value is the same as any in your allowed values, treating strings as case insensitive.
Should contain “cow”, “pigeon”, or “giraffe” somewhere in your entry, using any case:
Exclusion lets you validate against a list of values that are not allowed. You can do an exact match or a partial match.
This example will check that the value is not the same as any in your allowed values.
Should not be “cow”, “pigeon”, or “giraffe”:
This example will check that the value is not the same as any in your allowed values, treating strings as case insensitive. Allow case insensitivity by setting the ‘caseSensitive’ parameter to be false.
Should not be “cow”, “pigeon”, or “giraffe”, using any case:
This example will check that no part of the value matches something in the disallowed list. Allow this by setting the ‘partialMatch’ parameter to be true.
Should not contain “cow”, “pigeon”, or “giraffe” anywhere in your entry:
This example will check that no part of the value matches something in the disallowed list, treating strings as case insensitive.
Should not contain “cow”, “pigeon”, or “giraffe” anywhere in your entry, using any case:
Acceptance lets you validate that a checkbox has been checked.
I accept that LiveValidation is the validation of my dreams:
This is used to check that the value of the confirmation field matches that of another field. The most common use for this is for passwords, as demonstrated below, but will work just as well on other field types.
Enter a password:
Confirm password:
The email validation is not a real kind of validation in the sense that it actually uses the Validate.Format function to do its validation. It is essentially a validation that is done often enough to merit its own function so you don’t have to remember the long regular expression and custom failureMessage each time you want to validate an email.
It also serves as an example for the more adventurous of you, who want to make your own library of custom validations that you will use often. These will most likely include things like postcodes, telephone numbers, dates etc. which vary far too widely to include here, but it was felt that email addresses are generic enough to warrant inclusion, so here you go.
Should be an email address:
Most of the time, you will want to combine multiple types of validation on a single field. As your user is given real-time feedback, it would also be good to be able to specify an order in which they fail, so that the most appropriate message is displayed to avoid any confusion.
LiveValidation makes this easy. You simply keep adding validations to the same LiveValidation object, and they will fail in the order they are added.
The most usual combination you will use is Validate.Presence with one or more other validations, as only Validate.Presence, Validate.Confirmation and Validate.Acceptance will fail and display their message on an empty field. This is because it is common to have fields which are optional, but if the user decides to provide information, then it must be less than a certain length etc. Therefore if you want to ensure a field is filled in, you must add a Validate.Presence, then if you require any more validation types add them too.
You have already seen an example of a composite validation in the homepage example. The following example checks that the field is not empty, then checks that it is an email address, and then makes sure it is between 10 and 20 characters long.
Enter an email address (10 - 20 characters long):
When a LiveValidation object is instanciated, if it finds it is a child of a form, it will automatically attach itself to the submit event of the form, so when it is submitted, validation on all the LiveValidation objects inside it will be performed automatically. If any of the validations fail it will stop the form submitting.
You can also specify the onlyOnSubmit option to be true when you create the LiveValidation object to make it only validate when the form is submitted. This is demonstrated in the following example.
Note also that the email field has no validation that it is present, therefore if this is not filled in the form will still be valid, as it will be treated as an optional field.
There are various options that can be overridden when instatiating a LiveValidation object.
Setting onlyOnBlur to be true will mean the validation will only be run when the field loses focus.
Must be filled in:
Setting wait to a number (of milliseconds), will mean that the validation will not run until your chosen time after the last keystroke ocurred. This allows the user to type in their data without saying it has failed before they have had the chance to finish, by which time it may be valid, but it will still be validated without having to leave the field.
Must be filled in, and at least 10 characters long:
Setting onlyOnSubmit to be true will cause validation to be run on a field, only when the form it belongs to is submitted.
LiveValidation can be used with various input elements (text, password, checkbox), textarea elements, and select elements.
This example will check that the value is filled in.
Must be filled in:
This example will check that the value is the same as the previous text field.
Must be same as the previous text field’s value:
This example will check that the checkbox is checked.
Accept by checking the box:
This example will check that the value is filled in.
Must be filled in:
This example will check that the value is not the same as any in your allowed values.
Should be “Hello world”, or “Howdy”:
This example will check that the value is filled in.
Must be filled in: