Tigra Form Validator is professionally designed JavaScript component performing client-side form validation of any complexity. The script supports most of the data types used in online forms and it can be easily extended with any custom types. Offering rich feature set and great browser compatibility Tigra Form Validator PRO is suitable for any HTML form imaginable so visitors benefit from uniform, intuitive and friendly client-side validation.
Tigra Form Validaror PRO can work with any browser capable of generic DHTML.
Here is a table of the application compatibility:
| Platform | Browser | |||||
|---|---|---|---|---|---|---|
| MS IE | Netscape | Mozilla | Opera | Safari | ||
| Windows 95/98/ME/2000/XP | 4.0+ | 4.08+ | 0.9+ | 6.0+ | n/a | |
| Mac OS 8/9/X | 5.0+ | 4.7+ | 0.9+ | 6.0+ | 1.0+ | |
Tigra Form Validator PRO distribution package contains the following files:
Where ? and * are wildcards for single character and substring respectively.
First thing to be done to the document where Tigra Form Validator PRO will be used then is attaching product core script to a header with appropriate tag:
<head> <!-- some header data --> <script language="javascript" src="validator.js"></script> </head>
To validate fields of a HTML form Tigra Form Validator PRO script has to create a JavaScript object instance for that form. Such a creation is done with a JavaScript line called "constructor call". So the number of constructor calls in a HTML document should be equal to a number of HTML forms the script is desired to serve.
Here is sample Tigra Form Validator PRO constructor call:
var v = new validator('test', o_fields, o_config)
The constructor is supplied with 3 parameters:
| Index | Description | Type | If required | In above sample |
|---|---|---|---|---|
| 1 | a string form name inputs to fields of which are to be validated by the script | string | yes | 'test' |
| 2 | a JavaScript structure or a reference to a structure describing fields inputs of those are to be validated | object | yes | o_fields |
| 3 | a JavaScript structure or a reference to a structure describing validator settings | object | no | o_config |
The constructor is a function returning a reference to created object instance once being called. It is necessary to store that reference in a variable because it will be used then. In above sample such variable name is v.
Note that all constructor calls have to be placed only after the place where product core script is attached to the document.
Last step of adding Tigra Form Validator PRO to the document is handling on form submit event. Validator object instance created by the constructor has a method of exec(). That method call code has to be added to onsubmit form tag modifier value. Turning back to the above sample of validator constructor call, if having validator object instance named as v, the opening tag of test HTML form will look like the following:
<form name="test" ... onsubmit="return v.exec()">
Form fields inputs of those you would wish to validate are described with Fields Describing Structure, a JavaScript structure that contains names and attributes of those fields. Each form field you need to validate corresponds to one record of the structure - a descriptor - named exactly as that field. A descriptor is made up of a key (descriptor name) - a string containing corresponding field name, a colon (:) and a structure of field attributes:
<field name> : {<structure of field attributes>}
All descriptors are enclosed in curly brackets ({}) and separated with commas (,).
To tell validator script in which way an input of the field has to be validated each descriptor contains field attribute structure. The structure is a set of field attribute descriptors enclosed in curly brackets ({}) and separated with commas (,). Each field atribute descriptor consists of a name (string), colon (:) and value:
<field name> : {
// structure of field attributes
<attribute 1> : <value of attribute 1>,
<attribute 2> : <value of attribute 1>,
....
// any attributes here
....
<attribute n> : <value of attribute n>
}
Below is a table of field attribute descriptors currently supported:
| Name (key) | Description (regarding corresponding field) | Values | |
|---|---|---|---|
| accepted | default | ||
| l | Field label to refer the field in messages | a string | (required attribute) |
| r | If the field is required | boolean | false |
| f | Field format the input has to meet | predefined format name, a regular expression or a function |
(is not used) |
| t | id of a HTML element to highlight if input is not valid | a string | (is not used) |
| m | A name of another form field this field input must match. Usefull for password copies | a string | (is not used) |
| mn | The least number of characters the field can contain | a positive integer number | (is not used) |
| mn | The most number of characters the field can contain | a positive integer number | (is not used) |
Tigra Form Validator PRO supports a feature of checking if form field input meets certain pattern (format). There are 3 ways of supplying format for fields:
| Format name | Description |
|---|---|
| alpha | A string of characters of Latin alphabet, a dot (.) and a hyphen (-) |
| alphanum | Alphanumeric characters and an underline (_) |
| unsigned | Unsigned integer number |
| integer | An integer number |
| real | A number with a decimal point |
| E-mail address format | |
| phone | Phone number consisting of digits, spaces ( ), dots (.) and hyphens (-) |
| date | Date value formatted as DD-MM-YYYY |
| time | Time value formatted as HH:MM:SS |
Once field format is supplied as a user-defined function, flexible messaging option becomes available. Such a function can return an alternative error message instead of false value. So there is a way to create complex conditional field format checkings and supply adequate messaging for each case.
Suppose there is a form named myForm containing 3 fields: first_name, last_name and email:
<form name="myForm"> <input type="text" name="first_name"><br> <input type="text" name="last_name"><br> <input type="text" name="email"> </form>
We have to set up the validator to check if:
Here is sample Fields Describing structure for the case:
var myFields = {
// first_name field description line (descriptor)
'first_name' : {
// the field is required
'r' : true,
// field format: first letter must be capital
'f' : /^[A-Z]+/
}
// last_name field description line (descriptor)
'last_name' : {
// the field is required
'r' : true,
// field format: first letter must be capital
'f' : /^[A-Z]+/,
'mn' : 3
},
// email field description line (descriptor)
'email' : {
// field format: predefined
'f' : 'email',
'mn' : 3
}
}
Tigra Form Validator PRO behavior can be controlled by Validator Setting Structure, the third optional parameter of the constructor. Validator Setting Structure is a JavaScript structure consisting of records enclosed in curly brackets ({}) and separated with commas (,). Each record controls certain validator behavior aspect and contains a key (string name), a colon (:) and a value. Below is a table of keys currently supported by the structure and their meanings.
| Name (key) | Description (regarding corresponding field) | Values | ||
|---|---|---|---|---|
| accepted | default | |||
| alert | Defines what messaging options should be allowed for the form | An integer number from 0 to 31 or a function | 0 | |
| alert_class | An array of style classes to be applied to highlight and unhighlight form field labels on fill error | Array of strings | (is not used) | |
| 0 | Name of a style class to be applied to highlight form field labels on fill error | String | (is not used) | |
| 1 | Name of a style class to be applied to unhighlight (make of normal outlook) form field labels | String | (is not used) | |
| to_disable | A list of names of form fields to be blocked on successfull submit. Usefull to prevent multiple form posts before load | Array of strings | (is not used) | |
| messages | A structure of templates for messages validator gives out | an object | see below | |
While processing a form Tigra Form Validator PRO prepairs a set of messages for the one working with the form. Those messages can be shown in 5 operational points or processed by a user-defined function. Each moment the messages that can be shown has its number equivalent:
| Messaging point | Equivalent |
|---|---|
| Form fill error message dialog box | 1 |
| Form fill error message HTML box | 2 |
| Validator script set up error message dialog boxes | 4 |
| Form successfull validation message HTML box | 8 |
| Form submit confirmation message box | 16 |
Taking a value of certain equivalent or summarizing them and assigning as a value of alert key of Validator Setting Structure switches corresponding messaging options on. For instance:
// another Setting Structure keys here 'alert' : 1 + 4 + 16 // another Setting Structure keys here
switches form fill error message dialog box, script set up error message dialog boxes and form submit confirmation message box on.
If HTML boxes are used to contain messages validator script looks in the document for a HTML element that has an id modifier equal to "error_" plus the corresponding form name and passes all messages as inner HTML content for that element. For instance, if your form has a name of "my_form", just insert
<div align="center" id="error_my_form" style="display:block;"></div>
code in your document source and that container will be filled with the messages automatically.
To disable messaging just set alert key to 0 or omit it.
In a case when complex or another than predefined message proccessing is needed there is a way to define a message processing function declaration or reference as a value for the alert key. The function is supplied 3 parameters when called:
1 - message string to be processed; if there are several messages separator is "\n" character,
2 - message string to be processed; if there are several messages separator is "<br>" tag,
3 - a reference to a HTML container where messages can be put out
All messages validator can give out are built on templates. Templates are strings containing variables to be replaced by the apllication with certain values before displaying. Here is a table of all variables can be used inside message templates:
| Variable | Origin | Will be replaced with |
|---|---|---|
| %form% | form | name of the form this validator instance is attached to |
| %n% | name | name of the field the message is about |
| %attr% | attribute | name of field attribute the message is about |
| %t% | tag | container tag id specified as t field attribute |
| %m% | match | name of a field value of that has to match the value of the field the message is about |
| %l% | label | label of the field the message is about |
| %v% | value | value of the field the message is about |
| %mn% | minimum | minimum length of the field the message is about |
| %mx% | maximum | maximum length of the field the message is about |
| %ml% | match label | label of a field value of that has to match the value of the field the message is about |
| %error% | error | all error messages joined together with <br> tag |
Note: all field attributes become template variables by just enclosing their names in %% signs
Tigra Form Validator PRO message templates are predefined but can be easily changed if needed. There are 4 groups of message templates in the application. Such a division is based on a messages purpose and hence allows to redefine only one or several groups leaving rest messages unchanged (default). Below is a table of messages by their groups:
| Index | Description | Predefined value | Variables available |
|---|---|---|---|
| "setup" group | |||
| 0 | First parameter of validator constructor call is absent | No form name passed to validator construction routine | %form% |
| 1 | Second parameter of validator constructor call is absent | No array of "%form%" form fields passed to validator construction routine | %form% |
| 2 | The HTML form the validator instance is attached to can not be found in the document | Form "%form%" can not be found in this document | %form% |
| 3 | HTML container to put messages into can not be located in the document | Can not find area for error message box (id="error_%form%") |
%form% |
| 4 | One of required field attributes is absent | Incomplete form field description entry (index is %key%). Attribute "%attr%" is missing | %form%, %attr% |
| 5 | One of form fields described can not be found | Can not find form field "%n%" in the form "%form%" | %form%, %n% |
| 6 | There is no container tag for a field label to highlight | Can not find label tag (id="%t%") | %form%, %n%, %t% |
| 7 | The field specified as a match for this field can not be found in the document | Can not verify match. Field "%m%" was not found | %form%, %n%, %m% |
| "fill" group | |||
| 0 | Required form field has not been filled | "%l%" is a required field | %form%, %n%, %l% |
| 1 | Value of the field does not meet the pattern set for it | "%v%" is not valid value for "%l%" | %form%, %n%, %l%, %v% |
| 2 | Value of the field is shorter than the minimum limit for it | Value for "%l%" must be %mn% characters or more | %form%, %n%, %l%, %v%, %mn%, %mx% |
| 3 | Value of the field is longer than the maximum limit for it | Value for "%l%" must be no longer than %mx% characters | %form%, %n%, %l%, %v%, %mn%, %mx% |
| 4 | Field value does not match the value of the field set to be its copy | "%l%" must match "%ml%" | %form%, %n%, %l%, %v%, %ml% |
| "boxes" group | |||
| 0 | Template to wrap error messages in when putting them into HTML box | <table cellpadding="0"
cellspacing="0" border="0" width="100%">
<tr><td bgcolor="#CCCC33">
<table cellpadding="15"
cellspacing="1" border="0" width="100%"><tr>
<td bgcolor="#FFFFCC"
style="color: red;">%error%</td>
</tr></table>
</td></tr>
<tr><td height="10"> </td></tr>
</table> |
%form%, %error% |
| 1 | Successfull validation message | <table cellpadding="0" cellspacing="0"
border="0" width="100%">
<tr><td bgcolor="#CCCC33">
<table cellpadding="15" cellspacing="1"
border="0" width="100%"><tr>
<td bgcolor="#FFFFCC"
style="color:green;
font-weight:bold;">Submitting ...</td>
</tr></table>
</td></tr>
<tr><td height="10"> </td></tr>
</table> |
%form% |
| "confirm" group | |||
| 0 | Form post confirmation question message | The "%form%" form is to be submitted. Are you sure? | %form% |
There is a way to change certain message in a group or whole group of messages. To do so specify a value for messages key of Validator Setting Structure. The value should describe a JavaScript object fields of that are set in correspondence to groups message of those are needed to be changed. Messages inside each groups are separated with commas (,) and enclosed in square brackets ([]). The message to be changed has to take a place between square brackets exactly equal to the index of the above table if zero-based. All places before if are needed to left unchanged has to be filled with null value.
For example, there is a need to change a message of '"%v%" is not valid value for "%l%"' to '"%v%" is not correct answer for %l%' and set submit confirmation question message to "Do you agree to post %form% form?". Here is a corresponding fragment of Validator Setting Structure:
// another Setting Structure keys here 'messages' : { 'fill' : [ null, // our message is on 1-st (zero-based) place '"%v%" is not correct answer for %l%' ], 'confirm' : [ 'Do you agree to post %form% form?' ] } // another Setting Structure keys here
There is a way of more complex messaging in Tigra Form Validator PRO. The product supports a feature of assigning JavaScript functions instead of message templates. This allows any additional checking and/or data processing before displaying a message.
In other words the code to be assigned as a message template to appropriate subkey of messages key of Validator Settings Structure can be a function declaration or a function reference. Such a function will be called at the moment before Validator scripts cunstructs message string template. It receives a name of the current form as its only parameter. The value the function returns is considered to be a template for the message this function replaces. So there is a way to take into account any conditions JavaScript can reach while making message templates up.
For example, we have a mail form and subject fields named f_subj in it. The field is not required, but there is a need to ask a user if he(she) wishes to send the mail with blank subject field. The solution is to check if the f_subj is empty before displaying form confirmation message.
Here is code fragment for confirmation message template replaced with a function:
// another Setting Structure keys here 'messages' : { 'confirm' : [ // our message is on 0-th (zero-based) place function (s_form) { return document.forms[s_form].f_subj.value // if the subject is empty? ? 'Do you wish to send the mail with an empty subject field?' : 'You are about to send your mail. Continue?' } ] } // another Setting Structure keys here
One Regular Tigra Form Validator script license gives the right to use one copy of the script file (validator.js) within single domain boundaries.
| First Site URL | Second Site URL | Number of Licenses Required |
|---|---|---|
| http://www.domain.com/site_1/ | http://www.domain.com/site_2/ | one |
| http://www.domain1.com/ | http://www.domain2.com/ | two |
| http://subdomain1.domain.com/ | http://subdomain2.domain.com/ | two |
Developer license gives the right to include unlimited number of Tigra Form Validator PRO instances in the products of license owner. Such kind of license is obtained automatically by those who has 9 or more regular licenses.
As owner of the Tigra Form Validator PRO license You are allowed to configure the script in any possible way for use in Internet (public), Intranet (corporate) or offline application, however You are strictly NOT allowed (unless specifically authorized by SoftComplex.com) to:
You are entitled to free product upgrades and technical support for at least one year from the date of purchase. Technical support includes answers to script related questions via e-mail and/or Internet instant messaging services. Full validator customization services are provided on customer's request at additional charge.
Should you violate these Terms and Conditions or any other rights of SoftComplex Inc., SoftComplex Inc. reserves the right to pursue any and all legal and equitable remedies against you without limitation.