XForms: an Alternative to Ajax?

A Year of Ajax-Based XForms

Until early 2005, there was no sign of Ajax-enabled XForms engines, whether actually using the newly-coined term “Ajax” [GAR05] or not. But in May 2005, Orbeon presented the concept of Ajax-enabled server-side XForms at XTech [BRU05], along with the first demos of the new open source Orbeon PresentationServer (OPS) [ORBEON] XForms engine. In late 2005, the open source Chiba [CHIBA] project announced upcoming Ajax support, with a beta available later in December. Finally, in January 2006, OPS 3.0 final was released with comprehensive Ajax-based XForms support.

In short, while 2005 has been the year of Ajax, it has also been the year of the realization that XForms hugely benefits from being implemented using Ajax.

Recently, articles and blog entries by various independent writers have appeared on the web, noting how XForms and Ajax can “get along” [SEE06], how XForms can be seen an “alternative to Ajax” [AVK06], how “XForms matters” even more in light of the latest Ajax developments [CAG06], or how XForms and Ajax “do not compete” [BAR05]. The idea appears to have caught on.

Benefits of Ajax-Based XForms

Practically, the web cannot be dissociated from web browsers, and since XForms was designed as the next generation of "web forms", it is absolutely crucial to bring XForms to web browsers.

With Ajax, XForms finally reaches the web at large and fulfils its initial promise, since deployment does not require any client-side plugins, browser upgrades, or separate client software installs: any modern web browser serves as an XForms client out of the box. This includes Internet Explorer, which is very unlikely to implement XForms in the short term.

Because deployment targets now pervasive Ajax-enabled clients, most web sites and applications can use XForms as an authoring language. In particular, this opens the door for insurances, healthcare organizations, and governments to benefits from authoring applications with XForms while effectively reaching most of the web population.

Clearly, XForms deployment is the number one issue solved by Ajax, but there are additional benefits compared to browser plugins and native implementations, including:

• Improved security. XForms engine state can be kept entirely on the server. End users do not have access to the XForms engine internals. The details of secondary XForms instances and calculations, for example, can remain hidden from the user.

• Ease of upgrade. Bug-fixes, new widgets, and extensions are deployed to all clients simply by upgrading one server-side component.

• Performance optimizations. Very large XForms instances can be kept on the server instead of having to be sent to the client, therefore improving page startup time and latency.

• Shorter time to market and easier maintenance. The bulk of the XForms implementation is implemented with higher-productivity server-side programming languages such as Java and a wealth of existing libraries, instead of native C/C++ or Javascript.

Because of these benefits, we believe that Ajax-based XForms can in fact be a preferred XForms deployment solution over any other, even in the unlikely event that all web browsers end up implementing XForms natively.

Essentials of Ajax-Based XForms

An Ajax-based XForms implementation distributes its functionality between the client (web browser) and the server using Ajax technology. Like most Ajax applications, it:

• Uses the client's (X)HTML, CSS and Javascript capabilities.

• Communicates with server-side code using an XML protocol.

• Dynamically updates the (X)HTML page's using Javascript and DOM.

The exact balance between client-side code and server-side code varies between implementations. Orbeon PresentationServer for example chooses to keep the XForms engine proper as server-side Java code and uses a comparatively simple client written in Javascript.

With such an architecture, client-side tasks include:

• Reacting to mouse clicks and text input.

• Scheduling and sending appropriate update messages to the server.

• Interpreting server responses.

• Updating the (X)HTML DOM based on these responses.

• Providing widgets that are not native to (X)HTML, such as a slider or a calendar-based date selection widget.

Server-side tasks include:

• Generating the initial (X)HTML page by translating (X)HTML+XForms into (X)HTML+Javascript. This also includes loading external XForms instances and schemas.

• Receiving events from the client through Ajax.

• Keeping or restoring XForms engine state for the page being acted upon.

• Performing XForms engine tasks such as evaluating model item properties, dispatching events, running XML Schema validation, performing XForms submissions, etc.

• Sending back to the client the information needed to update the DOM.

