- The Design Pattern of Client Side Form Validation
- Use a Form validation library or framework
- Focus on solving the biggest problems
- Validate form before the form is submitted
- Use API-based validation for business data input
- Do extensive testing of client side validation
- Rewrite input data to valid formats
- Attach form validation late in the design process
- Make the validation i18n- and l10n-compatible
- Add events and callbacks to your validation library
- Make your library extensible
- External Resources
Whenever a user needs to submit data to your application, there is a need in validating the users input.
As soon as you start developing and implementing your validation, it is easy trying to address all potential validation that is needed for all types of input. My advice is to try to catch 75-85% of the potential user input errors in the front-end validation. Trying to catch all will lead to the following:
- Bloated code, your framework will grow too large
- More or less impossible to test client side validation as there are too many combinations of validation that can go wrong
- Business rules will move to the front-end.(More on how to avoid this by using Ajax later)
To avoid this I think that creating a small validation framework that can do most of the validation is the way to go, and leave the specific things for the server (or create a plugin to your framework later) to validate.
- Whenever a controls value is changed
- When a control is blurred
- Periodically check if controls has changed
- When a control that is connected to another control changes value
- When a form is submitted
- When a form is reset (if you for some reason finds it intelligent to have a reset-button on your form)
In order to validate business data you have three alternatives
- Let the server take care of it
- Add business logic to your front-end code
- Let the front-end talk to the back-end through an Ajax-API
My suggestion is to go with the first or the last option, if you go with the last option there are a couple of things to keep in mind
- Make sure your code is secure. Sometimes “smart” solutions like these, exposes business data to people with a little technical knowledge
- Create a server-side API that has a defined set of methods with a defined set of parameters to be sent to it.
- Create a client-side wrapper, wrapping the functionality exposed in the server-side API.
- Only allow communication between the server-API and the client-side API-wrapper
* json * html * xml * script * text
Typical business data in my mind, are unique usernames and emails, age-validation rules, address verification etc etc
There is one thing worse than no validation: Validation that do not let correct data through.In order to avoid this, my finding is that coding is a smaller part then the actual testing of the validation framework. My tips is to create unit-tests for all your validation rules as a part of the validation framework, this way it is easy for you/your team to verify functionality whenever a change is needed to your framework
- Phone numbers
- Social Security numbers / Personal Numbers
- Trim spaces
- Remove/exchange invalid characters
If your web is successful for an international public, the non-english-speaking audience is next. In order to achieve this it is important that even user generated error messages is localised and translated. Make sure your client side validation framework is prepared for translation and other localised parameters such as currencies, dates and time-formatting.
90 % of the time you want to use your validation framework as it was intended to be used, 10 % of the time you will be wishing that your framework would be more generic to achieve some specific interesting effect you have identified while working with your site and validation framework. In order to achieve this I think it is important to add the possibiltity to attach callback functions for your forms, letting the developer use your library in a way you couldnt dream of. The definition of a good library is when people using it creates stuff you as a creator of the library didnt think was possible.
If you add working hours to a framework or a library, it is important that the architecture of the library/framework is open, and is extendable.
- Will Jessup has a nice example of form validation with jquery.