1.3 XForms Components

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 .


All nonpresentational aspects of a Web application are encapsulated by the XForms data model. The data model incorporates an XML instance that holds user input, the constraints used to validate this input, and the necessary metadata about how this user input should be communicated to the Web server.


XForms defines a user interface vocabulary that consists of abstract controls and aggregation constructs used to create rich user interfaces. The user interface vocabulary is designed to capture the underlying intent of the user interaction, rather than its final presentation on any given device or in any specific modality. This makes it possible to deliver XForms-based Web applications to different devices and modalities.


This allows the Web application author to specify where, how, and what pieces of data to submit to the Web server. It also permits the application developer to specify what actions to take upon receiving a response from the server.

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 [11] document that defines the structure of the XML instance ”see Figure 1.3.

[11] http://www.w3.org/tr/xschema

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 [12] 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.

[12] Attribute xsi:type is defined by XML Schema.

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 [13] is available from the Apache project implements XML Schema and can be used to validate data collected on the server.

[13] http://xml.apache.org/ xerces-j

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:

  • 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 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.


Figure 1.5 illustrates the following XForms features:


Attributes model and ref on element input specify the portion of the instance to be populated by the value obtained via this control. Attribute model gives the id of the person model; Attribute ref addresses node /person/age of this instance. The syntax used to address portions of the instance is defined by XPath. [14]


Elements label , help , hint , and alert encapsulate metadata to be displayed to the user at various times. Notice that in XForms the label for the user interface control is tightly bound to the associated control; this is an extremely useful accessibility feature. Elements hint and help encapsulate tool tip text and detailed help to be displayed upon request. Finally, element alert holds the message to be displayed in the case of invalid input. Notice that the alert message uses element output to access the value supplied by the user. Element output uses XPath to address the relevant portion of the data model.

For simplicity, this example has shown elements label , hint , and help with inline content. For more complex applications, the contents of these elements can be specified indirectly via a URI by using attribute src . This feature can be used to advantage in localizing XForms-based Web applications by factoring all such messages into an XML file, referring to portions of that XML file using URIs within the XForms Web application, and loading these XML files to provide locale-specific messages.


Attribute ev:event on element input sets up control input to respond to event DOMActivate by calling the handler located at #speak . This uses the syntax defined in XML Events [15] for authoring DOM2 Events and is described in Section 2.3.


Hints can be provided via attribute appearance .


Attribute class specifies a Cascading Style Sheet (CSS [16] ) style to use for styling this control. CSS is a style sheet language that allows authors and users to attach style (for example, fonts, spacing, and aural cues) to structured documents (for example, XHTML documents).


Attribute accesskey specifies an accelerator key for navigating to this control. This was an accessibility feature first introduced in HTML and has been incorporated into XForms.

[14] http://www.w3.org/tr/xpath

[15] http://www.w3.org/tr/xml-events

[16] http://www.w3.org/TR/CSS2/

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:

Serve content

The server produces a presentation that is appropriate for the connecting device.

Code generation

The XForms server can generate client-side validation code to be embedded in the markup being served to the connecting client. This provides client-side validation and immediate user feedback, but without the cost of requiring the Web developer to hand-craft such validation scripts.

Data Validation

Validate user data against the constraints given in the model.

State management

Maintain application state by implementing the XForms processing model. As a result, the developer of the questionnaire need write no special software for maintaining values submitted by the user between client-server round-trips.

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


Consume the XForms-authored application to produce the client-side user interface.


Check user input against the validation rules to provide live feedback.


Submit a valid XML instance on completion.

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.


XForms. XML Powered Web Forms with CD
XForms. XML Powered Web Forms with CD
Year: 2003
Pages: 94

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net