Validanguage Overview

Documentation Menu:

Validanguage Overview
Advanced Validanguage Features
Frequently Asked Questions
Validanguage API Docs
Support / Contact Info
  1. Introduction
  2. Installing Validanguage
  3. API #1 -- The Comment-based API
  4. List of Options Available in the Comment-based API
  5. Available Custom Validation Functions
  6. CSS Classes and IDs Used by Validanguage
  7. Changing Settings Globally
  8. Transformations
  9. API #2 -- The Object API

Introduction

Validanguage is a form validation framework supporting a number of powerful and easy-to-configure features. These features can be enabled on a web form via two different APIs*. Each API will be discussed below, beginning with the Comment-based API, which is recommended for those with limited javascript experience.

*API = Application Programming Interface, which is simply a fancy term meaning a computer language which is used to describe something -- in this case, validation rules.

Installing Validanguage

Download validanguage, upload it to your web server then include it on your web page by adding a script tag in the <head> section of your page:

<script type="text/javascript" src="/path/to/validanguage.js"></script>

Once the validanguage.js file has been included on your web page, the next requirement is to ensure that all form elements on the web page for which you intend to load validation rules includes an id attribute. This id attribute is used to specify which validation functions should be associated with which form elements. Each id should be unique (appearing only once on the web page). For example:

<input type="checkbox" name="termAgreement" id="termAgreement" value="1" />

It is also recommended that every <form> tag on your webpage also include an id (although, strictly speaking, this is only required if you want to have different settings apply to different forms).

Once you have the javascript installed on your page, and every item in your form has a unique id added to the HTML, the final step is to use one of the APIs described below to load the specific validation requirements for each form field.

API #1 -- The Comment-based API

The comment-based Validanguage API is the API which is recommended for anyone who is not familiar with javascript object notation. Even if you are familiar with javascript objects, you may find the Comment API to be easier to use and simpler.

The Comment API, as its name implies, is placed on your web page inside HTML comments and uses the same syntax as HTML. The best way to describe the Comment API is to provide an example. Let's assume you have a checkbox with an id of "termAgreement" and you want to make the checkbox required so that the form cannot be submitted unless the checkbox is checked. You could load this simple validation rule by placing the following anywhere inside the <body> section of your web page:

<!-- <validanguage target="termAgreement" required="true" errorMsg="You must agree to the terms before submitting this form"> -->

Let's break down this example. All HTML comments are started with <!-- and ended with -->. Next, <validanguage appears within the comment to indicate that what follows is a Validanguage API statement. target="termAgreement" indicates which form element the rest of the statement is describing. required="true" tells the validanguage library that this form element needs to be filled out, checked, or selected before the form in which it appears will be allowed to submit. Finally, the errorMsg item provides the text which will be shown inside the error message which will be displayed to the user.

That's pretty much all there is to the Comment API. There are a several additional features I'll mention briefly.

Some attributes, such as target, allow you to specify more than one value, by placing commas in between each. For example, target="termAgreement, ageVerify" would load all the validation statements included inside the Validanguage Comment for both the termAgreement and the ageVerify form fields.

Although quotation marks are used to surround the values in all the examples we've seen so far, you can actually use any character you want as the delimiter (unlike in actual HTML). This comes in handy if you need to use quotation marks inside the value itself. For example, if your errorMsg contained quotation marks, you could define the errorMsg using the dollar sign as the value delimiter: errorMsg=$You must complete the "Education" section before continuing.$

Just like actual HTML, the order in which attributes in a Validanguage comment appear is irrelevant. Although the target attribute determines what form fields all the other attributes will apply to, the target attribute can appear first, second, third, or even last within the comment.

Unlike actual HTML, validanguage comments are case-sensitive. Be sure to use the proper capitalization.

Finally, be sure that you only include 1 validanguage tag per HTML comment. If you include more than one Validanguage tag in the same comment, only the first one will be processed. (Note: Multiple tags per comment can be enabled by changing the validanguage.settings.commentDelimiter value. If you do enable this, you will need to properly close all your Validanguage tags with a "/>" at the end, per XHTML Strict standards).

List of Options Available in the Comment-based API

Basic Options

target="dateField" -- As explained above, the target defines which form fields the subsequent rules will apply to.

validations="validanguage.validateDate, someCustomFunction" -- This example would load 2 validations for the form target(s). The first function mentioned is Validanguage's built in function for validating dates. The second function in this example is a custom function that the end user defined elsewhere.

