XForms, three ways

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

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.

DENG 1.0

The DENG (Desktop ENGine) project is a free XML browser that runs in Mozilla, Internet Explorer, Opera, and Safari. Built and supported by Claus Wahlers and Stefano Debenedetti, it began life under the lead of Mozquito, a German company that initiated the formation of the XForms working group. Although Mozquito no longer exists, DENG continues to be supported at http://claus.packts.net.

I tested DENG Version 1.0, the current release as of this writing. DENG’s creators are at work on Version 2, which is expected to be part of a larger XML browser framework code-named UGO (see “DENG joins a new project: Say hello to UGO”). Although I concentrated on its XForms support, DENG also implements features such as XFrames, SVG, XHTML, and more.

DENG is a marvelously clever client-side implementation of XForms — clever because it’s crafted largely in Flash, with a touch of ECMAScript (the European Computer Manufacturers Association’s standardization of JavaScript). This means virtually any browser that supports Flash Player 6 (or better) can run DENG.

The DENG installation is simple and quick, amounting to unpacking a .zip that includes the Flash ActionScript files. There’s not much documentation because DENG implements technologies exhaustively detailed at the W3C’s site. DENG’s Web site includes a number of samples you can use to test your installation.

Working with DENG is extremely intuitive. You just install it; that’s it. Its capability — from the perspective of this review — is singular: It implements XForms and handles the XForms processing. Apart from the XHTML that encapsulates the XForms, no data is passed between client and server.

Unfortunately, DENG 1.0’s XForms support is incomplete. It doesn’t support schema validation, nor are the range and select forms controls implemented. The lack of these controls is a pretty serious deficit, but it does not detract from my overall favorable impression of DENG. Furthermore, Wahlers claims that the next release of DENG will be 100 percent XForms 1.0 compliant. Based on what I’ve seen, I’m confident it will be.

Orbeon PresentationServer 2.7

Orbeon’s PresentationServer is a Java framework that runs on a variety of J2EE servers to create a platform for executing XML-based Web applications. Because it runs on a J2EE server, it also provides user authentication and session management, and it integrates with Web services.

Formerly known as OXF Server, PresentationServer was released as open source last August under the LGPL (Lesser General Public License). I ran the server on Tomcat 5.0.25, though it also runs on Tomcat 4.1.30, BEA WebLogic Server 8.1, and IBM WebSphere 5.1. To install it, you simply unpack a WAR (Web Application Archive) file into your application server’s deployment directory.

PresentationServer sees an application as a collection of pages. You craft these pages using XHTML, XSLT (XSL Transformation), and XForms. PresentationServer relies on XForms to handle all user input. As such, XForms plays a partial role in the overall scheme of PresentationServer.

PresentationServer is built along classic MVC architecture lines: The PresentationServer is the controller, which is guided by the Page Flow file. This file is a special XML file that manages the transitions from one page to another. Within it you specify the model information (the data source) as well as the file that contains the XHTML for the view.

The Page Flow file also governs the passing of data from one page to the next. In XForms parlance, data associated with any form on a particular page is referred to as instance data. Commands in the Page Flow file process the instance data going into and coming from each page, and it routes the data to its proper destination.

All this data movement is encapsulated in XML, of course, and as it moves from point to point, data often needs to be processed (transformed, merged, and so on). To do this processing, Orbeon uses the concept of an “XML pipeline,” a series of computational and XML-manipulating elements (called XML processors) hooked into a chain, with the output of one feeding the input of the next.

The pipeline format makes it easy to visualize how to assemble a collection of XML processors. With this setup, XForms instance data passing out of one page can be sent through an XML pipeline on its way to the next page, perhaps to be reformatted or combined with data read from a database, to name just two of many options.

PresentationServer comes with a host of standard processors. There are processors for transforming XML, for reading and writing XML to files, for querying SQL and XML databases, and more. If you need a custom processor, you can write your own in Java and incorporate it into PresentationServer. The ability to write a custom XML processor is not so much unique as powerful: You can create customized document transformation and filtering code and use it within the Orbeon framework.

