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 and XML and JavaScript in Mozilla) 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.
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.
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 was very helpful for providing a working script that only needed slight modification.
Scott Andrew’s addEvent function (found via Simon) was similarly helpful in speeding things along.
Finally, Mike Hall’s DHTML Events page saved my sanity when struggling with the differing event models in Mozilla and Internet Explorer.
Frequently Asked Questions (FAQs) about XML Form Validation
What is XML form validation and why is it important?
XML form validation is a process that checks the data input in an XML form against a predefined set of rules or schema. This is important because it ensures the data entered is accurate, consistent, and in the correct format. Without validation, incorrect or inconsistent data can lead to errors, misinterpretation, or even data loss. Therefore, XML form validation is a crucial step in maintaining the integrity and reliability of your data.
How does XML form validation work?
XML form validation works by comparing the data entered in an XML form against a predefined schema. The schema defines the structure of the XML document, including the elements and attributes that can appear, their data types, and their relationships to each other. If the data entered does not match the schema, the validation process will return an error.
What are the common types of errors in XML form validation?
Common types of errors in XML form validation include missing required elements, incorrect data types, and values that are out of range. For example, if a form requires a date in the format “YYYY-MM-DD” and the user enters “12/31/2020”, the validation process will return an error because the date is not in the correct format.
How can I create a schema for XML form validation?
A schema for XML form validation can be created using a variety of tools and languages, including XML Schema Definition (XSD), Document Type Definition (DTD), and RELAX NG. These tools allow you to define the structure of your XML document, including the elements and attributes that can appear, their data types, and their relationships to each other.
Can I use XML form validation with other programming languages?
Yes, XML form validation can be used with a variety of programming languages, including Java, C#, and PHP. Many of these languages have libraries or modules that provide support for XML form validation.
What are some best practices for XML form validation?
Some best practices for XML form validation include using a schema to define the structure of your XML document, providing clear error messages to help users correct their data, and testing your validation process with a variety of data inputs to ensure it works correctly.
How can I handle errors in XML form validation?
Errors in XML form validation can be handled in a variety of ways, depending on the programming language and tools you are using. Some common methods include displaying an error message to the user, logging the error for debugging purposes, or throwing an exception to halt the execution of the program.
Can I customize the error messages in XML form validation?
Yes, most tools and languages that support XML form validation allow you to customize the error messages. This can be helpful for providing more specific feedback to users and for localizing your application for different languages or regions.
What is the difference between client-side and server-side XML form validation?
Client-side XML form validation is performed in the user’s browser before the form data is sent to the server. This can provide immediate feedback to the user and reduce the load on the server. Server-side validation is performed after the form data is received by the server. This is necessary to protect against malicious or malformed data that could bypass client-side validation.
Can I use XML form validation with HTML forms?
Yes, XML form validation can be used with HTML forms. The form data can be converted to XML for validation, and then converted back to HTML for display or further processing. This can be done using a variety of tools and languages, including JavaScript, PHP, and XSLT.
Currently studying at Swinburne University, Lachlan made his first Web page in 1999... A geocities Web page... With rotating animated GIFs. He hopes that in time people will forgive him. His current Webpage is http://illuminosity.net/.