1.3 Limitations of HTML Forms, Advantages of XForms
| According to developers, the most commonly cited problem with HTML forms is their dependency on scripting languages. Real-world HTML forms are reliant on script to accomplish many common tasks such as marking controls as required, performing validations and calculations, displaying error messages, and managing dynamic layout. This dependency results in complex documents, which are expensive and time-consuming to maintain, since a full-time programmer is practically necessary when dealing with that much script. XForms helps reduce the need for script in several ways: by defining a framework for simple, XPath-based calculations and validations, by providing better user feedback on the status of the form, through dynamic features such as repeating tables and optional sections, and through a system of XForms Actions elements that cause commonly needed actions such as setting focus or changing a data value. A second limitation of HTML forms is the difficulty of initializing form data, as commonly happens when web sites "remember" past users and provide them the courtesy of not having to repeatedly enter information. As shown earlier, each form control has its own unique way of defining initial data, with small bits of initialization data spread all across the document. This means that in order to process a blank form into a filled form, either a new document needs to be constructed piece by piece, or an existing document needs to be patched in numerous places one of the reasons why template-replacement facilities are commonly found in application servers. Constructing such forms is CPU-intensive and leads to bottlenecks on high-volume servers. In XForms, form data is provided from an initial XML file, which can be external to the form definition. Since XForms is also flexible enough to deal directly with most XML data formats, piping initial data into a form is typically a simple matter of pointing a src attribute to an existing XML data source. A third limitation of HTML forms is that the encoding formats, urlencoded or multipart, represent only "flat" data, or name/value pairs. Many types of forms, including purchase orders, would benefit from a richer data representation. XML is a better foundation for most business documents than a flattened set of names and values. Since it has XML support as a fundamental requirement, XForms excels at helping users create those kinds of documents. More subtle, but still serious, is a fourth fundamental design flaw in HTML forms: a hidden assumption of a one-step process from a client to a server with processing finishing there. In the real world, forms often travel in more complicated paths. For example, a vacation request form might go to a supervisor for approval, then to the human resources department, and finally to accounting for final processing. Managing HTML forms in such a workflow scenario involves reinterpreting the data format at every stage. Perhaps this is one reason why HTML forms aren't commonly seen in use for workflow. XForms enables a different pattern: it allows form data, as an XML file, to be routed to various workstations, as needed. At each stop, the data is loaded into a form, which provides a viewport into editing all or parts of the document, and submitted again. This process can be repeated as many times as necessary, with any number of participants. As the HTML Working Group became increasingly aware of the limitations inherent in HTML forms, they decided that they needed to develop a new, non-backward-compatible specification for web forms. To do this, they formed a subgroup (which later became a full Working Group) to define the requirements and begin the initial design work of XForms. They set out to produce a system that would fulfill the following requirements:
|