Figure 1 illustrates the architecture of an Ajax-based XForms engine and its position between a server-side XForms-based application and a client web browser.

Figure 1: Architecture of an Ajax-Based XForms Engine

There is no limitation as to what software produces XForms pages on the server: any dynamic server-side platform, including Java, .NET, scripting languages, or even static files, can be used.

Sending page update information to the web browser can require advanced strategies. For example, Orbeon PresentationServer uses a difference algorithm to compute the smallest set of updates to send to the client as the result of an Ajax request.

Ajax Libraries and Widgets

An Ajax-based XForms implementation does not need to reinvent the wheel when it comes to Ajax functionality: it can leverage existing Ajax frameworks and can even combine several of them, without impacting the XForms code written by the application developer.

Libraries are particularly important as the number of available user interface widgets increases. Figure 2 shows an example of slider widget that can be used by an XForms implementation to present an xforms:range control to the user:

Figure 2: Slider Widget

XForms follows an intent-driven philosophy when it comes to user interface controls. This means in particular that XForms does not mandate the exact appearance of a control, but mandates a certain type of functionality instead, such as "a control that allows picking a particular value from a list of values".

As another example, a text input control can be presented as a regular HTML input field, or as an in-place editing widget:

Figure 3: In-Place Editing Widget

Whether the input field is presented as an in-place editing widget does not change the interface the application developer uses, including event capture:

<xforms:input ref="my-data">
  <xforms:label>Please enter your data</xforms:label>
  <xforms:send ev:event="xforms-value-changed"
               submission="save"/>
</xforms:input>

This gives XForms implementers freedom to pick appropriate widgets, while optionally exposing the choice of the widget to the application developer through an appearance attribute, present on all XForms control elements. This also allows implementations to easily fallback to existing widgets when more advanced or non-standard appearances are not available, therefore still allowing an application to function properly.

When widgets do not nicely map to existing XForms controls, a further step consists in extending XForms with new controls, or new attributes and elements on existing XForms controls. With such extensions, XForms implementations can expose as many widgets as they see fit, and present to the application developer a unified, markup-based interface to a very large collection of widgets.

Implementation Challenges

Implementing an Ajax-enabled XForms engine raises some challenges. It is important to mention that the XForms engine addresses those challenges, shielding XForms authors from having to deal with them:

• Latency. The XForms processing model requires a possibly very large number of events to be processed. With an XForms implementation that resides mostly on the server, this can translate into many requests sent to the server. An Ajax-based XForms engine should try to minimize the number of such requests, and minimize the size of those requests as well. The effect of latency can also be mitigated by using a loading indicator, preferably handled automatically by the XForms implementation.

• DOM updates. Complex client-side DOM updates need to be performed. For example, the xforms:repeat feature requires repeating possibly nested sections of a page based on an (X)HTML template. This can be implemented entirely with Javascript and DOM, but a hint that this task is not easy is that Web Forms 2.0 [WEBFORMS20] provides utilities to facilitate repetition in (X)HTML.

• Javascript. Client-side Javascript rapidly becomes hard to maintain, even with a relatively lightweight XForms client. But contrary to most Ajax applications, XForms hides this aspect entirely from the application developer: only XForms engine implementers have to struggle with this issue.

• State keeping. An XForms engine needs to keep a large and complex internal state. Strategies to keep state on the client and/or on the server have to be devised. Each strategy has benefits and drawbacks, as discussed briefly in [BRU05].

• Usability. As is the case with all Ajax applications, it is important to ensure that the application reacts in a way as compatible as possible with regular web browsing habits. For example, the browser's back button should restore page state as expected by the user. Orbeon PresentationServer, for example, handles the browser's back button to an XForms page by restoring the page to its latest state by using a difference algorithm.

• Graceful degradation. An Ajax-based XForms engine can degrade gracefully by switching to a pure server-side mode for non-Ajax enabled clients. This however means that some interactive aspects of XForms, such as incremental data updates, real-time validation, Javascript-based widgets, etc. are not performed. Graceful degradation, while possible and greatly facilitated by the XForms programming model (including intent-based controls), still requires attention from the developer.

