Introduction to XForms: XML Powered Web Forms

This chapter is from the book

XForms: XML Powered Web Forms

Learn More Buy

This chapter is from the book

This chapter is from the book 

XForms: XML Powered Web Forms

Learn More Buy

1.3 XForms Components

The previous section traced the development of a simple Web application using present-day technologies predicated by the HTML forms architecture. The questionnaire application evolved from a simple stand-alone CGI script to a more complex Web application consisting of software components dedicated to managing the application state within a servlet, markup pages designed to create the user interaction, and navigation components designed to connect the various views with the application state. In doing so, we saw that the Web developer needed to implement significant application-specific functionality in custom software to deliver the questionnaire to a Web browser.

XForms leverages the power of using XML in modeling, collecting, and serializing user input. XForms has been designed to abstract much of this functionality into a set of components that enable the Web developer to rely on a standard set of services and off-the-shelf XML tools when developing the final Web application. This allows the Web developer to focus on key aspects of the application and rely on the underlying XForms platform for the following services:

• Produce user interfaces appropriate for the connecting device.

• Provide interactive user feedback via automated client-side validation.

• Validate user input on the server automatically.

• Marshal user input on the server into a structure suitable for the back-end application.

Based on what has been observed in the design of today’s Web applications and the need to deliver such applications to an ever-increasing array of end-user devices, the overall XForms architecture has been divided into the following components. A key feature of this MVC decomposition is a clear separation of the model from its final presentation.

1.3.1 XForms Overview

Next, we reexamine the questionnaire and recast it as an XForms application. The questionnaire will be created as an XHTML document that contains the XForms model and user interface components. The following subsections detail each of these components and show how they are used within an XHTML document. The XForms model (contained in 〈model〉) is placed within XHTML element 〈head〉. XForms user interface controls create the user interaction and appear within the body of the document, that is, within XHTML element 〈body〉, and are rendered as part of the document content. In this overview, we will describe a few of the XForms user interface controls to give the reader a feel for XForms markup; subsequent chapters will detail all the constructs defined in XForms 1.0.

1.3.2 XForms Model

As before, we start by enumerating the various items of user information collected by the Web application. Since we are now using XML, we no longer need restrict ourselves to a flat data model consisting of a set of untyped name-value pairs. Instead, we encapsulate the information collected from the user in a structured XML document. This is called the XML instance. Further, we pick the structure of this XML instance to suit the survey application—see Figure 1.2.

Figure 1.2 Element 〈instance〉 declares the XML template that holds user input and default values.

<model xmlns="http://www.w3.org/2002/xforms" id="p1">
   <instance>
   <person xmlns="">
   <name><first/><last/></name>
   <age/><email/>
   <address><street/><city/><zip/></address>
   <birthday><day/><month/><year/></birthday>
   <ssn>000-000-000</ssn>
   <gender>m</gender>
   </person>
   </instance>
   </model>
   

Notice that compound data items such as address are now modeled to reflect the structure of the data, unlike when using flat name-value pairs. This also obviates the need to introduce intermediate fields to hold portions of the user data and the subsequent need to marshal such intermediate fields into the structure required by the application.

Next, this XML instance can be annotated with the various constraints specified by the application, for example, age should be a number. When using XML, such constraints are typically encapsulated in an XML Schema¹¹ document that defines the structure of the XML instance—see Figure 1.3.

Figure 1.3 Constraining instance data by specifying an XML Schema.

<model xmlns="http://www.w3.org/2002/xforms"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   schema="person.xsd" id="p1">
   <instance>
   <person xmlns="">...</person>
   </instance>
   </model>
   

Alternatively, such type constraints can be specified as part of the instance using attribute xsi:type¹² as shown in Figure 1.4. Both techniques have their place in Web development; the former is especially relevant when creating Web applications that access existing business logic, and the latter is useful when creating a one-off Web application with relatively simple type constraints.

Figure 1.4 XML representation of the data collected by a questionnaire application, along with some simple type constraints.

