Why XForms might be a Winner

mgm develops several large scale web applications containing hundreds of forms, e.g. the e-government portal ElsterOnline Portal. Design, implementation, test, and maintenance of these forms implies significant effort. We are currently evaluating different technologies – including XForms, Wicket and JSF (ICEfaces) – that could help us to reduce these efforts, to improve quality and set the framework for our next generation web forms-centric applications.

For many enterprise web applications, HTML forms are a critical challenge. Java-based enterprise web application are typically built on server-side frameworks like Struts, JSF (ICEfaces) or Wicket which only provide very basic form controls. On the other hand, advanced RIA frameworks like ExtJS do require a lot of error prone JavaScript code.

A New Perspective on Web Forms

In the old days HTML forms were very easy to create. It was simply a matter of writing a few HTML tags. But those forms provided very little interactivity and the server-side processing was cumbersome. Current Java web frameworks tend to encapsulate everything into Java objects, making web forms programming similar to desktop GUI development. The downside of that is that rather low-level Java code has to be written and that the resulting application is tied to the web framework and its programming model.

This screenshot is taken from an evaluation project done for one of our clients. It shows how to build nice-looking layouts with XForms. We will describe how we built this form in one of the next articles.

From that perspective, XForms could provide the best from both worlds. This W3C standard allows building simple forms – very similar to HTML forms –, but also provides a powerful document model for implementing complex interactions and data validations. All communication is done via XML documents, which allows using complex data structures and is not tied to a specific programming language or architecture.

The MVC architecture of XForms

Here are some examples that can be accomplished very easily with XForms:

  • Repeating structures: for instance, adding items to a shopping basket or adding items to an expense declaration.
  • Wizards: exposing successive parts of a form without returning to the server.
  • Multiple submission: submitting results to different servers.

Browser support and Implementations of XForms

Similar to HTML, XForms is basically just a document format for defining input controls, data structures, and validation rules. Since current browsers do not understand XForms, these documents have to be handled by an XForms processor which can be implemented in various ways:

  • Server-side: The XForms processor is implemented as a server application which transforms all functionality related to XForms to something the browser understands (i.e. HTML+JavaScript). – Orbeon, Chiba, betterFORM
  • Browser Plug-in: The XForms processor runs within the browser and is implemented as a plug-in/extension or requires the installation of a plug-in (e.g. Flash/Java). – Mozilla XForms, IE FormsPlayer
  • JavaScript: The XForms processor runs inside the browser and is implemented in JavaScript. – EMC Formula

I’ve added a list of the XForms implementations that we have evaluated. In a later article we will comment in detail on our experiences with three selected XForms processors: Orbeon, Chiba, and the EMC Formula XForms Engine.

XForms Implementation Type
AJAXForms Client-side (Javascript)
betterFORM Server-side (JEE)
Chiba Server-side (JEE)
DENG Client-side (Flash)
EMC Formula XForms Engine Client-side (GWT)
FormFaces Client-side (Javascript)
formsPlayer Client-side (Browser-Plugin)
Mozilla XForms Client-side (Browser-Plugin)
MozzIE Client-side (Browser-Plugin)
Orbeon Server-side (JEE)
Ubiquity formsPlayer Client-side (Browser-Plugin)
Ubiquity XForms Client-side (Javascript)
XSLTForms Client-side (XSLT+Javascript)

The W3C also has a extensive list of all XForms implementations. A huge source of information about XForms and its implementations is the Wikibooks page on XForms.

Long Term Perspective with XForms

In the long term, we hope to be able to leverage specific features of XForms to allow approaches that are currently very hard to achieve:

  • Closer involvement of business departments in the form definition and testing process. Because most aspects of XForms are document-centered, they could be built or generated from an abstract, high level specification. This could help in reducing repetitive work in the development department and in increasing agility in the business departments.
  • Building different versions of a form from a single source document. XForms processors can provide forms for typical web applications as well as for desktop or mobile applications.
  • Dramatically decreasing latencies for high scale web applications. If we had a mature XForms processor running within a browser (either as a plug-in or a JavaScript implementation), server roundtrips would only be necessary for reading or submitting data.

In the next part of this series we’ll have a look at a small XForms application running on the Orbeon XForms engine.

Share

Leave a Reply

*

3 Responses to “Why XForms might be a Winner”

  1. clarkepeters says:

    Making the transition to xforms is a bit cumbersome at first, but once you get your mind wrapped around it, for web development, you won’t find anything better.

    I am not a professional programmer but I designed several applications using only Xforms–no javascript whatsoever (e.g. a forms-maker, a forum and BB engine, a BB code text editor, to name a few) and it’s power is remarkable. Particularly, in using either switch/case elements or using binding and relevancy, you can keep so much of the page/application hidden until needed–if needed at all. It’s really awesome to look at an online full web application that is completely written into a single html (xhtml) page –without even a hint of javascript (of course, you can use javascript within your application if you like).

    Modularity is a bit of a problem, however. On the one hand, you don’t have to write special code for every gui widget because it is built into xforms, but if you yourself combine several widgets that work great together, you’ll end up copying and pasting that code whenever you want to reuse it — UNLESS, you use something like XBL. So far, the only one I know that supports XBL is Orbeon forms. I use mozilla xforms myself, but am debating making a switch to Orbeon for that very reason.

    The only problem you might have is if you’re thinking of client-side support, unless you want to pay for it. Here, mozilla-xforms is far above the rest, according to my experience and testing. However, since IBM pulled out their support, you just don’t know when the upgrades will halt altogether. It is being maintained by a few who have kept upgrades up to FF 3.6, but what happens when these people also move on to other things and in the meantime FireFox continues on to higher versions that eventually become incompatible with the last mozilla-xforms extension. The other open source client-side xforms processors such as Ubiquity and XSLTForms are still in development and I haven’t been able to get my mammoth application to run on either of these processors. However, I can say that for smaller forms such as information gathering forms, XSLTForms won’t fail you and is production ready. Because it is XSLT it’ll run on any XSLT supportive browser for many years to come. But you might run into problems if you’re doing a large and complete application with XSLTForms–unless you design it from the ground up using XSLTForms so that you don’t run into the quirks that I’ve run into by trying to convert an application that was originally built and tested with Mozilla-Xforms. (It will be a few more years before any xforms applications that runs on one processor will be able to run out-of-the-box with any other processor, but that gap is closing rapidly, I think.

    • clarkepeters says:

      sorry, don’t want to be misleading, Firefox supports XBL 1.0 and so in turn does anything written with Mozilla-xforms, however, I have to make a switch because I need to go into production, and since there is no guaranteed support I need to switch, and this is why I’m looking to Orbeon — which supports XBL 2.0 and these guys are very professional so they will be around for a long time.

  2. Ryan R says:

    I agree that the HTML forms are too cumbersome, while the Java forms are too complicated. Let’s hope this bridges the gap.