onerror="showError" -- If you wish to display form error messages on the page itself using a custom function, you can use the onerror option to name a custom function to display the message somewhere on your page. Any function included in the onerror handler will be executed in the scope of the element which failed the validation, with the this keyword referring to the form element. This enables you to use "this.id" to retrieve the id of the form element from inside the showError() function ( which would return "dateField" in this example ). Additionally, the error message assigned to the failed validation is passed to the function as its first argument. This enables you to write custom functions yourself such as the following:
function showError( errorMsg) { document.getElementById( this.id + '_errorSpan' ).innerHTML = errorMsg; }
You could use a function similar to the function above to put the error message in <span> or <div> tags throughout your form, if the id's for the error message areas match the ids of the form field -- in the showError function above, the error message span's would all end in "_errorSpan", such as "dateField_errorSpan"

By default, onerror is set to validanguage.showError, which creates/unhides a div to show the error message.

onsuccess="removeError" -- The onsuccess function is run on each form element being validated if it passes the validation. This can be used to set a custom function to remove error messages which are assigned using the onerror handler. For example, the removeError function might look something like:
function removeError( ) { document.getElementById( this.id + '_errorSpan' ).innerHTML = ''; }
By default, onsuccess is set to validanguage.hideError.

errorMsg="This field did not validate" -- You can assign a custom error message to the form target validation functions using the errorMsg setting.

showAlert="true" -- Allows you to control whether or not a javascript alert() prompt is shown when a validation fails. By default, alerts are not shown.

focusOnError="true" -- Setting this to true will make the form field which failed validation receive focus when the validation fails. Be careful when using this option in combination with showAlert="true" and onblur="true". Using all 3 settings together is not recommended, as it may lead to an infinite number of alert messages which the user can't get rid of.

onsubmit="hideSubmitButton" -- This option allows you to specify a custom function which will be run when the form is submitted. This is useful for hiding the submit button, among other things, to prevent users from clicking it a second time. This can also be used to submit a form via AJAX instead of the normal POST/GET form. These functions are referred to as "onsubmit form transformations" and are discussed in more detail below.

Event Handlers

When using the event handlers below to define which events should trigger validations, it is worth noting that if you want to define 2 validations functions for the same form field which are triggered using different event handlers, you would simply create 2 validanguage comment tags: 1 for each function which references the desired event handler(s).

onsubmit="true" -- Including onsubmit="true" (which is the default) will run any validations or other settings referenced inside the validation comment when the form is submitted. If the validation fails, the form will not be submitted. You can disable these validations from running onsubmit via onsubmit="false".

onblur="true" -- Runs validations when the form field loses focus, such as via the user pressing Tab or clicking on a different field.

onchange="true" -- Runs validations when the form field onchange event is fired -- mostly useful for select boxes.

onclick="true" -- Runs validations when the form field is clicked on.

onkeydown="true" -- Runs validations when a keydown event is triggered on the form field.

onkeyup="true" -- Runs validations when a keyup event is triggered on the form field.

onkeypress="true" -- Runs validations when a keypress event is triggered on the form field.

ontyping="true" -- Runs validations following a keypress after 1100ms (or the time period specified in validanguage.settings.typingDelay) has passed. Any keypresses prior to 1100ms elapsing will restart the timeout used to see if the user has stopped typing.

Specialized Validation Presets

