XForms: The new generation Web form
The submission of data on any Web site is pretty much its lifeblood. From registration to purchases, we constantly request data from our end users, often using the typical HTML form that has been around since the Internet's inception. Now, however, we have XForms, a new generation of Web forms developed under the guidance of the W3C.
One of the biggest disadvantages of using current HTML forms is data validation. Although we can never guarantee that the data submitted by an end user is valid in its truest sense, as developers we generally go to great lengths to assure that it is, at a minimum, syntacticly correct. We verify that a field holds an email structure where one is expected, and check for data that contains only digits where a phone number is to be given.
Even though mainstream Web development platforms have devised ways to reduce this burden, they are all based on some form of server-side mechanism. XForms is a client-side solution. It's a standard developed by the World Wide Web Consortium, which will eventually guarantee its integration into mainstream browsers.
Much like other emerging technologies, XForms in its current state can be executed only through third-party browser plug-ins or standalone applications. That means a wide-scale deployment on a production Web site could be troublesome for your end users, but you can still build working prototypes and eventually roll them out at your discretion.
Among the current standalone XForm engines are XForms Explorer , by Novell, and X-Smiles, developed by the University of Helsinki, both of which are Linux-friendly since they are based on Java. For Internet Explorer users there is a plug-in named formsPlayer and an IBM alphaWorks XML Forms package. Unfortunately, for other mainstream browsers like the Mozilla family and Opera, there is no clear road to XForms yet. There are a number of XForms implementations being developed besides these that vary in maturity, but these are the most established to date.
Let's illustrate a fairly straightforward XForm:
NOTE: This XForm was tested on X-Smiles.
Other provisions and plug-in declarations
might be needed for other browsers.
<title> One way reservation system </title>
<xform:bind constraint=". > 0"
<xform:bind constraint=". > 0"
calculate="(/flight/adults/number * /flight/adults/price) +
(/flight/children/number * /flight/children/price)"
One way reservation system
<table align="center" border="5">
<tr><td> From : Anywhere </td>
<td> To : Anywhere </td>
No. of Children
We start by declaring the typical elements in an XHTML document: <html>, <head>, and <title>, with the small variant of adding three extras namespaces for XForms elements XML-Events and Schemas.
The first piece of our XForm is enclosed within the <head> elements and includes a series of logical structures which are appropriately nested in the <xform:model> tag. The element named xform:submission declares the server-side page that will process the XForm, while xform:instance defines the XML data model that will be used throughout the XForm. In our case, the file named flightmodel.xml would have the following structure:
<?xml version="1.0" encoding="ISO-8859-1"?>
Once our data instance has been declared, we are free to start defining constraints or logical processes on it by using xform:bind elements. The first declaration restricts our departure element to a Schema standard date. The actual syntax used in the ref attribute is XPath-based. We next define both our number elements to be integers and have values grater than zero through the type and constraint attributes respectively. Finally, we declare a mathematical operation through the calculate attribute and place its corresponding result in the total element, followed by the closing of the <xform:model> tag.
With the XForm model defined, we are now in a position to open the typical <body> XHTML tag and define the XForm elements that will be rendered onto the screen. Our first two declarations use the xform:output element to display an actual part of our data model. Using the ref attribute we call two price elements present in our model. We then define two xform:input elements with which users will provide information. Notice that each of these elements also defines a ref attribute to hook into the data model. Ending our XForm, we define the xform:submit element, which is used to generate a submission button, and a special reset button xform:reset to reinitialize our data model to its original state.
Among the highlights of executing the previous XForm are the following:
- Every change in input automatically triggers a modification in the data model, which propagates to the actual data display.
- If you try to enter data that is out of the scope as defined in the data model, the browser underlines the errors.
- The actual payload submitted to the server-side script is the same modified XML model.
Although we outlined the advanced logic capabilities available through XForms, the specification as a whole has a much wider scope than this particular feature, much like the ambitions set out for XHTML when compared to classic HTML. XForms is set to be supported on handheld devices, as well as provide seamless integration with other XML technologies, making it a must-know subject for the coming years.