The W3C XForms standard offers a great way to define forms. XForms is really beneficial if you want to develop complex forms with many subsections, with complex logic and if, at the same time, you want the result to be long-term maintainable. XForms is a W3C standard supported by many vendors, allowing you to invest in forms development without getting stuck into a vendor lock-in.
We are not talking about simple contact forms here, but rather about extended, complex forms, such as tax forms, application forms et cetera. As these forms contain business rules, they might be considered mini-apps.
Combine the power of the XForms standard with smart tools, such as the Smartsite XForms Engine and Workbench, and productivity in forms development and maintenance will soar. XForms allows us to define a form declaratively, just like a programmer would do. Not only is there is rich set of controls and an extensive event model, but XForms also offers a great way to create custom implementations with a completely personalized look-and-feel. In this step-by-step tutorial we will try to demonstrate the power of this standard.
In the tutorial section we will build a form from scratch and gradually extend it to include validations, dependencies and other smart features. We will create a simplified version of a fairly complex form that authorities may offer for entities wanting to organize public events. This could be either a person or an organization and many types of (indoor or outdoor, small scale or large scale) events are possible.
The first XForms draft specification was published on April 6, 2000 and was titled "Datamodeling Proposal for XForms". This premature version has little to do with the current XForms specification. As the W3C XML Schema workgroup picked up speed, this first draft was quick to become obsolete. The workgroup made a brave choice to accept this fact and go back to the drawing board.
After much reworking and revising in November 2002, the XForms Candidate Recommendation was released. It became a final W3C Recommendation in October 2007. There has been a 1.1 release of the recommendation in October of 2009 and currently work is under way for a 2.0 specification.
The software industry has been slow in adopting the XForms standard but the industry giants committed themselves with a few exceptions. IBM has been a strong supporter over the years and offers a broad range of XForms related documentation on its web sites. The Lotus Forms Server uses XForms (together with the XFLD, another W3C standard) to specify and process forms.
Novell, SAP and Sun Microsystems all use XForms to some extend. Microsoft went on to develop InfoPath as a forms platform, using proprietary technology for tight integration into its own products, such as Outlook.
The XForms specification uses some terms that sound familiar but may have a slightly different meaning that what you are used to. Unlike HTML, XForms does not have a single self-contained element, such as the HTML form tag, in which to embed the total form information. Generally, a complete XForms document consists of some HTML (be it HTML 4, HTML 5 or XHTML), with some added namespaces and some XForms code in several places in the document.
XForms adheres to the MVC approach: a Model, View and Controller. To quote the W3C XForms specification:
In short, the model contains all business rules for the form, the view determines the presentation of the interaction with the user, and the controller is the engine that makes everything work. The illustration below from Wikipedia illustrates this:
The XForms specification does not use the concept of field, which is something most developers generally understand (although not specified in HTML). Instead, it proposes controls.