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?”
When building an XML vocabulary, I like to keep a few rules in mind. The vocabulary should be:
- Easily understandable
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.
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.
<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.
<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
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.
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.
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.
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:
- 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.
Peter-Paul Koch’s Import XML page was very helpful for providing a working script that only needed slight modification.
Finally, Mike Hall’s DHTML Events page saved my sanity when struggling with the differing event models in Mozilla and Internet Explorer.