PresentationServer is a stunning display of XML-variant vocabularies employed both declaratively (to specify schemas and page layouts, for example) and imperatively (to create business logic). Be warned, however, that you will have to learn a dizzying array of XML-based dialects to use these products: XQuery to query databases; XSLT to specify style sheets; XForms to handle user input; XSD (XML Schema Definition) to describe schemas; XPL to build pipelines; and on and on.

Maybe this is easier than coding the application in Java or .Net, but I occasionally wondered if I was just trading one species of complexity for another.

PureEdge 8x Suite 2.6

PureEdge's goal is to replace all those paper forms that you have to deal with -- even a 1040 tax form from the IRS -- with electronic equivalents. It doesn’t hit that mark dead-on, but after putting it through its paces, I’d say that it does come close.

PureEdge 8x is a suite of products for creating and manipulating XML-based documents known as PureXML e-forms. The suite consists of the Designer, Viewer, Server, and Web Server modules. PureEdge e-forms are the digital equivalent of paper forms: securable, writeable, and executable documents stored using the XFDL (Extensible Forms Definition Language) dialect of XML. (XFDL was accepted as a note by the W3C several years ago.)

PureEdge uses XFDL as the host language for XForms in much the same way that a Web page displayed in a browser using an XForms plug-in (such as DENG) will use XHTML as the host language for XForms. Consequently, XForms is only one of several XML technologies employed by the PureEdge suite. However, it’s the means by which user data is collected, verified, and validated.

Because e-forms are securable, they support signatures via secure digital identities. Because they’re writeable, users can — via either the Viewer or the Web Server — “fill out” the form, updating its contents. E-forms can even include attachments (such as image data), which a user can “insert” into an e-form in an entirely intuitive fashion.

When developers create an e-form, they can define virtual folders within it. They can also specify that a button on the e-form will open a standard file dialog box, allowing the user to choose a file (or files) to be copied from the local file system into the e-form’s virtual folder.

An e-form is executable in the sense that it carries all its business logic within itself. Much of that business logic can be handled by XForms, which performs schema data-type validation, calculates intermediate values, and applies constraints to the data.

For custom calculations or procedures that exceed XForms capabilities, a PureEdge e-form can even include embedded Java classes. These classes reside in the e-form document itself, and their methods are made available as functions to the computation engine.

The PureEdge Server is made up of several products. The Deployment Server aids in the deployment of the Viewer, which allows clients to interact with e-forms in a disconnected state when the Server is unavailable.

The Server’s PureEdge API provides a document model for working with PureEdge e-forms and includes features that, for example, let you load a form template from a file or content management system, prepopulate the template with data to create an e-form, and serialize the e-form for transmission to the client.

Finally, the Web Server creates a “zero-footprint” platform that lets clients work with e-forms via a Web browser (though such an arrangement does lose some capabilities — signatures, for example).

What makes a PureEdge e-form particularly versatile is that it’s entirely self-contained: It’s a single, compound file. Because the system sees it as just a file, storage can be a complex content management system or a simple database. For the same reason, e-forms are easily delivered to clients. The process is as simple as an e-mail attachment.

The PureEdge Viewer assists in an e-form’s versatility. When the user fin-ishes filling out the form, clicking a button within the Viewer automatically attaches the e-form to a new, blank e-mail gener-ated by the default e-mail client. If the Viewer is run while the local system is on a network, the Viewer can connect with Web services on the PureEdge Server, pulling in “live” data based on user input.

PureEdge is an enterprise-level solution, and the pricing shows it. Although the cost varies on a case-by-case basis, an organization with four developers and an esti-mated customer base of 10,000 would pay somewhere in the neighborhood of $200,000. If you want a taste of PureEdge — and I recommend exploring the package fully before settling on it — you can download the free version of PureEdge Viewer and several sample e-forms from PureEdge’s Web site.