• Ajax libraries and widgets. Appropriate Ajax libraries must be chosen. Given that consolidation has not yet occurred in the Ajax world, the optimal choice may change rapidly over time. In addition, widget libraries are numerous and do not yet agree to a common interface. This is again an issue for XForms engine implementers rather than XForms application authors.

Semantic Ajax

There is no universal agreement that declarative approaches are always better than imperative approaches. It is important however to recognize the differences between the two approaches, and the benefits and drawbacks of each one.

XForms mostly falls into the declarative category, with arguably one exception, the sequencing of actions. On the other hand, most Ajax frameworks are decidedly imperative, since they use Javascript as their main programming language.

Regardless of the approach, the crux of the issue is to recognize that both Javascript-based Ajax libraries and XForms have identified common patterns that are constantly reused by developers, and formalize access to those patterns either through APIs or standard markup.

For example, it is common to update a dropdown menu with items dynamically. XForms translates this update scenario into the creation of the xforms:itemset element, which allows a menu to point to items stored in an XML document. Similarly, the xforms:submission element allows performing complex XML submissions simply by configuring it with a few attributes. Such formalizations introduce meaningful abstractions, or semantics, to Ajax.

We show in the next few sections that many of the constructs of XForms address use cases also tackled by traditional Ajax frameworks. Note that we sometimes use the term "Ajax" freely, in that not all the examples presented necessarily require exchanging data with the server through XmlHttpRequest. However, they all perform DOM updates, and are very likely to actually use XmlHttpRequest when implemented by an XForms engine.

Repeating Table Rows

Web application often require presenting and editing several rows of fairly homogeneous data. For example, a task list presents one row per task, each with a description of the task; a motor vehicle administration form presents one row per vehicle:

Figure 4: Repeated Table Rows

XForms solves this problem using the xforms:repeat construct:

<tr xforms:repeat-nodeset="dmv:vehicle">
  <td>
    <xforms:input ref="dmv:plate-number">
      <xforms:label>California Plate...</xforms:label>
    </xforms:input>
  </td>
  <td>
    <xforms:input ref="dmv:vin" class="dmv-vin">
      <xforms:label>Vehicle Id...</xforms:label>
    </xforms:input>
  </td>
  <td align="center">
    <xforms:select ref="dmv:leased" appearance="full">
      <xforms:label>Check...</xforms:label>
      <xforms:item>
        <xforms:label></xforms:label>
        <xforms:value>Y</xforms:value>
      </xforms:item>
    </xforms:select>
  </td>
</tr>

The repetition operates over a bit of XML data stored into the (X)HTML page, for example:

<vehicles>
  <vehicle>
    <plate-number>1CCD412</plate-number>
    <vin>53585987654321031</vin>
    <leased>Y</leased>
  </vehicle>
  <vehicle>
    <plate-number>3TRE787</plate-number>
    <vin>14393483498123400</vin>
    <leased></leased>
  </vehicle>
  <vehicle>
    <plate-number>6QWA76</plate-number>
    <vin>34756976067146047</vin>
    <leased>Y</leased>
  </vehicle>
</vehicles>

Row insertions and deletions are performed by declaratively hooking up an xforms:trigger control (in other words a button the user can activate) and an XForms action through the use of an event:

<xforms:action ev:event="DOMActivate">
  <xforms:insert nodeset="//dmv:vehicle" at="index('vehicles-repeat')" position="after"/>
</xforms:action>
<xforms:trigger>
  <xforms:label>Add Vehicle</xforms:label>
</xforms:trigger>

Tabbed View

Tabbed views are common in desktop applications, and becoming more and more common in web applications because Ajax allows switching between tabs without reloading the page entirely.

Figure 5: Tabbed View

Creating a tabbed view involves the following aspects:

• Displaying the tabs with the appropriate layout and style.

• Reacting to user activation of an individual tab.

• Switching the view to the newly selected tab.

XForms features the individual components to implement a tabbed view:

