When working with Ajax sooner or later you will run into the need to validate data the user has entered. The Ajax approach to validation would be client side validation (using a JavaScript on the browser) which gives the user a direct feedback for the values entered. While non-Web 2.0 applications rely mostly on server side validation, requiring a full round trip to the server and back before the user actually sees the validation result. While server side validation is slower it has some advantages over client side validation:

• It can’t be fooled: while JavaScript can be turned off, or manipulated injecting scripts.
• The server can perform security test, such as checking a password, without making the check vulnerable to viewers (remember: never check on the client side if the password is correct ^^)
• Formatting errors will be recognized.

But Web 2.0 developers just love those fancy instant validations they can do with JavaScript so why not combine them? There are basically 3 different ways to validate data:

• Client side (JavaScript): the easiest way to validate a field is to attach a callback function to a field that will then check if the value is valid.
  
• Server Side (Ajax): for some operations we want on the fly validation but have to do a roundtrip to the server, for example to see if a username is still available.
  
• Server Side (Submit): the classic way of doing things. User submits Form, Server validates and performs actions or throws out a bunch of validation errors.

All three of these techniques have their advantages and disadvantages, while the Client side (JavaScript) is the fastest it is neither secure as it can be turned off, nor applicable to every possible situation (see the Username example). The Server Side (Ajax) method is the nicest as it virtually allows any validation possible but it too can be turned off and it involves a full round trip making it slow and requires some extra data handling. The Server Side (Submit) method is the most secure method but it is the slowest and does not give immediate feedback on a user action. Nevertheless the server side validation (submit) should never be omitted since the others can be turned off, and we don’t want the user to add bogus data, do we?

So what’s our best option? The logic step would be combine them together so we do react on user actions immediately giving him some feedback and we are secure that the data is validated at least once (on the server) before we operate on it.
The main problem now is that we would have to write most of the validation criterias twice (once for the server side and once for the client side). What we need is some sort of meta-model for the form in which we describe the datatypes and validation tests we want to execute on them and then generate the Form on the fly out of this model. This idea isn’t actually new (and it would be wrong to give me the credits for it ), I stumbled over it when starting to work on a Cocoon project. At first sight the Framework looks a bit overblown but once you get started it is really easy to understand.
Basically you describe the Form-Fields in an XML file defining fieldtype and name, and, what is interesting for us right now, add some validation functions. This model will then be translated into the Form once it is requested. The validation functions will be executed both on the server side and the client side, thus eliminating the need for writing them twice.
The same could be archieved with any other scripting language, and I’m looking forward to see other frameworks going in this direction, it really makes coding a pleasure.


Technorati Tags: ajax, web 2.0, form, validation, snyke