A few days I blogged about Adobe's release (and sexy-fication) of the javascript framework Spry 1.6.  While I have not had a lot of time to play around with the absolutely unique elements, some cool additions are the improvements they made to the password verification and confirmation widgets.  With the root password widget, the developer can create a pretty robust set of validation rules for user-entered passwords, such as setting minimum and maximum lengths, required special characters/numbers, etc.  The best part is that the Spry framework makes these validations incredibly easy to implement on a normal HTML form.  For example, here is an example password field I have created:


<span id="passwordValidation">
    <input type="password" name="password" id="password" />
        <span class="passwordRequiredMsg">Please enter a password.</span>
        <span class="passwordMinCharsMsg">Your password must be at least 7 characters long.</span>
        <span class="passwordInvalidStrengthMsg">Your password must contain at least 1 number.</span>

That's it.  Basically, the entire password widget is a span wrap on the password field.  Within this, special validation messages can be defined.  On this example, I have set an error message for "required," "minimum characters" and "password strength". 

On the function side, the following is all that is required to fully validate this field:

var password = new Spry.Widget.ValidationPassword("passwordValidation", {minChars:7, minNumbers:1, validateOn:["blur", "change"]});

Basically, I simply pass the ID of the widget ("passwordValidation", the ID I gave to the span above) to the Spry.Widget.ValidationPassword() function and then define the various rules that I want to apply to it.  I finish the function call with the action I want to trigger the function (here, "blur").  That's it–very simple.

To further round out my example, I have also included a password confirmation field, a required security question field, and a custom-validation zip code field.  But most interesting (at least to me) is the functionality on the email field.  In addition to validating that the user has entered a syntactically correct email address (that is, one containing an "@" followed by "domain.com"), it also makes an asynchronous call to a ColdFusion component to check whether or not the email exists in the database.  It finishes up with displaying a message depending upon the result of the component call.  I do this with the following:

function checkEmail() {
    var email = document.getElementById('email');
    var emailText = document.getElementById('emailVerification');
    emailText.innerHTML = "";
    var email = email.value;
       Spry.Utils.loadURL("POST", "registration.cfc?method=checkEmail&email=" + email, true, emailResult);

Here, I am simply getting the values of the email input field, as well as clearing out any values that exist in the "emailVerification" field.  After this, I pass the value of the email field to my component.  The component queries the database, evaluates the input, and then returns the status of the email lookup.  Once returned, loadURL() fires the callback function "emailResult", listed below.

function emailResult(request) {
       var result = request.xhRequest.responseText;
       var xmldom = Spry.Utils.stringToXMLDoc(result);  
       var verifyEmail=xmldom.getElementsByTagName("email");
       var emailText = document.getElementById('emailVerification');
    var emailNode = verifyEmail.item(0);
       if (emailNode.getAttribute("id") == "yes") {
        emailText.innerHTML += "That email has already been taken";
    else {
        emailText.innerHTML += "That email is available";

In a nutshell, this function simply parses the returned value from the component call.  If the result is "yes" (i.e., the email exists in the database), I return an error message.  If "no," the user is told so.

Now obviously, strikingly absent from this example is any server-side validation.  If I were to implement this into an application, I would want to duplicate the various bits of functionality for server-side processing, for the end-user could easily disable javascript in their browser and render all of this fun, flashy stuff entirely moot.  Now of course, this means more work for the developer.  However, I think it is worth it as the kind of UI options outlined above can make the end-user experience more robust and significantly less frustrating (don't you hate getting error messages AFTER hitting submit and then have to go back and do it all over again?).

Anyway, this is long enough now.  Click here to see this code in action!