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.
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.
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.
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:
- 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
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.
|EMC Formula XForms Engine||Client-side (GWT)|
|Mozilla XForms||Client-side (Browser-Plugin)|
|Ubiquity formsPlayer||Client-side (Browser-Plugin)|
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.
In the next part of this series we’ll have a look at a small XForms application running on the Orbeon XForms engine.