XML News Desk

Digg This!

Page 1 of 2   next page »

HTML forms are one of the best-known techniques for gathering data from a user and submitting that data to a server. However, HTML forms are only simple tools and don't natively support some of the features needed by current Web applications such as sophisticated data validation. Also, the user interface created by HTML forms is essentially hard coded for one device, meaning the same form can't be easily re-tasked for, say, PDAs or mobile phones.

The W3C XForms Recommendation is one way of addressing some of these issues. (XForms is both plural and singular, so there's no XForm, only XForms.) XForms are XML tags embedded in host documents such as XHTML that, when rendered by an XForms-aware browser, give applications some rich and dynamic capabilities such as:

• XForms can take advantage of the strong data typing offered by XML Schemas to validate user input at the client without using any scripting. More sophisticated data validation is also possible, such as enforcing relationships between different form values.
• XForms' user interface components are device-independent, meaning they are rendered according to whatever device they are being displayed on.
• XForms create and consume XML, rather than name/value pairs, making them the ideal client for Web services.

To show how some of these capabilities can be used, this article walks through the development of a simple XForms application that uses an Amazon Web service to query and display a typical book search.

Setting Up for XForms
To take advantage of the power of XForms, we first of all need something over and above the simple HTML forms processing model - an XForms engine. XForms engines are programs that are usually installed on the client side, for example as browser plug-ins, and typically work in the following way:

• A request is made for a host document containing XForms markup by, for example, opening a document on a file system or issuing an HTTP GET.
• The XForms engine reads the markup and renders the form. Because XForms' user interface components are defined in an abstract way, the same XForms will be rendered in a way that is appropriate to the client device. Therefore, while a date input field might be rendered as a calendar picker on a desktop browser, on a more constrained device such as a PDA, the same input field may be rendered as a single-line text box.
• Once the form has been rendered, the users work with it to accomplish what they need to. As they are doing this, events will be fired to, amongst other things, enforce data validation rules, conditionally display different user interface components, or perform calculations. (XForms calculations and field updates are performed using the same depth-first search and topological sorting as spreadsheets.)
• When the user has completed the form, he or she clicks a button to submit it. The XForms engine will then create an XML instance document and deal with this payload according to the rules defined by the form. The target of a submission is always a URI, which may mean that the XML payload is written to a file, sent to an e-mail address, submitted to a Web service, or to any other HTTP or HTTPS endpoint.

The advantage of having the XForms engine on the client is that all processing happens in one place and unnecessary traffic with the server is avoided. However, until XForms implementations become more common, developers can't always assume that their clients will have the right installation. Alternatively, server-side XForms engines can deliver equivalent XForms functionality to plain clients, usually through a combination of scripting and the normal markup of the host language. This means that clients don't need their own XForms engine, but the markup delivered to the client may be bulky and may not support the full range of XForms features.

For the examples used in this article, I'll be using a client-side XForms engine called FormsPlayer (www.formsplayer.com/content/index.html). Sidebar 1 has more details about some of the XForms engines that are available today.

XForms Basics
XForms are not intended to be stand-alone XML documents, but rather are embedded in what is known as a host "language." Often, this host language will be XHTML, but it might also be Wireless Markup Language (WML) or Scalable Vector Graphics (SVG), among others. Within their host languages, XForms closely follow the Model View Controller (MVC) pattern, which means there is a clean separation of data, presentation, and logic.

The XForms equivalent of the MVC model is, appropriately enough, the model element. An XForms model is really a template for the XML payload that will eventually be created, and it has a dual role in loading the model with any initial data. Listing 1, a basic Hello World XForms, shows a simple model inside the head of an XHTML document. Models are typically placed in the head to emphasize the fact that they are a non-rendered component. Any well-formed XML document can be placed within the model's instance sub-element, or it can contain a pointer to an external instance document Figure 1).

One of the key advantages XForms have over HTML forms is the ability to perform data validation, constraint checking, and calculations without the need for client-side scripting. XForms allows this to be done in a number of ways.

• An XML Schema can be associated with the instance data elements. For small models, these constraints and validations can also be specified inline rather than referring to a separate XML Schema.
• The bind element can be used to establish a data binding between user interface controls and elements in the instance document and at the same time specify a data type for the instance element. The bind element also contains any calculations or restrictions (as XPath expressions) that need to be applied.

The last part of the XForms model is the submission element, which uses a URI to describe what should be done with the XML payload once it has been populated. In our Hello World example, the XML payload is simply written out to a named file when the user clicks on the Write to Disk button.

Once the model is defined, all or part of it is exposed through user interface components. Following the MVC pattern, XForms user interface components provide a view onto the model, with the two being linked by either XPath expressions as in Listing 1, or through a bind element. Whereas HTML defines explicit user interface components such as radio buttons and check boxes, XForms defines a set of abstract components. These abstract components say what a component should do, but the actual rendering will depend on the host language and the device on which the components will be displayed.

While the XForms engine takes care of most of the rendering of the XForms user interface, developers can still have a style influence in a couple of ways. XForms can be directly styled according to the features available in the host language, so when using XHTML, this might mean using tables, headings, and other XHTML tags, with the XForms components arranged within these. However, by hard coding the styling details in this way, the device-independence of the form is limited.

The alternative styling approach is to use only the minimum host-language structure necessary to accommodate the XForms markup. Again, when using XHTML, this would mean placing the XForms model in the head section and the abstract user interface definition and bindings in the body section. An external stylesheet, such as Listing 2, would then provide the colors, fonts, and other formatting for each particular device.

The final part of the MVC pattern, the controller, equates to XForms events and actions. Events in XForms are defined by the XML Events specification, which in turn provides an element-based interface to the Document Object Model (DOM) Level 2 event syntax (see the Resources for more details). Meanwhile, XForms actions are the handlers that respond to XForms events. This means that XForms follow the well-known Gang of Four Observer pattern in which observers are attached to particular elements, which are notified when nominated events occurs, and then certain actions are performed.

Page 1 of 2   next page »