required="true" -- Loads validation for the form target ensuring that the field is filled out or selected. If the form field accepts text input (textboxes and textareas), then the field will fail validation if it is empty. For radio buttons, the validation will fail if none of the radio buttons are clicked. For checkboxes, the validation will fail if the checkbox is not checked. For a select box, the validation will fail if the select box is left on the default, "empty" option (A selectbox is considered empty if the selected option's value is '', ' ', 0 or ' ', although this setting can be changed, if needed).

requiredAlternatives="checkbox2, checkbox3" -- Specifying a requiredAlternative allows a form field to pass validation if one of the defined alternatives is filled out. This enables you to load a group of checkboxes and allow a form to be submitted if at least one is checked. You can also define 2 textboxes so that at least 1 must be filled out.

maxlength="12" -- Loads a validation check to ensure that the text entered in the field does not exceed the specified number of characters.

minlength="2" -- Loads a validation check to ensure that the text entered in the field is at least as long as the specified number of characters.

expression="numeric$." -- You can use the expression attribute to load character validation for the target form field. A character validation expression allows you to specify which letters, numbers and punctuation are allowed to be entered into the form field. The behavior of the expression attribute is controlled by the mode attribute. If mode="allow" is defined (the default), then a form field will fail character validation if it contains any characters other than those defined in expression. If mode="deny" is defined, then a form field will fail validation if it contains any characters defined in expression.

The following shortcuts are supported inside expression:
  • "numeric" is the same as defining "0123456789"
  • "alpha" is the same as defining "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
  • "alphaUpper" is the same as defining "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
  • "alphaLower" is the same as defining "abcdefghijklmnopqrstuvwxyz"
  • Note that shortcuts can be combined (e.g, "alphaLowernumeric")
Thus, when expression="numeric$." mode="allow" is defined, then input will fail validation if it contains any characters other than numbers, periods or dollar signs. (If you wanted to ensure that a dollar sign or period didn't appear multiple times, you would need to use a regular expression, which is described below).

mode="deny" -- Defines the behavior of the character validation expression. See above.

suppress="true" -- When suppress="true" is defined (which is the default when a character expression is defined), then anything which a user types on their keyboard that doesn't conform to the defined character validation will be suppressed from appearing in the textfield. For example, if the user attempts to type the letter 'P' in a textfield with expression="numeric$." defined, the keyboard event will be suppressed and the letter will not appear in the textfield.

regex="^\d{1,3}[a-zA-Z]{1}$" -- Specifies a validation rule using a regular expression (regex). By default, the form field's input must match the regular expression (although this behavior can be reversed through the use of the errorOnMatch argument). If you need to use quotation marks inside the regex itself, you can use a different character not appearing in the regex as the delimiter, such as regex=B[\d|'|"|\.]+B

errorOnMatch="true" -- Allows the user to control whether a match against the provided regular expression will result in the form field passing or failing the validation check. The default setting is errorOnMatch="false", which means that if the form field matches the regex, it will pass validation. By specifying errorOnMatch="false", this behavior can be reversed so that when the form field matches the regex, it will result in a validation error.

modifiers="im" -- Allows the user to add modifiers to the regex. Javascript supports 2 modifiers in this context:
  • i for case-insensitive matching
  • m for multi-line mode, in which caret and dollar signs refer to the start and end of a line, rather than start and end of a string
If you are using both modifiers, provide them without a comma in between.

Available Custom Validation Functions

The following functions are included in validanguage.js by default and can be used by loading them as a "custom" validation via the validations="validanguage.customFunction" syntax. For functions which take optional arguments to customize the behavior, you must always specify "text" as the first argument (since all validanguage validations must expect the text of the field being validated as the initial argument). For example: validations="validanguage.someFunction( text, argumentOne, argumentTwo )".

validanguage.validateCreditCard

validanguage.validateCreditCard verifies that the field contains a valid credit card number. This function takes 2 arguments:
  • cardTypes {Array} -- Pass an array using [] bracket notation to indicate the types of credit cards which are considered valid. Supported card types include 'amex', 'bankcard', 'diners', 'disc', 'electron', 'enroute', 'jcb', 'maestro', 'mc', 'solo', 'switch', 'visa' and 'voyager'. The default value is ['amex','disc','mc','visa'].
  • testChecksum {Boolean} -- Pass false to skip the luhn checksum test. The luhn checksum is a basic validation routine used to weed out fake card numbers and simple transposition errors.
Examples: Comment API: <validanguage target="credit_card" validations="validanguage.validateCreditCard( text, ['disc','mc','visa','diners'], false)" onblur="true" onsubmit="true" />

Object API: 
validanguage.el.credit_card = {
   validations: [
    {
      name: "validanguage.validateCreditCard( text, ['disc','mc','visa','diners'], false)",
      onblur: true,
      onsubmit: true
    }
 ]

validanguage.validateDate

validanguage.validateDate validates that a valid date is supplied and is entered in the correct format. Since this function takes a large number of arguments to customize its behavior, all the arguments must be passed in as part of a single object using Javascript Object Notation. Javascript object notation requires that curly braces surround a comma-delimited list of key/value pairs. See the examples below for the correct syntax.
  • dateOrder {String} -- Specifies the order in which the year, month and day values are passed. This must be either 'ymd','mdy','dmy','myd','ydm', or 'dym'. Defaults to U.S.-format 'mdy'.
  • allowedDelimiters {String} -- Specifies the delimiters which are allowed to be used to separate the year, month and days from one another. validateDate requires delimiters and cannot be configured to accept dates such as "123108". Defaults to: './-'.
  • twoDigitYearsAllowed {Boolean} -- Is a 2-digit year valid? Defaults to false. If this is set as true, then years greater than "20" are treated as 19XX and years less than or equal to 20 are treated as 20XX (for purposes of validating leap year dates).
  • oneDigitDaysAndMonthsAllowed {Boolean} -- Is a 1-digit month or year valid? Defaults to true. If set to false, then a user would need to enter the first of the month as "01".
  • maxYear {Integer} -- Years greater than maxYear will be treated as invalid. Defaults to 15 years from today.
  • minYear {Integer} -- Years less than minYear will be treated as invalid. Defaults to 1900.
  • rejectDatesInTheFuture: {Boolean} -- Are dates in the future valid? rejectDatesInTheFuture defaults to false (meaning that future dates are valid).
  • rejectDatesInThePast: {Boolean} -- Are dates in the past valid? rejectDatesInThePast defaults to false (meaning that dates in the past are valid).
Examples: Comment API: <validanguage target="birthdayField" validations="validanguage.validateDate( text, { dateOrder: 'dmy', rejectDatesInTheFuture: true } )" onblur="true" onsubmit="true" />

Object API: 
validanguage.el.birthdayField = {
  validations: [
    {
      name: "validanguage.validateDate( text, { dateOrder: 'dmy', rejectDatesInTheFuture: true } )",
      onblur: true,
      onsubmit: true
    }
  ]

validanguage.validateTimestamp

validanguage.validateTimestamp validates that a valid timestamp has been supplied. This function supports all the validateDate arguments listed above, as well as the following additional arguments:
  • timeIsRequired: {Boolean} -- Is a date which is provided without an accompanying time considered a valid timestamp? timeIsRequired defaults to false (meaning timestamps without times are considered valid).
  • timeUnits: {String} -- A string containing a list of all the time units which are allowed to be entered in the timestamp. These may include any of the following: h for hours, m for minutes, s for seconds, u for microseconds, and t for timezone. Example: "hms" for hours, minutes and seconds or "hmsut" for all 5 units. Defaults to "hms".
  • microsecondPrecision {Integer} -- Indicates the supported number of decimal places for the microseconds. Defaults to 6.
Examples: Comment API: <validanguage target="birthdayField" validations="validanguage.validateTimestamp( text, { rejectDatesInTheFuture: true, timeIsRequired: true, timeUnits: 'hmsut' } )" onblur="true" onsubmit="true" />

Object API: 
validanguage.el.birthdayField = {
  validations: [
    {
      name: "validanguage.validateTimestamp( text, { rejectDatesInTheFuture: true, timeIsRequired: true, timeUnits: 'hmsut' } )",
      onblur: true,
      onsubmit: true
    }
  ]

validanguage.validateEmail

validanguage.validateEmail validates that a valid email has been supplied. This function does not take any arguments.

validanguage.validateIP

validanguage.validateIP validates that a valid IPv4 address has been supplied. This function does not take any arguments.

validanguage.validateNumeric

validanguage.validateNumeric validates that a numeric value has been supplied (via the regular expression /^\d+$/). This function does not take any arguments.

validanguage.validateURL

validanguage.validateURL validates that a valid URL has been supplied. This function does not take any arguments.

validanguage.validateUSPhoneNumber

validanguage.validateUSPhoneNumber validates that a US-style social security number has been supplied (via the regular expression /^\d{3}( |-|.){0,1}\d{2}( |-|.){0,1}\d{4}$/). This function does not take any arguments.

validanguage.validateUSZipCode

validanguage.validateUSZipCode validates that a US-style phone number has been supplied (via the regular expression /^\D?(\d{3})\D?\D?(\d{3})\D?(\d{4})$/). This function does not take any arguments.

CSS Classes and IDs Used by Validanguage

The following CSS classes are used by default within validanguage and can be used by the end user to customize the appearance of your form validation messages and form fields. If needed, the class names listed below can be changed from their default values to customized values via the corresponding setting in validanguage.settings.

vdError and vdNoError

The default showError() function used by validanguage will create a DIV with the class name of vdError to contain the inline text of the validation error message. When the hideError() function is run, any error message DIVs will be hidden by toggling their display property to 'none' and the class name will be changed to vdNoError. You can change these class names from their default values via the validanguage.settings.onErrorClassName and validanguage.settings.noErrorClassName settings.

ElementID_errorMsg

As noted above, the default showError() function used by validanguage will create a DIV with the class name of vdError to contain the inline text of the validation error message. This error message is placed inside a span tag which is assigned an element ID using the ID of the form field with _errorMsg appended at the end. Here is an example of the HTML which would be produced to show the error message for a form field named "address1":

<div class="vdError"><span id="address1_errorMsg">Please enter your address</span></div>

If a SPAN with this ID already exists in the DOM, it will be used. If it doesn't exist, one will be created dynamically. You can change the suffix from its default value via the validanguage.settings.errorMsgSpanSuffix setting.

passedField and failedField

The default showError() function used by validanguage will add the class name of failedField to any form field which fails validation. Any existing class names already used by this form field will remain (since elements are permitted to have multiple class names). When the hideError() function is run, any form fields passing validation will have the failedField class removed and have a passedField class name added. You can change these class names from their default values via the validanguage.settings.failedFieldClassName and validanguage.settings.passedFieldClassName settings.

Changing Settings Globally

A number of settings, including some of the ones mentioned above, can be changed globally for all form fields, or alternately, for all fields in a specific form. To change a setting globally, you simply redefine the setting inside a script tag which must appear in the page's HTML below the script tag which loads validanguage. For example: 
<script type="text/javascript" src="/path/to/validanguage.js"></script><script type="text/javascript">
  validanguage.settings.showAlert = true; //Turn on alerts for all form fields
</script>
Any setting which is defined globally will be overruled if the same setting is also defined for a specific form field. For example, if showAlert were turned on using the global setting above, but one form field contained a validanguage comment with showAlert="false" then the alert would not appear for that one field, but still display for all others.

For a full list of all the Form-level validanguage settings which are available, see the Validanguage Settings API Documentation.

Loading a Setting as Form-Specific instead of Global

If you have 2 forms on the same page and would like to define separate global settings for each form, this can be done easily. Within validanguage's populate() method, the program determines how many forms are on the page and creates separate copies of validanguage.settings for each form, which are then used as the global setting for all fields within each form. This is a form of inheritance which allows you to first define settings that all forms will inherit, and then, if needed, you can step in and change the form-specific settings at will by defining a custom validanguage.overloadFormSettings() function. All form-specific settings are stored in the validanguage.forms.{$id_of_the_form}.settings

Here is an example of how you might combine global settings and form-specific settings: 
<script type="text/javascript">
   validanguage.settings.showAlert = false; //set this for ALL forms
   validanguage.overloadFormSettings = function() {
      validanguage.settings.forms.form1.onerror = 'showErrorsForForm1';
      validanguage.settings.forms.form2.onerror = 'showErrorsForForm2';
   }
</script>

Transformations

Validanguage includes support for a class of functions I have named Transformations. These are intended to be used as functions which reformat the data inside a text field, or which toggle other form fields in response to user actions. Transformations are distinguished from Validations in that they do not directly have any impact on whether a form validates. However, transformations for a given form field will always be executed prior to any validations for that field, and thus can be used as a "beforeValidation" hook. Transformations are basically standard event handlers and are defined with the following syntax: Comment API: <validanguage target="text" transformations="customFunction" onblur="true" />

Object API: 
validanguage.el.text = {
  transformations: [
    {
      name: customFunction,
      onblur: true
    }
  ]
Alternately, a shorthand notation for declaring transformations is supported. When an event handler references a string or a function directly, such as onblur="customFunction", then a transformation will be loaded.

Like validations, transformations are executed within the scope of the form field on which they are applied.

The validanguage.format() transformation is included in validanguage.js (an example of its use appears on the validanguage demo page in the phone number field). In this example, I use the validanguage.format() function to reformat a US phone number to add spaces, dashes and parenthesis when the user tabs out of the field. Here is the Object API code used to load this function: 
  onblur: "validanguage.format( '(xxx) xxx-xxxx', '-() ' )"
See the Advanced Validanguage Features for more details on how to use validanguage.format() and a list of additional transformations included with Validanguage.

Form-Level Transformations

In addition to the field-specific transformations above, you can use form-specific onsubmit transformations to define custom error/success handlers on a form, which provides the ability to prevent a form from submitting and instead submit it via Ajax, or to display a list of all the form fields that failed validation.

Form-level transformations can be defined with the following syntax:

Comment API: <validanguage target="form1" onsubmit="formHandler" />

Object API: 
validanguage.el.form1 = {
  onsubmit: 'formHandler'
}
Both of the above examples would call a function named formHandler after all validations have been performed. The formHandler function is executed within the scope of the form and is passed 2 arguments:

1st argument / submitStatus = A boolean indicating whether or not any form fields flunked validation 2nd argument / failedValidations = An array of objects containing details on any flunked validations, including their error messages

An onsubmit form transformation can suppress or allow a form to be submitted by returning a boolean value. So, if the customHandler function above were to be used to submit a form via Ajax, it would issue the Ajax call and then return false to block the form submission. To have a transformation not affect the form submission either way, simply avoid returning anything.

API #2 -- The Object API

The Comment-based API is actually converted into the Object API within Validanguage before the validation event handlers are assigned. Thus, all functionality available in the Comment-based API is available in the Object API. However, you may find that the Comment API is easier and faster to work with. Or, you may prefer using the Object API for the added flexibility it gives you.

The validanguage Object API is used by adding rules to the validanguage.el object, grouped by form field. For example: 
validanguage.el.date: {
  characters: {
    mode: 'allow',expression: 'numeric/-',
    suppress: true,
    errorMsg: 'You have entered invalid characters'
  },
  required: true,
  errorMsg: 'Please enter a valid birthday.',
  validations: [
    {
      name: 'validanguage.validateDate',
      errorMsg: 'Please enter a valid birthday'
    }
  ]
};

validanguage.el.socks: {
  required: true,
  maxlength: 8,
  minlength: 6
};
Assuming you're familiar with Javascript Object and have read through the documentation in the Comment API section above, then the above example should be pretty self-explanatory.

List of Options Available in the Object API within validanguage.el.{$form_field_id}

onerror: 'showError, updateForm' onsuccess: [hideError, updateStatus] -- The onsuccess and onerror handlers are available on the Object API and allow the user to specify which functions to be run by using one or more of the following methods:
  1. A string containing the name of a single function or object method
  2. A string containing a comma-separated list of function/method names
  3. A function reference
  4. An array containing multiple values, each of which can be of any of the previously listed types
errorMsg: 'This field did not validate' -- This error message would be used for all validations listed for this form field (unless overidden by a more specific message).

showAlert: false -- Allows you to control whether or not a javascript alert() prompt is shown for this form field only.

focusOnError: true -- Setting this to true will make the form field which failed validation receive focus when the validation fails. Be careful when using this option in combination with showAlert="true" and onblur="true".

onsubmit: true onblur: true, onchange: true, etc. -- Defining the event handlers within Validanguage.el.{$form_field_id} will make the defined handlers apply to all the validations for this form field unless a given function has its own event handlers assigned (which would have a higher specificity and override the more general ones defined on the element for that function)

required: true -- Loads the validateRequired validation within the corresponding validations array of functions.

requiredAlternatives: 'checkbox1,checkbox' -- You can specify the requiredAlternatives as either a comma-separated list of element IDs or as an array of element IDs.

minlength: 4, maxlength: 12 -- Adds the minlength and maxlength validations.

Defining Custom Validations in validanguage.el.{$form_field_id}.validations

Custom validation functions are defined in the validanguage.el.{$form_field_id}.validations array, which is an array of custom objects, with each object containing details on a single validation function. The example below lists 2 custom validations and demonstrates all the supported options: 
validanguage.el.login_name: {
  validations: [
    {
      name: 'checkSpelling',
      onblur: true,
      onsubmit: true,
      errorMsg: 'You have misspelled your login name'
    },
    {
      name: 'checkProfanities',
      onblur: true,
      onsubmit: false,
      errorMsg: 'Your login name may not contain profanities. Please select another login name.'
    },
  ]
};

Defining Character Validation in validanguage.el.{$form_field_id}.characters

Character validation can be defined using the characters object with the same parameters available in the Comment-based API, as illustrated in the following example: 
validanguage.el.date: {
  characters: {
    mode: 'allow',
    expression: 'numeric/-',
    suppress: true,
    errorMsg: 'You have entered invalid characters'
  }
};

Defining Validations with Regular Expressions in validanguage.el.{$form_field_id}.regex

Regex-based validation can be defined using the regex object with the same parameters available in the Comment-based API, as illustrated in the following example: 
validanguage.el.money: {
  regex: {
    expression: /^[\$]{0,1}[0-9]+[\.]{0,1}[0-9]?$[/,   //You can supply either a string or a Regex to the expression argument
    errorOnMatch: false,       //This is the default option and doesnt really need to be specified
    errorMsg: 'You have not entered a valid amount'
  }
};
This completes the introduction to Validanguage's basic features. To read more, please continue on to the Advanced Validanguage Features page.