Understanding XForms: Components

I know, I know … when you talk about a series, it usually implies that the articles will be somewhat closer together than the ones for my Understanding XForms series has been. Mea culpa. The last couple of months have been busy, but a desire to wrap up my Firefox book (another mea culpa, if it comes to that) has combined with being fairly deeply immersed in the vagaries of XForms on Firefox to prompt me to write the third installment in this series. Take a look at the links at the end of the article for the previous installments. Please note in all of these that the assumption being made that the examples given here, if run in Mozilla Firefox, need the Xforms extension available at http://www.mozilla.org/projects/xforms/download.html. However, the examples should (in general) run in most contemporary XForms enabled browsers (a topic I’ll be discussing a couple of columns from now).

The Joy of XForms Components

Big complex data models look really imposing and impressive, but at the end of the day, XForms got their start largely because the existing HTML forms just weren’t expressive enough. Consider some of the more vexing problems associated with typical web forms. Suppose that you wished to:

• choose a value from a given numeric range, rather than from a drop-down list?
• create an invoice where you needed to add items to an invoice list?
• enter a date in a consistent numerical format?
• allow data into a text field that corresponded to a given regular expression pattern?
• create tabbed panes of content?
• create a wizard for gathering information?

All of these things can, of course, be done with the careful application of JavaScript, server side code, and perhaps third party plugins. The problem though is that most of these things are also fairly common operations in more traditional stand-alone applications, which has often spelled real trouble when such applications were then ported from the web. Moreover, there are no consistent standards from such solutions that seem to work universally on the web, especially from the standpoint of being able to tie such components into the bigger framework of web pages and CSS.

Thus, as the XForms working group within the W3C tried to grapple with making web components more application like, they also began to see the need to define more sophisticated structures for handling the use cases that arose in any number of business applications.

Consequently, one of the first things that came out of the working group was the realization that a component standard should be more concerned with interface requirements than it should be with presentation. In other words, XForms components needed to be abstract.

This notion is of course hardly foreign to HTML, but it is one that tends to be foreign to a lot of people who work regularly with web forms. The first pass of Web forms defined the notion of the field, with an associated type attribute that would determine whether it was an text box, a check box, a radio button, in short, everything that didn’t involve selecting from a list or dealing with multiline content.

There are several things wrong with this approach, things that only became obvious in retrospect. First of all, there are significant qualitative differences between a box of text and a checkbox - one can take potentially any string, the other can only hold one of four well defined state values (selected, unselected, disabled and indeterminate). This meant that the same statement needed to essentially be treated as perhaps half a dozen distinct elements, each with its own attributes, events properties and methods. This in turn made validation considerably more difficult, and became really hairy in the case of such things as radio buttons, which generally have no semantic meaning outside of groups).

Moreover, such components are fundamentally dumb. You can use script to handle manipulation of content, but its remarkable just how ugly such computations can be for even the simplest of operations. For instance,consider the following form fragment:

+

+

Not only do you have the fairly complex bit of manipulation when the “=” button is pressed just to add two numbers, but you are outputting to an input box, which means that a user could go in and change this field. Moreover, the “=” button has a largely spurious value - if this form was submitted this information would go with it even though it makes no different to the model.

Now compare this to the XForm way of doing things:

+ =

In this particular case, you are trading the complexity of DOM manipulation in Javascript for the complexity of creating a data model. Once that model is defined, however, you suddenly have components that are aware of one another through the data model - if you change the value in either field a or field b, not only does it change the data model, but that change then gets propagated back to a new element - the

element, which can perform calculations upon the model itself. This may seem overkill here, but the value proves itself once you start getting into more complex situations (which I’ll cover in a bit).

The element is one of those which, once you start using it, you begin to wonder why it never ended up in the initial HTML set. It is a non-editable component that can either reflect the value of a given item in the data-model (via the ref attribute), or can reflect the result of a calculation (using XPath notation) via the value attribute.

Both the and

methods can also be associated with a binding based on an element. For instance, in the above example, you could create a binding that performs the calculation and associates the result with another data member:

+ =

The output object (generally) only displays text content, though I’ll show some examples in the next column (customizing XForms) to demonstrate how to display other things, making the component considerably more useful.

One thing that you may notice if you are following along in this demonstration - when you type an entry into one of the input fields, nothing happens until you change the focus (by tabbing out or clicking outside of the control). This feature is built into XForms in order to insure that the proper processing can be handled in lower-capability devices. You can, however, change this behavior by including the attribute incremental=”true” on the input control in question. Once this happens, the component will force an update automatically whenever a change occurs. This becomes even more important when dealing with styling and customization issues.

One of the more frustrating elements missing from the set of core HTML tools is a simple slider, that lets you select between a range of numeric values. The component does precisely that. By specifying the start, end and an optional step value, you can create a slider that will let you select either a discrete or continuous value from that range (depending upon step). For instance, the following XHTML document uses two sliders to create a coordinate value (x,y) where both x and y can be expressed in 0.05 step intervals: