How does Jel.FormValidator work?

Jel.FormValidator is a JavaScript class which adds flexible form validation behaviour to the XHTML form element it is applied to. When a form is submitted the validator marks any invalid fields (and their labels) as culprit fields (meaning that they were responsible for validation not succeeding).

For each culprit field, an error message is automatically generated (these can be overridden) describing to the user what they need to do to fix the problem; these error messages are then collectively displayed in the validation results, which can be via a simple alert box, or inside a selected XHTML element.

To discover how to validate each field in the form, the validator looks for special strings in their class attributes termed validation classes, which can describe:

The acceptable syntax for these validators is quite vast, and a detailed discussion can be found in the API page for Jel.FormValidator. To give you an idea of the kind of things you can validate fields on refer to the examples below.

Validation Class Examples

Validation Class Description
required field is required (treated as a special case)
int-neq-0 integer not equal to 0
int-ge-4 integer greater than or equal to 4
int-le-10 integer less than or equal to 4
int-range-4:8 integer between 4 and 8, non-inclusive (:)
int-range-4::8 integer between 4 and 8, inclusive (::)
float-range-4p5:20p1 floating point, between 4.5 and 20.1
neq-password not equal to the word "password" case-sensitive
eq-password-field equal to the value of the field with ID "password" (useful for confirm password)
gt-ci-a string, greater than "a", case-insensitive
lt-b string, less than "b", case-sensitive
date-ge-20000101-us US formatted date (mm/dd/yyyy) sometime after the turn of the millenium (1st Jan 2000)
date-range-20050201::20070301-uk UK formatted date between 01/02/2005 and 01/03/2007, inclusive
date-future-uk UK formatted date (dd/mm/yyyy) in the future
date-past-us US formatted date (dd/mm/yyyy) in the past

Thus, if I wanted to validate a field called quantity which is a required integer between 1 and 5 inclusive, then my markup for the field could look like:

Or say I wanted to validate a field called date of birth which is a date in the past in UK format (dd/mm/yyyy), then my markup for the field could look like:

And if doing this kind of validation so easily isn't enough, look at the automatic error messages that get generated for these fields:

Quantity must be a whole number between 1 and 5 inclusive
Date of Birth must be a date in the past, in the format dd/mm/yyyy

(and remember, these can be overridden)

Setting up your XHTML forms - encouraging accessibility

The JEL Form Validator is easy to integrate, provided you build your XHTML forms the accessible way - for each field, attach a <label> tag with the for attribute equal to the ID of the field. Note that this usually means having the same name and id attributes for each field, so that they can be attached to a label, and they are submitted correctly. The example code below demonstrates this:

If you do this, not only have you made your forms more accessible to everyone, but the Form Validator can use this information to build automatic error strings and also mark the labels attached to each field as culprits in the validation.

The problem with radio button and checkbox field sets

When setting up checkbox and radio buttons in field sets, each field cannot be given the same id and name, since the name attribute must be the same for each field in the set, but you cannot have two elements with the same id on a page. My usual practice is to append the value to the name to form the id, which works well as a standard practice (JEL does NOT assume this though):

A further problem with radio button and checkbox field sets is that they usually need two types of labels: one for the overall group itself, and one for each radio button or checkbox. The seemingly correct way to achieve this is to use a fieldset tag, and use the legend tag inside to define the label for the set, i.e.:

The problem here is that fieldsets cannot be flexibly styled with CSS across all browsers - you are stuck with the fieldset box and/or legend positioning. I like to use a p tag to describe the field set before each field is declared, which should help screen readers out.

For field sets, the FormValidator still needs to know where it can get the label from. It does this by looking for an element with an id that is the name of each control in the set, prefixed with for-, as shown in the complete example below:

Note that you can still use the fieldset tag if you want to, just give the legend the ID as described.

View some examples of using the Form Validator here.

All Site Content © 2007 Travis Hensgen.  Icons by IconBuffet and FamFamFam.