Below is a list of all available options. For more details about options, or events, check out the wiki.
|appendRulesToFieldClass||false||If true, rule names will be appended to the fields class. When rules are enabled/disabled via method calls, these will stay in sync.|
|reconcileFieldOrder||false||If true, the fields will be validated in the order they appear on the form, instead of the order they're added to Pliant.|
|haltOnFirstInvalidRule||true||If true, validation for each field will halt on the first invalid rule.|
|hideMessageContainerOnLoad||true||If true, hide the shared message container on load if one is defined.|
|validateOnFieldChange||true||If true, validation will trigger on field change, unless the field overrides the behaviour via its validateOnChange options.|
|focusFirstInvalidField||false||If true, the first invalid field will gain focus. You can handle the focus yourself by handling the onInvalidFieldFocus event.|
|ignoreHidden||true||If true, any field not visible during validation will be ignored.|
|ignoreDisabled||true||If true, any field that's disabled during validation will be ignored.|
|validateOnSubmit||true||If true, the validation will attempt to trigger automatically on form submission, assuming the instance scope is a form.|
|validateOnSubmitSelector||NULL||If set, validation on submission will only be triggered by elements returned by the selector. By default, any 'form' submission will be validated if validateSubmit is enabled, and the scope of the plugin is a form.|
|validateOnSubmitEvent||'click'||The event to subscribe to for elements returned by the validateSubmitSelector option.|
|validateOnSubmitScope||NULL||The selector to use for the scope when binding the validateSubmitSelector. If NULL, the selector/scope used when invoking the plugin is used.|
|inputSelector||':input[type!=button]'||The default jQuery selector for finding fields when the reconcileFieldOrder option is enabled.|
|messageElement||'<label />'||The default element to wrap around error message text.|
|messageWrap||NULL||The element to wrap around the messageElement.|
|messageContainer||NULL||The jQuery object of an HTML element to stick all validation messages in.|
|messageElementClass||'pl-element-error'||The default CSS class applied to validation message elements.|
|messageWrapClass||'pl-wrap-error'||The default CSS class applied to validation message wrappers.|
|inputClass||'pl-input-error'||The default CSS class applied to invalid input fields.|
|plugins||NULL||See the WIKI documentation for plugin information.|
|rules||See Docs.||A literal object containing validation rules. See the WIKI documentation for more information.|
|fields||See Docs.||An array of fields to validate. Fields are validated in the order they're added, unless you enabled the reconcileFieldOrder option.|
We've defined a custom rule called "date", which any field can use.
We also defined a "one off" rule called "ssnformat", that only the SSN field can use, since it's defined in the fields definition.
Building on the first example, we've simply overridden the default messages for some rules. You can override any property in a defined rule, including the validate function.
A new rule called "compare" was also added. You can see that it makes use of "shouldMatch" and "compareTo" properties that each field using it can specify.
Built into Pliant, is the "length" rule. What we've done is create out own rule called "mylength", which inherits from the built in "length" rule.
The purpose of this would be if you want to use a custom rule for multiple fields, but don't want to override the properties of the rule multiple times since they're all the same.
Chaining simply lets you trigger validation for other specific fields, when you validation occurs for another.
In this example, we're using it to trigger comparison validation for both password fields. We're actually only chaining specific rules in this example, but you can also chain it to validate all rules or multiple fields if you want.
Enter two mismatched passwords, and then correct either of the two fields. You'll notice that their comparison validation triggers for both.
Markup rules is a way to add basic validation to fields by using HTML comments. This can be useful if you're dynamically adding content, and you want the content to have validation defined in itself.
The comments themselves are stringified JSON, and are the same format using everywhere else in Pliant. You can define them anywhere on the page, so long as that place is in the scope you've selected when instantiating Pliant.
Setting the "parseMarkup" to true, causes the initial scrape of any HTML comments, and calling the "AddMarkupRules" function scrapes and adds any new HTML comment rules after init.
This is an example of the Pliant input masking plugin. This was created because normal masking plugins are difficult to use with Pliant due to them usually controlling events relied upon for validation.
This is a basic example, showing a date, URL, phone w/optional extension, and SSN mask. Masks can be shown on field focus, or always be shown.
Notice that the date, and SSN masks only show on field focus, while the others are static.
You can see from the code, you can define the rule, placeholder, and focus option. Notice that a number inside curly braces indicates how many times to repeat the mask character before it. Also notice the "?" character in the phone mask; where it indicates that everything to the right of it is optional. The mask to use is defined in the field definition.
The definitions shown are built in to the plugin by default, and are only shown as an example for adding your own.
This is an example of the Pliant input hinting plugin. The hint plugin supports text boxes, and password boxes. You would generally use this to give the user a hint as to what the field is for, which is useful if you don't want separate labels in your forms.