10.5 Making the Switch to XForms

From a technology perspective, XForms makes a clean break with HTML forms. The reality, though, is that, as of 2002, nearly every Web site is using HTML forms or, more precisely, is expecting visiting browsers to be equipped to handle HTML forms and JavaScript. Given the slow rate at which new technologies reach average users, it will likely be several years before Web designers can safely rely on XForms being present as a standard feature of visiting browsers. This section contains some pointers on how to make a smooth transition to XForms technology.

10.5.1 Client-Side and Server-Side XForms

HTML forms were defined such that the only reasonable way to implement the technology was in a client-side browser. XForms, on the other hand, defines things such as validation rules and declarative actions, which can be processed on either a client or a server. This gives a lot of flexibility in the architecture of an XForms engine and, in many cases, allows XForms to be layered on top of existing browser technologies.

One common strategy for XForms engines is to divide processing between the client and server. The dividing line between client and server can be in several different places:

10.5.2 The Featherweight Client

The client side requires almost no intelligence, serving only as a viewer application, while the server handles all of the logic and processing. Frequent server round trips are needed in order to coordinate the display with the internal state of the engine. The open source Chiba project (http://chiba.sourceforge.net) falls into this category.

10.5.3 The Scriptable Client

The client side includes a scripting engine or some limited ability to do local processing, which can perform some of the logic and calculations. Only the most sophisticated operations require a server round trip, improving the user experience.

10.5.4 The Modern Browser Client

The server "compiles" the form definition into a dense bundle of HTML, CSS, and JavaScript that existing browsers will render in a way scarcely distinguishable from a native XForms engine. If the target browser has XML capabilities, the resulting XML can be directly submitted. Otherwise, the server needs to reinterpret a conventional form submission as XML. The IBM XML Forms Package (http://www.alphaworks.ibm.com/tech/xmlforms) includes a server-side compiler that falls into this category.

One major benefit of XForms split architectures is that they are readily adaptable to various supported languages in the client, including HTML, SVG, and VoiceML, among other possibilities. In particular, HTML translation is a popular option for supporting XForms in existing clients.

10.5.5 Client-Side Options

Another way to work with XForms today is to take advantage of the plug-in architecture of modern browsers. Two of the most popular options are the DENG engine (http://mozquito.markuplanguage.net), which works with any Flash 6 enabled browser, and FormsPlayer (http://www.formsplayer.com), which turns the most popular browser, IE6 for Windows, into a full-fledged XForms engine.