Project's description
This project intends to facilitate the data validation (client side and server side) for any kind of website. The main idea is to provide developers with a way to write or generate quick validation rules, and display messages back to the user accordingly. The API is designed to be highly extensible, and provide a way to easily interact with any step of the validation process. It has been greatly inspired by the following project : JSR303JS, but about 90% of the code has been rewritten to better fit our needs.
This project can be split in 2 parts :
- the core API
- the plugins
Its only required dependency is Javascript, and can be used along with whatever language : Php, Java, C++/C#, etc. This is possible thanks to the way the API has been split : the plugins provide a way to generate the validation rules, whereas the core API provides the validation engine that will use them.
This is the part that actually does the validation. It provides all necessary methods to read the validation rules (not to create them, though), execute them, register listeners for fields and lifecycle events, etc.
Given a simple HTML form :
<form id="myFormId" action="/send" method="POST">
<input type="text" name="firstname" />
<div id="firstname_errors"></div>
<input type="submit" value="Send" />
</form>Here's an example of what the engine looks like :
formBeanValidator = new JSValidator('myFormId',
new Array(
new JSValidator.Rule('firstname', 'NotNull',{'message':'Firstname should not be empty'})
)
);The above code creates an instance of the validation engine, given the form's Id, and a validation run on the "firstname" field. In order for the validation to work properly, we now need to bind the validation to one or more events, like that :
formBeanValidator.getFieldWithName("firstname").bindValidationToEvent("change");The above method finds the "firstname" field in the form, then tells the engine to validate the field when its value is changed (ie. when the user actually changes the value AND looses the field focus). You can either bind native or custom Javascript events to the fields. In order to display the error messages, the validator automatically detects the message containers, and prints them into it.
This is just a tiny fraction of what this API can do. Here's the full features list :
-
Bind events that would trigger validation either on fields or on form (or both at the same time). As there can only be a "submit" event at the form's level, there is a shortcut method for that
-
Allow you to write your own Javascript validation rules
-
Allow you to define field-by-field conditions regarding validation
-
Allow you to delay validation execution (useful for key* events)
-
Allow you to decide whether to validate the rule in pure javascript (with a written validation rule, as stated right above), or using AJAX
-
Allow you to configure many things
-
How messages should be rendered (DOM, CSS classes, etc.)
-
In AJAX mode, allow you to configure your endpoint, and the parameters (names and values) you want to send out
-
Define global events, on form's level, that would be fire only once :
-
before any validation takes place (the very first event in the validation lifecycle, no matter what)
-
after any validation has taken place (the very last event in the validation lifecycle, no matter what)
-
Define global field-level events, on form's level, to be executed by each field which needs validation, regardless the thrown event (may be useful for logging, for example)
-
before any validation on the field
-
after all the validations on the field have taken place, but before error messages have been displayed, if any (thus allowing you to modify them on the fly)
-
after all the validations on the field have taken place, and after the error messages have been displayed, if any
-
Define local field-level events, on form's level, to be executed for each field, when the form is submitted
-
before any validation on the field
-
after all the validations on the field have taken place, but before error messages have been displayed, if any (thus allowing you to modify them on the fly)
-
after all the validations on the field have taken place, and after the error messages have been displayed, if any
-
Define local field-level events, on field's level, to be executed for each field, given an event
-
before any validation on the field
-
after all the validations on the field have taken place, but before error messages have been displayed, if any (thus allowing you to modify them on the fly)
-
after all the validations on the field have taken place, and after the error messages have been displayed, if any
Here's a picture that explains the validation's lifecycle
For a detailed overview of all the features, please see the technical documentation //TODO
The plugins allows you to develop tools that will help you further improve the easiness of using this validation API, in your favorite language. For example, a plugin that can read all the constraints from your data model, and generate the rules for you. You think this is magic ? Well, not so much, and we did it for you already.
Those are the plugins that already exist (we intend to make that list grow to any major programmatic or scripting language) :
- Java
- Core - JavaEE plugin
- Extension - JSR 303 plugin
- Extension - Spring MVC plugin
Please note that some plugins may be used together.
This plugin contains :
- A taglib that'll generate all the validation rules for you, provided an object or full-qualified Class name. It will look up the Class in the classpath, and create for you a ready-to-use validator. No more writing the rules by yourself. In order to do that, it will however need another plugin related to the validation strategy (JSR 303, OVal, etc.)
- A servlet that should be extended for AJAX call, and that will contain the needed Java methods. This servlet will be used for AJAX calls, and will ensure you to get only the errors (if any) related to the fields and constraints you asked for.
The main advantage, putting aside the fact that it will be easier to use AJAX validation because of the native JSR303 validation API, is that you willll now be sure that every constraint you write will be present in both the client and the server side.
This plugin uses... big surprise... the JSR 303 specifications as a validation model. If you include it in your classpath, the taglib mentioned right before will understand and create rules based on the JSR 303 specifications.
This plugin will use the power of Spring controllers to handle AJAX validation even faster. It comes with a Spring controller, and a Javascript method to override the way the AJAX validation URL is made (so it can be more efficient for Spring MVC)