Chapter: XML and Web Services : Building XML-Based Applications : Formatting XML for the Web
An Overview of XForms
An Overview of XForms
One of the primary uses of the Web by businesses is to gather data from
the visitors to their Web sites. Forms provide a powerful mechanism for users
to interact with Web sites. HTML forms, and more recently XHTML forms, have
been used for this purpose. Currently, the W3C organization is working on the
next generation of Web forms: XForms. On August 28, 2001 the XForms 1.0 working
draft was released.
Even though XForms is only a working draft at this point, it is
important to at least get a good general understanding of XForms. XForms is
going to be one of the vital technolo-gies that drives the Web in the future.
Introduction to XForms
Forms were first introduced to the Web in 1993. Since then, forms have
grown to be a vital part of the user interaction with Web sites. More recently,
HTML forms developers have been able to start restructuring their forms to be
XHTML compliant. This makes forms XML 1.0 compatible; however, this does not
really change any of the shortcom-ings of old HTML forms. HTML forms fail to
provide any separation of presentation from data and logic. There are very
limited facilities in HTML forms (short of doing a bunch of script programming,
which is not even supported in all browsers) for tracking user input during
form filling. XForms is being designed to solve these problems.
Next Generation of Web Forms
XForms provides the next logical step in the evolvement of forms on the
Web. The XML standard dictates that structure be separated from presentation.
XForms as an XML application accomplishes this.
Successor to HTML Forms
As stated, XForms is being designed to be the successor to HTML forms.
Let’s take a quick look at Listing 11.22, which shows a typical HTML form.
LISTING 11.22 Typical HTML Form
<html>
<head>
<title>Typical HTML Form</title> </head>
<body>
<form action=”processexample.asp” method=”post”> <p>Please
enter your personal information:</p> <table>
<tr>
<td>Name:</td>
<td><input type=”text” id=”txtName”
name=”txtName”></td> </tr>
<tr>
<td>Age:</td>
<td>
<select id=”cboAge” name=”cboAge”> <option>Less than
18</option> <option>18 - 35</option> <option>Over
35</option>
</select>
</td>
</tr>
<tr>
<td>Gender:</td>
<td>
<select id=”cboGender” name=”cboGender”>
<option>Male</option> <option>Female</option>
</select>
</td>
</tr>
<tr>
<td colspan=”2”><input type=”submit”
value=”Submit”></td> </tr>
</table>
</form>
</body>
</html>
You can see that this is a regular HTML form typical of what you will
find on most Web sites. Presentation of the form is combined with the purpose
of the form. Additionally, there is no control over the data entered by the
user prior to form submission. Figure 11.6 demonstrates how this form would be
rendered in Internet Explorer 5.5.
In XForms, there are separate sections used to describe the purpose of
the form and the presentation of the form. This provides a great advantage over
HTML because XForms makes no requirement of how the form should be presented.
This makes XForms very rich and flexible. XForms may just as easily be
displayed using XHTML form controls as WML form controls. This is because
XForms does not predetermine the type of con-trol that must be used to collect
the data. XForms merely dictates the type of data that should be collected.
Listing 11.23 shows how the form in Listing 11.22 would be rewrit-ten using
XForms.
LISTING 11.23 XForms Web Form
<xform:input ref=”txtName”> <xform:caption>Name</xform:caption>
</xform:input>
<xform:selectOne ref=”cboAge”>
<xform:caption>Age</xform:caption> <xform:choices>
<xform:item value=”Less than 18”><xform:caption>Less than 18
</xform:caption></xform:item>
<xform:item value=”18 - 35”><xform:caption>18 -
35</xform:caption></xform:item> <xform:item value=”Over
35”><xform:caption>Over 35</xform:caption></xform:item>
</xform:choices>
</xform:selectOne> <xform:selectOne ref=”cboGender”>
<xform:caption>Gender</xform:caption>
<xform:choices>
<xform:item
value=”Male”><xform:caption>Male</xform:caption></xform:item>
<xform:item
value=”Female”><xform:caption>Female</xform:caption></xform:item>
</xform:choices>
</xform:selectOne>
<xform:submit>
<xform:caption>Submit<xform:caption>
</xform:submit>
You can immediately see in this listing that the user interface is not
hard-coded to use select boxes and text boxes, as is the case in the HTML form
in Listing 11.22. The list-ing merely specifies that the data that should be
gathered. Different clients can render the interface as appropriate. The id and name attributes have been replaced by
the ref attribute, which is an XML ID
type of attribute that uniquely identifies the XForms control.
Several other things should be noted about Listing 11.23. There is no form element. This is not required in
XForms. Also, when the form is submitted, the data will be submitted as XML
data. Data entered in this XForms form by a user might look like what appears
in Listing 11.24.
LISTING 11.24 Submitted XForms Data
<Envelope>
<Body>
<txtName>Michael Qualls</txtName> <cboAge>18 -
34</cboAge> <cboGender>Male</cboGender> </Body>
</Envelope>
XForms submits well-formed XML data. Once this data is received by the
server, it may be validated against a DTD by an XML parser.
Comparing Listing 11.23 with Listing 11.22 shows the very clear
divergence of XForms with HTML forms. Before we go on to look at the specific
parts of XForms, let’s take a quick look at the other ways that XForms differs
from HTML forms.
Based on XML
XForms is, of course, an XML technology. This opens up XForms to using
all the differ-ent permutations of XML on the Web, such as XHTML, WML, and XSL.
It appears that XSL is going to be very important in relation to XForms. As
stated, the XForms working draft makes no requirements for how forms should be
presented. XSL will be able to be used to transform XForms documents to meet
the presentation requirements of any clients using the form.
Platform Neutral
XForms is platform neutral. As an XML technology, no specific
requirements are made in order to use XForms. XForms may be formatted for
display as easily for handheld devices, as for cellular phones, and as for
desktop computers (within reason, of course; the display limitations of some
devices would have to be taken into account).
Works with XHTML
XForms may be displayed using XHTML. As a matter of fact, the W3C is
working on a DTD that combines XHTML 1.1 with XForms. Once integrated, XForms
will not only provide complete separation of purpose and presentation but will
be completely modular-ized. At the time of this writing, the DTD has not been
completed.
XForms: Three Layers
XForms forms technology is split into three layers. These layers are
purpose, presenta-tion, and data. We will now look at each of these layers and
see how they relate to the overall design goals of XForms.
Purpose Layer
As has been stated several times previously, the purpose of the form and
the presentation of the form are separated in XForms. But what does this
actually mean? As you saw in Listing 11.22, the purpose and the presentation
were combined in the HTML form. In that listing, HTML form elements were
hard-coded into the page. The presentation was predetermined for any clients
loading the page. When viewing Listing 11.23, you quickly see that there is no
defined presentation. The actual main form elements, referenced from the XForms
namespace, are input and selectOne. Both of these elements make their purpose very clear. The input element expects some input from
the user, and selectOne allows the user to choose one of several defined options (the choices child element con-tains the
options available). However, although the purpose of the form is clear, there
is no indication of how the form should be displayed. It is left totally to the
client to config-ure the presentation.
Presentation Layer
The presentation layer of XForms is actually dependent on the client
loading the XForms document. An XForms document could be rendered in HTML,
XHTML, or WML. XForms could even be configured for delivery to an audio device
or a Braille device. This is one area where the presentation capabilities truly
transcend the abilities of HTML forms. The handicapped accessibility to XForms
documents is greatly enhanced over the abilities of more traditional forms of
electronic data gathering.
Data Layer
It might seem odd to say that there is a data layer. The data is entered
into the form fields that are rendered by the client device. It would seem that
data should be part of the pre-sentation layer, or it might seem appropriate to
make data part of the purpose layer because the purpose layer defines the type
of data being gathered. However, there is indeed a data layer to XForms. You
see, although data might be entered into the form fields, there is another part
of the XForms document that is actually tracking this data as it is being
entered: the data layer. There is actually an XForms construct placed within
the head element
of the XForms document. Listing 11.25 shows what the data layer might look like
for the XForms form from Listing 11.23.
LISTING 11.25 XForms Data Layer
<xform:xform>
<xform:submitinfo action=”processexample.asp” method=”post” />
<xform:instance>
<personalinfo > <txtName />
<cboAge />
<cboGender />
</personalinfo>
</xform:instance>
</xform:xform>
Three elements in this listing have names that match the values of the ref attributes of the form elements
defined in Listing 11.23. These elements serve as placeholders for the values
entered into the form elements. These elements are wrapped inside of the
wrapper element personalinfo. The wrapper element may be of the author’s choosing. It is these
placeholders that give us the ability to perform instance tracking of the
values users input while filling out the form. This is the next factor that
makes XForms superior to HTML forms. We will now take a look at instance data
tracking.
Instance Data Tracking
Instance data tracking gives the XForms author greater control over user
input. As stated previously, data submitted by an end user via an XForms
document could be validated against a DTD on the server. Using instance data
tracking, it’s even possible to validate user input during form entry—prior to
form submission. Sure, this type of validation is available in HTML if you want
to write a bunch of JavaScript to track user entries, but then you have to
rewrite the JavaScript to achieve compatibility for each of the Web browsers
used to visit your Web site. No extra code is needed to write with XForms. This
will be a feature included with the XForms parser.
Tracks Partially Filled Forms
Listing 11.25 demonstrated the data layer in XForms. In order to use the
data layer to track form filling for partially filled forms, a namespace is
created for the placeholder elements in the data layer. Listing 11.26
demonstrates how a namespace could be refer-enced for a XForms data layer in a
document that is using a combination of XHTML and XForms to create the form.
LISTING 11.26 XForms Data Instance
Tracking—Namespace
<?xml version=”1.0” encoding=”UTF-8”?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN”> <html
xmlns=”http://www.w3.org/1999/xhtml”
xmlns:xform=”http://www.w3.org/2001/08/xforms”
xmlns:info=”http://mydomain.example.com/personalinformation”xml:lang=”en”>
<head>
<title>Referencing a namespace for instance data
tracking</title> <xform:xform>
<xform:submitinfo action=”processexample.asp” method=”post” />
<xform:instance>
<info:personalinfo > <info:txtName /> <info:cboAge />
<info:cboGender /> </info:personalinfo> </xform:instance>
</xform:xform> </head>
…
</html>
Listing 11.26 is not a complete document. It only includes the
declaration statements, the head element and its contents, and the root element, html. In the html element, three namespace are referenced. The first
two are for the XHTML and XForms namespaces. The third is the namespace for
placeholder elements. The namespace is referenced by attaching the prefix “info:” to the wrapper element, personalinfo, and to the place-holder
elements, txtName, cboAge, and cboGender.
Now we are ready to start tracking partial form filling. We just need to
connect the actual form elements to the placeholder elements.
Connects with Form Elements
In order to connect our form elements with the placeholder elements in
the XForms data layer, we must reference the placeholder elements from the ref attribute of each of the form
elements. Listing 11.27 shows how the placeholder elements are referenced.
LISTING 11.27 Connecting with Form
Elements
<xform:input ref=”info:personalinfo/info:txtName”>
<xform:caption>Name</xform:caption>
</xform:input>
<xform:selectOne ref=”info:personalinfo/info:cboAge”>
<xform:caption>Age</xform:caption>
<xform:choices>
LISTING 11.27 continued
<xform:item value=”Less than 18”><xform:caption>Less than 18
</xform:caption></xform:item>
<xform:item value=”18 - 35”><xform:caption>18 -
35</xform:caption></xform:item> <xform:item value=”Over
35”><xform:caption>Over 35</xform:caption></xform:item>
</xform:choices>
</xform:selectOne>
<xform:selectOne ref=”info:personalinfo/info:cboGender”>
<xform:caption>Gender</xform:caption>
<xform:choices>
<xform:item
value=”Male”><xform:caption>Male</xform:caption></xform:item>
<xform:item
value=”Female”><xform:caption>Female</xform:caption></xform:item>
</xform:choices>
</xform:selectOne>
<xform:submit>
<xform:caption>Submit<xform:caption>
</xform:submit>
Listing 11.27 is very similar to Listing 11.23. However, there is one
major difference: The value of the ref attribute for each form element has been updated to point to a
placeholder element.
Now the form elements are connected with the placeholder elements.
During the form-filling process, prior to form submission, the XForms parser
will have access to the val-ues that the end user is entering into the form elements.
Is XPath Based
In Listing 11.27, XPath statements were used as the values of the ref attributes to con-nect the form
elements with the placeholder elements. This is another example of how using
XForms, an XML application, will enable us to incorporate more XML
technolo-gies to complete our tasks.
Rich Data Type and Form Validation
XForms adopts the XML Schema data typing system. This enables the author
to specify the type of data that is expected to be entered into the form
fields. From this, the XForms parser can be used to enforce the proper data
typing. A very simple example of how validation and data typing can be used is
demonstrated in Listing 11.28.
LISTING 11.28 Data Typing and Form
Validation
<xform:xform>
…
<xform:bind ref=”info:personalinfo/info:txtName” required=”true”
LISTING 11.28 continued
type=”xsd:string”
/>
<xform:bind ref=”info:personalinfo/info:cboAge” required=”true”
type=”xsd:string”
/>
<xform:bind ref=”info:personalinfo/info:cgoGender” required=”true”
type=”xsd:string”
/>
…
</xform:xform>
The XForms bind element is used to indicate that each of the form elements is required
and that the data type will be a character string. The ref attribute, once again, has its
value set to an XPath expression that points to the placeholder elements in the
data layer. Now the XForms parser can make sure that the required elements are
present and that the proper data types are entered.
Multiple Form Documents
Finally, it should be noted that XForms places no limitations on the
number of forms per document. When multiple forms share the same document,
multiple xform elements will be required. Each of the xform elements following the first xform element must have a unique ID type of attribute so that it can be
referenced uniquely from other parts of the document. Additionally, when
multiple xform elements are used, each of the form ele-ments on the document will need
an IDREF type of
attribute, xform, along side its ref
attribute so that it can be associated with the proper xform element. Listing 11.29 shows how
an xform element
would be referenced from a form element in a multiple-form document.
LISTING 11.29 xform Element
Reference from a Form Element
<xform:input ref=”txtEMailAddress” xform=”contactinfo”>
<xform:caption>Email Address</xform:caption> </xform:input>
<xform:submit xform=”contactinfo”>
<xform:caption>Submit</xform:caption> </xform:submit>
In this listing, a new attribute, xform, has been added to the XForms input element and submit element. The xform attribute is an IDREF that references the ID attribute for an xform element defined elsewhere in the document. This establishes a clear
relationship between
the form elements and the xform element in a multiple-form document.
Related Topics