• The trigger (or button) control reacts to user activation.

• The xforms:switch construct allows showing and hiding different sections of the page.

The layout and style is done with plain (X)HTML, using <div> or <table> elements. The switches are implemented as follows:

<xforms:switch>
  <xforms:case id="text-tab">
    [Content of the "Text Controls" tab]
  </xforms:case>
  <xforms:case id="selection-tab">
    [Content of the "Selection Controls" tab]
  </xforms:case>
</xforms:switch>

Switching between tabs is done by calling the xforms:toggle action upon receiving the appropriate event from the button:

<xforms:trigger>
  <xforms:label>Selection controls</xforms:label>
  <xforms:toggle ev:event="DOMActivate"
                 case="selection-tab"/>
</xforms:trigger>

Some XForms implementations expose tabbed views as configurable components that do not require developers to even use xforms:switch and xforms:trigger explicitly.

Note that so-called "wizards", which take the user through multiple steps of information gathering, as well as "hide/show" buttons that hide or show a particular section of a page, function on a model very similar to tabbed views.

“Google Suggests”

"Google Suggests" was one of the first high-profile Ajax-based example:

Figure 6: Original Google Suggests

To implement such a feature without the help of XForms, you need to:

• Find or write a textfield-with-dropdown widget.

• Write Javascript code that captures user events, sends them to a server-side service through XmlHttpRequest or an abstraction of it, receives an answer back (in XML or Javascript), and updates the dropdown list.

XForms already features a selection control that allows the user to select a single value from a set of values, typically rendered with a dropdown or radio buttons. In addition, you can parametrize the XForms selection control to allow for open selection, where the user can, in addition, enter her own value. An XForms implementation can choose to represent this control as a widget that looks exactly like Google's (this is the case of Orbeon PresentationServer thanks to an xxforms:autocomplete appearance). This standard XForms control also supports an incremental mode, where XForms sends event as the user types. This is how the control is hooked up:

<xforms:select1 ref="instance('suggest-query')"
                selection="open" incremental="true"
                appearance="xxforms:autocomplete">
</xforms:select1>

As the user types, events are captured and cause an XForms submission to be called:

<xforms:send submission="suggest" ev:event="xforms-value-changed"/>

The xforms:submission construct declaratively specifies what XML data to send, to what location, using what HTTP method, and what to do with the returned data. Here, we call a simple server-side suggestion service that returns suggestion data already formatted in XML:

<xforms:submission id="suggest" method="post"
  action="/suggest" ref="instance('suggest-query')"
  replace="instance" instance="suggestions" />

The suggestions automatically update the dropdown list with the xforms:itemset construct:

<xforms:itemset nodeset="instance('suggestions')/suggestion">
  <xforms:label ref="."/>
    <xforms:value ref="."/>
</xforms:itemset>

Finally, when the user activates the selection field (for example with the "enter" key), a second submission is called to take the user to the Google search page:

<xforms:send submission="google-search"
             ev:event="DOMActivate"/>

This time, the submission uses the HTTP get method, and directly returns the Google page to the user:

<xforms:submission id="google-search" method="get"
  action="http://www.google.com/search"
  separator="&amp;" ref="instance('google-query')" replace="all"/>

The final result looks like this:

Figure 7: XForms-Based Google Suggests

Validation As You Type

Form data validation typically has two facets on the web: one server-side based, almost always present, and one client-side based, optional and usually written in Javascript.

The main reason to introduce client-side validation is obvious: you want to be able to notify the user as early as possible of errors in his form. Without Ajax, submitting the form to the server in order to validate it requires reloading the entire page and introduces latency. Ajax allows you to send data for validation to the server in the background, and to display relevant errors to the user.

Figure 8: Presenting Validation Errors to the User

With XForms, validation automatically occurs regularly, when a data value has changed, or when a special "revalidate" action is performed. In short, the expectation is that validation will usually be close to real-time. You can validate in several ways:

• Simple or complex XML Schema types constraints. These include built-in types like xs:integer, xs:date, etc., as well as types defined by the user in an XML Schema.