<model id="p1" xmlns:xsi=
   "http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://www.w3.org/2002/xforms"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <instance>
   <person xmlns="">
   <name><first/><last/></name>
   <age xsi:type="xsd:number"/>
   <birthday>
   <day xsi:type="xsd:number"/>
   <month xsi:type="xsd:number"/>
   <year xsi:type="xsd:number"/>
   </birthday>
   <address>
   <street/><city/><zip/>
   </address>
   <email/><ssn>000-000-000</ssn>
   <gender>m</gender></person>
   </instance></model>
   

In the questionnaire application, the constraints shown in Figure 1.4 encapsulate type constraints—the default type is string. Complex schemas typically encapsulate more constraints, such as specifying the rules for validating a 9-digit Social Security Number or specifying the set of valid values for the various fields. Note that this example has been kept intentionally simple—later chapters will build real-world examples where we will use the full richness of the built-in type mechanisms provided by XML Schema.

The advantage of specifying such constraints using XML Schema is that the developer can then rely on off-the-shelf XML parsers to validate the data instance against the supplied constraints. With the increasing adoption of XML Schema by database vendors, complex business applications are likely already to have an XML Schema definition for the data model, and the developer can leverage such existing assets when creating a Web application. XML processor xerces¹³ is available from the Apache project implements XML Schema and can be used to validate data collected on the server.

Finally, the constraints on the data instance are now encapsulated in declarative XML—as opposed to imperative program code—thus making it easier to maintain and revise these constraints using XML-aware tools without having to reprogram the application.

1.3.3 XForms User Interface

This section creates a sample XForms user interface for the questionnaire application and binds this user interface to the XForms data model defined in the previous section. XForms user interface markup appears within XHTML element 〈body〉 along with other document markup. Notice that because of the separation of the model from the user interaction, XForms user interface markup can appear anywhere within the contents of XHTML element 〈body〉; in contrast, when using HTML forms, user interface controls can appear only within element 〈form〉.

In the questionnaire application, XForms user interface control 〈input〉 can be used to collect each item of data. User interface control 〈input〉 is intentionally designed to be generic. The type of information available about the underlying data item, for example, birthday is a date, can be used to advantage in generating a user interface representation that is appropriate to the connecting device, for example, rendering it as a calendar on a desktop browser. Notice that in addition to making the resulting user interface customizable for the connecting device, this design provides a rich level of accessibility for supporting users with different needs.

UI Control Input

Here, we review different aspects of UI control 〈input〉 in some detail; later chapters will review all of the XForms user interface controls. See Figure 1.5 for the markup that creates the input field for obtaining the user’s age and Figure 1.6 for the resulting user interface. XForms controls encapsulate the following pieces of information needed to render the interaction and connect the result to the appropriate portion of the XForms data model:

Figure 1.5 User interface control for obtaining the user’s age.

<input xmlns="http://www.w3.org/2002/xforms"
   xmlns:ev="http://www.w3.org/2001/xml-events"
   model="p1" ref="/person/age" class="edit"
   ev:event="DOMActivate" ev:handler="#speak"
   accesskey="a"><label>Age</label>
   <help>Specify your age as a number e.g., 21</help>
   <hint>How young are you?</hint>
   <alert>The age you specified,
   <output  ref="/person/age"/>is not a valid age.
   </alert></input>
   

Figure 1.6. User interface for obtaining the user’s age.

• Binding attributes that wire control to model

• Metadata for giving feedback to the user

• Wiring up of events and event handlers

• Presentation hints

• CSS style rules

• Keyboard shortcuts and navigation hints

Figure 1.5 illustrates the following XForms features:

UI Control select1

The field corresponding to the user’s gender can have one of two legal values, m or f. The user must pick one of these values. Using traditional HTML forms, the corresponding user interface would be authored as a group of radio buttons. Notice that the HTML design hard-wires a particular presentation (radio buttons) to the underlying notion of allowing the user to select one and only one value. However, radio buttons may not always be the most appropriate (or even feasible) representation, given the device or modality in use; for instance, a radio button does not make sense when using a speech interface.

XForms separates form from interaction by capturing abstract notions such as select from a set. This enables the XForms author to create user interfaces that can be delivered to different target modalities and devices. XForms user interface control 〈select1〉 can be used instead of 〈input〉 to obtain the user’s gender in the questionnaire example—see Figure 1.7 for the XML markup and Figure 1.8 for the resulting user interface.

Figure 1.7 XForms user interface control for selecting a single value.

<select1 xmlns="http://www.w3.org/2002/xforms"
   model="p1" ref="/person/gender" appearance="full">
   <label>Select gender</label>
   <help>...</help>
   <hint>...</hint>
   <item><label>Male</label>
   <value>m</value></item>
   <item><label>Female</label>
   <value>f</value></item>
   </select1>
   

Figure 1.8. XForms user interface for selecting a single value.

As in the previous example, binding attributes model and ref specify the location where the value is to be stored. Attribute appearance is set to full to indicate that the client should create a full representation of this control; in the case of a visual presentation, this might be realized by using a group of radio buttons. Element 〈item〉 encodes each of the available choices. Subelement 〈label〉 contains the display value; subelement 〈value〉 encodes the value to be stored in the instance. The default value m is obtained from the model—see Figure 1.2. The author can style the interface further by using Cascading Style Sheets (CSS).

1.3.4 XForms Submit

The final stage of the questionnaire user interaction is to have the user submit the information. Using HTML forms, this is achieved by creating a submit button within HTML element 〈form〉. Activating the corresponding user interface control results in all values created as part of the containing 〈form〉 being submitted to the URI specified via attribute action.

As mentioned earlier, a key feature of XForms is to separate the model from the interaction. XForms preserves this separation in its design of data submission. Submission details covering

• What to submit,

• Where to submit,

• How to submit

that are independent of the presentation are encapsulated by element 〈submission〉 within element 〈model〉. XForms user interface control 〈submit〉 when activated dispatches an appropriate xforms-submit event to the relevant 〈submission〉 element. Upon receiving this event, the XForms processor serializes the values stored in the instance before transmitting the result as specified by element 〈submission〉.

For the questionnaire example, we first extend the model shown in Figure 1.2 with an appropriate 〈submission〉 element—see Figure 1.9.

Figure 1.9 Element 〈submission〉 models what, where, and how to submit.

<submission xmlns="http://www.w3.org/2002/xforms"
   id="s0" method="post"
   action="http://example.com/survey"/>
   

User interface control 〈submit〉 in Figure 1.10 uses attribute submission to connect the user interface to the model. We show the resulting user interface in Figure 1.11.

Figure 1.10 XForms user interface control for submitting the questionnaire.

<submit xmlns="http://www.w3.org/2002/xforms"
   submission="s0"><label>Submit</label>
   </submit>
   

Figure 1.11. Visual representation of XForms submit control.

1.3.5 The Complete XForms Questionnaire

This section combines the model and user interface developed so far to create the complete XForms questionnaire. The resulting XForms application is contained in an XHTML document. The complete example uses XML namespaces so that markup elements defined by different XML languages such as XForms and XHTML are clearly identified—see Figure 1.12.

Figure 1.12 The complete XForms questionnaire.

<html xmlns="http://www.w3.org/1999/xhtml"
   xmlns:xf="http://www.w3.org/2002/xforms"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <head><title>XForms Questionnaire</title>
   <xf:model schema="questionnaire.xsd">
   <xf:instance xmlns="">
   <person>...</person>
   </xf:instance>
   <xf:submission action="..."
   method="post" id="s0"/>
   </xf:model></head>
   <body>...
   <xf:input ref="/person/address/street">
   ...</xf:input>...
   <xf:submit submission="s0">
   <xf:label>Submit questionnaire</xf:label>
   </xf:submit></body>
   </html>
   

1.3.6 Deploying the XForms Questionnaire

The XForms questionnaire can be deployed in a variety of ways depending on the XForms processor being used. This section details a variety of deployment scenarios.

The questionnaire can be deployed on an XForms-aware Web server that provides the following:

The XHTML document hosting the XForms questionnaire could be served to conforming XForms clients. An XForms client would implement the following:

Notice that in the deployment scenarios, the Web developer need only create the XForms questionnaire; contrast this with the application-specific components needed when deploying HTML forms—compare Figure 1.1 with the software components needed to deploy the XForms questionnaire shown in Figure 1.13.

Figure 1.13. Deploying the XForms questionnaire.