In the MooTools 1.1 version I had a base class, ‘Widget’ which I would extend as below:

var DialogBox = Widget.extend({ … });

Widget implements both Options and Events which allowed me to create a set of events the widget can fire, handlers for which can be added through options, as such:

var DialogBox = Widget.extend({
  options : {
    onCancel : this.close.bind(this)
  }
  ...
});

Because extend is a method of Widget, its ‘this’ is the object itself and, provided there is a close method, the event handler for ‘cancel’ is set up.

MooTools 1.2 introduces a new syntax for extending objects:

var DialogBox = new Class({
  Extends : Widget,

  options : {
    onCancel : this.close.bind(this)
  },
  ...
});

Now, the ‘this’ is actually the window object so the cancel event is actually handled by the window.close method – not quite the functionality intended!

After digging around in the MooTools code, in particular the Request.HTML class, I found what appears to be the only way to default events in options. By setting the option before calling setOptions (if it isn’t already set), the event handler is correctly assigned:

var DialogBox = new Class({
  Extends : Widget,

  options : {
    ...
  },

  initialize: function(options) {
    options.onCancel = options.onCancel || this.close.bind(this);
    this.setOptions(options);
  },
  ...
});

The binding is now done on instantiation so the correct close method is assigned as the cancel event handler.

Traditionally, JavaScript form validation involves calling a validate function when the onSubmit event of the form is fired, with the function returning whether or not the form validated. In most cases, if validation failed the user is informed; in the best cases with a highlighted field and inline message, in the worst with an alert box.

With recent trends in website / web application development moving towards more responsive pages and the use of Ajax to speed up user interaction, this system has been crying out for a radical update. Until now.

Live Validation allows a developer to hook any number of validation requirements directly onto form elements. As a user interacts with the field they are given real-time feedback as to whether their data is valid.

The open-source library is available for download to work either with the Prototype framework or as a stand-alone version. The Prototype version integrates well with Ruby on Rails applications and the coding conventions of Live Validation will be very familiar to Rails developers but simple enough to be understood by anyone with basic JavaScript knowledge.

Once the library is downloaded and included on your page, adding validation couldn’t be much easier. The LiveValidation object is instantiated with an id of (or reference to) the input element and then rules added to the object. The following example validates for a required field with an id of ‘f1′:

var f1 = new LiveValidation(‘f1′);
f1.add(Validate.Presence);

LiveValidation also allows chaining of rules and even the object so that it is possible to simply have a single line of code provide very powerful validation rules. The example below requires the field to be filled and to be numeric:

new LiveValidation(‘f1′).add(Validate.Presence).add(Validate.Numericality);

The range of validation rules doesn’t end with required fields and numbers, Live Validation also covers regular expression pattern matching, numeric ranges, length ranges and inclusion / exclusion, amongst others.

Overall, Live Validation’s powerful features, simplicity of use and extensive on-line documentation, combined with it’s graceful degradation and real-time user interaction add up to provide a fantastic replacement for an ageing concept.

Update: Since writing the article there have been two point-releases of LiveValidation and it is now on version 1.2. Added is support for select boxes, time delayed checking and automatic onSubmit validation. Full details are available on the blog.