By: Lachlan Cannon

April 29th, 2004

Reader Rating: 8.5

I like XML. I really do. Still, my eyes glaze over just as much as the next person's when I hear about how wonderful it is. Wonderful it may be, but as a Web developer, how does XML help me?

I use XHTML on my site, yet that doesn't provide any advantages above and beyond those I'd gain using HTML. I have RSS syndication, but that benefits my readers, not me.

It's time to be selfish. It's time to ask, "How can XML help me? How can I use it to make building Web pages easier?"

The Concept

One area that always annoys me when I build Web pages is form validation. Even if you develop a library of functions for page validation, whenever you build a new form, you need either to create a new external JavaScript file with appropriate variables set, or include them in the page itself. It can, and should, be done better.

SitePoint has run a couple of articles (Read and Display Server-Side XML with JavaScript [1] and XML and JavaScript in Mozilla [2]) about loading an XML file with JavaScript, but none that have detailed a practical benefit of the technology. I think it's ideally suited for the task of providing seamless Web form validation.

The idea is that, instead of having to include those messy variables in an external JavaScript file, we can create an XML vocabulary, uploading these special XML files to specify the constraints we place upon our forms.

The Precepts

When building an XML vocabulary, I like to keep a few rules in mind. The vocabulary should be:

• Simple
• Easily understandable
• Concise

There is a fair amount of overlap between these concepts, but I feel they're all important enough to express individually. A vocabulary should be simple so that it's easy to create and parse. It should be easily understandable so that anybody who's not familiar with it can look at it, and at least make an educated guess as to what it does. It should be concise to cut down on unnecessary typing and typographical errors.

The most important consideration I try to bear in mind when designing JavaScripts is that of unobtrusive DHTML. You should be able to link the external JavaScript file into your page, and have it work. This makes it easier on page authors, who don't have to futz about adding things to the page, and also encourages authors to build pages that will work properly without JavaScript enabled -- an all-round win.

The XML

When I started designing the XML format, I specifically decided to choose simplicity over comprehensibility. Therefore, you won't find validation of different form fields working together, such as in a date, in this example. Nor will the format support form controls other than the most common text inputs. These are definite possibilities for future extensions to the script, but for the sake of simplicity, they've been left out for now. For similar reasons, support for validation is provided only for one form per page.

For the JavaScript to know which form to hook into, in order to be able to hijack the form submittal event, the root element, <form>, has an attribute id. Inside the <form> tag is a succession of <element> tags, each of which specifies the rules for one text input.

There are two types of <element> tags. One type has the attribute sameas, which is set equal to the id of another <element>. This is used to specify that an element is a confirmation value, such as a confirmation password or email address.

The other, main, type of <element> has a succession of attributes. The id attribute is a pointer to the form element for which it specifies the rules, and is required. The other required attribute is the name attribute, which is used in the auto-generation of error messages.

The optional attributes are min, specifying the minimum number of characters, and max specifying the maximum number. Leaving either out places no constraint on the upper or lower number of characters. Leaving both out means the input can have any number of characters. The other optional attribute is req, which is set to true or false, and specifies whether the input must be filled in or not.

Inside the <element> tag, a series of 0 or more <regex> tags can be input, specifying patterns of which the input must match at least one. If the text in the field matches none of the patterns, the contents of the <error> element, also a child of the <element> tag, specify the error message to be used. The JavaScript automatically generates error messages for other conditions.

The JavaScript

I don't want to get into too much detail about the script, since that's redundant information, tediously boring, and all the parts that relate to importing the XML have been covered elsewhere, anyway. Check out the example – all the files can be downloaded here [3].

Effectively, this script checks to see if the browser can handle the importation of XML files. If it can, it imports the XML, then executes another function that parses the newly imported XML. If it can't handle the importation of an XML file, the function returns, and the browser does nothing.

To find the filename of the XML file to import, the JavaScript gets the URL of the current page, and replaces the current file extension with .xml. So, if your page is called myform.html, the associated XML file should be called myform.xml.

If the browser imported the XML, it now grabs all the <element> tags and creates an array of ElementValidator objects, which are given their node as part of their constructor. I chose to use objects instead of functions and arrays, because I felt that objects better suited the varied data the validators encompass, and having methods instead of outside functions keeps the global namespace cleaner. Conceptually, also, it made more sense to make an element know how to check itself.

When a validator is created, its corresponding element is given an onblur function that checks its validity as soon as the user stops working on it and focuses elsewhere. This means that users get instant feedback if something they have entered is wrong. To improve the feedback the user is given, an error class is added to the parent of an incorrect form input, and text is inserted into the document with an explanation of what the user has done wrong. This was done in the manner of Kalsey Consulting's simplified form errors [4].

When the form is submitted, a JavaScript function runs through all the validator objects, getting them to check their validity. If any of the objects isn't valid, the form submission is stopped, and the user is given an alert box asking them to review what they have entered.

Of course, if the user has JavaScript disabled, or isn't using Mozilla or Internet Explorer version 5 or higher, they won't see any error messages immediately, and will have to wait for the server to return their errors to them.

Conclusion

There you have it -- a quick and easy way to bring XML into line and get it to help you. This is a useful, quick means of inserting form validation into your pages. Maybe it'll even be enough to make me stop shirking around and use form validation on my own site. You never know.

What are the advantages and disadvantages of this method?

The advantages, as I see them, are:

• Unobtrusive - no changes are required to the structure of your page, beyond the insertion of the JavaScript and maybe a few ids here and there.
• Easy to change - if you discover an error in some of your validation, or realize that something which, previously, did not need validation now does, you can quickly update your XML file and upload it to your Website again.
• User-friendly - when users type an incorrect value into a form field, they're informed obviously and immediately.

The disadvantages are:

• Compatibility – Currently, this code works only in IE 5+ and Mozilla.
• Limited - To keep things simple, this solution currently supports only textual inputs. Of course, anybody is free to extend the current script to more complicated form validation routines should they wish to.

I hope that I've expanded your horizons on the possibilities of using XML to improve your Web pages – or, at the very least, that I've given you a neat new form validation trick to add to the toolbox.

Acknowledgements

Peter-Paul Koch's Import XML page [5] was very helpful for providing a working script that only needed slight modification.

Scott Andrew's addEvent function [6] (found via Simon [7]) was similarly helpful in speeding things along.

Finally, Mike Hall's DHTML Events page [8] saved my sanity when struggling with the differing event models in Mozilla and Internet Explorer.

[1] http://www.sitepoint.com/article/989
[2] http://www.sitepoint.com/article/xml-javascript-mozilla
[3] http://www.sitepoint.com/examples/xmlvalidation/xmlvalidation.zip
[4] http://kalsey.com/simplified/form_errors/
[5] http://www.quirksmode.org/dom/importxml.html
[6] http://www.scottandrew.com/weblog/
[7] http://simon.incutio.com/
[8] http://brainjar.com/dhtml/events/