• XPath constraints. These can use any boolean XPath expression, such as string-length() > 10.

• Required fields. Fields that are required but empty are specially marked and styled.

Telling XForms to validate a data field is as simple as creating an xforms:bind element, pointing it to the right data, and specifying what type of constraint you want:

<xforms:bind nodeset="name" constraint="starts-with(., 'A')"/>

You can also import an XML Schema. In this case, you have added benefits: not only can schema validation work within the XForms engine, but the same XML schema is reused by a service that processes the submitted form data.

Button-Less Form

The "Submit" button has long been a must in web forms. But since Ajax allows you to submit form data in the background, you can send form data to a server as the user interacts with the user interface. This is very useful in the following example of real-time translation:

Figure 9: Button-Less Form

As the user types in the text area, the text is sent to a service which performs the translation and returns the translated data. The page then displays the resulting translated text.

With XForms, reacting to user keystrokes in this scenario requires using the incremental="true" attribute, which causes events called xforms-value-changed to be sent as the user is typing. An action then submits the data to the server:

<xforms:textarea incremental="true">
  <xforms:label>Translate text:</xforms:label>
  <xforms:send submission="default-submission"
               ev:event="xforms-value-changed"/>
</xforms:textarea>

The response from the server containing the translation is directly referred to by the XForms output control:

<xforms:output ref="instance('response-instance')/target">
  <xforms:label>Translation:</xforms:label>
</xforms:output>

With this declarative syntax, the developer does not have to write any code to set the output value upon receiving the translated text from the server.

Mashups and Querying Services

"Mashups", or "website or web application[s] that seamlessly combine content from more than one source into an integrated experience" (Wikipedia), have been greatly facilitated by Ajax technology. One crucial aspect of mashups is the ability to retrieve content from multiple data sources, often on the web.

XForms provides a facility to query data and services over HTTP and HTTPS while the user interacts with the application: the xforms:submission construct. XForms submissions in particular allow sending data as parameters on a URL using the GET protocol, or sending XML using the POST or PUT protocols, and handling returned XML data. XForms 1.1, currently in the works, also introduces SOAP support.

An XForms submission is therefore a tool appropriate for calling web services, whether lightweight REST-based or SOAP-based. With XForms actions and calculations, combining the data received is possible.

In this section, we explore a simple example (initially proposed in [BIR06]) that queries a single source of data using the Flickr API. This API expects here a URI of the form:

http://www.flickr.com/services/rest/
  ?method=flickr.photos.search
  &api_key=[key]
  &tags=mountains
  &per_page=12

XForms allows you to submit an XML document as URL parameters by configuring the xforms:submission element as follows:

<xforms:submission id="sub-flickr" method="get"
  action="http://www.flickr.com/services/rest/"
  separator="&amp;" replace="instance" instance="inst-rs">

And pointing to an XML document of the following form:

<instanceData>
    <method>flickr.photos.search</method>
    <api_key>[key]</api_key>
    <tags>mountains</tags>
    <per_page>12</per_page>
</instanceData>

Flickr responds with an XML document as follows:

<rsp stat="ok">
  <photos page="1" pages="13484" ...>
    <photo id="109199721" owner="..." .../>
    ...
  </photos>
</rsp>

With XForms, displaying the resulting images is then just a matter of using the xforms:repeat over the photo elements:

<xforms:repeat nodeset="photos/photo">

The final result is nicely presented:

Figure 10: Searching Flickr With XForms

Server-Side Calculations

Javascript has many facilities to perform arithmetic calculations. There are times however where complex calculations should be delegated to the server for performance, complexity, or confidentiality reasons. XForms allows doing all this by calling a calculation service using xforms:submission or by using XForms' built-in calculate property:

<xforms:bind nodeset="section02/line04"
    calculate="/f1040ez/section02/line01
             + /f1040ez/section02/line02
             + /f1040ez/section02/line03"/>

Figure 11 shows an example of a simple tax forms that can perform such server-side calculations with XForms:

Figure 11: Tax Form With Calculations