XForms, three ways

HTML’s ongoing affair with XML is producing another love child: XForms.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

Introductory metaphors notwithstanding, XForms is an entirely legitimate offspring because it achieves two worthwhile purposes: It further elevates the position of XML as the medium of exchange for Web site data, and it eliminates a number of weaknesses in standard HTML forms. (That’s a polite way of saying that the premier goal of XForms is to replace HTML forms.)

XForms and Function

For those unfamiliar with HTML forms, a form is a part of a Web page — an input field, a text box, a radio button — that includes an input control. XForms, meanwhile, is built on an MVC (Model-View-Controller) architecture. The structural details of the data manipulated by a Web form are purposely separated from the form’s visual details. Thus, XForms code that describes the data to be input and output is not entangled with the code that displays that data — a common problem with HTML forms.

Indeed, XForms takes things a step further, leaving the visual details of the display entirely up to the user interface. For example, in HTML forms the multiple options presented by a <select> tag are rendered as a menu. In XForms, the programmer can render those options in other ways. In other words, the display portion of an XForms form describes the intent of the form’s controls, not their appearance.

All this factoring makes XForms easier to work with than HTML forms. For example, a change in the structure of the data requires less alteration of the display code. In addition, data is exchanged between Web form and server using XML. And XForms can call upon its cousins XSL and XPath for input format and type validation (for example, making sure that a quantity input field contains a positive integer), as well as for calculations and special formatting.

Consequently, much of a form’s business logic that must now be done by scripting can instead be done by XForms. The result is cleaner, and easier to read as well as maintain.

Implementing XForms in a browser (its typical but not necessarily only home) can take one of two routes. A server-side implementation performs all the heavy lifting on the server, rendering the entire user experience in HTML. It places minimal requirements on the browser but results in unnecessary data trips between client and server as the server manages tasks such as intermediate calculations during data entry. This disadvantage is absent in a client-side implementation, but placing all XForms processing on the client requires some sort of browser plug-in or client-side run time.

I examined three software products that feature XForms to varying degrees. Each product fits into the server-side or the client-side implementation model. DENG is different from the others, however; it’s a modular XML brow-ser and a free add-on that works with most popular browsers and implements (among other things) an XForms engine.

The Orbeon Integration Suite, comprised of PresentationServer 2.7 and Orbeon Studio 1.2 , is an open source presentation server and Eclipse-based IDE for developing XML-based data management applications (applications whose run-time user interface is specified in XForms). Finally, the PureEdge 8x Suite is a collection of tools for e-forms creation, distribution, and management. Like Orbeon’s PresentationServer and Studio, PureEdge uses XForms to create an e-form’s user interface.

Of course, in an XForms proponent’s ideal world, all browsers would include XForms engines as standard equipment. There are other options out there (see infoworld.com/2556), but this ideal has yet to become a reality. In the meantime, XForms offerings from DENG, Orbeon, and PureEdge give us all a glimpse of where this progressive and versatile technology is headed.