XForms: Are They for Real?
- Before We Begin: Why Do We Need "Another" Forms Technology?
- XForms Demystified: What Is It?
- XHTML Example: What Does It Look Like Today?
- Enter XForms: What Will It Look Like?
- XForms: Where Do We Go from Here?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
My previous articles discussed how to use the existing web infrastructure to submit XML documents. The examples revolved around using the HTML form elements that were processed suitably on the server side into an XML tree by Active Server Pages or a Java class. But what if I told you that "soon" there will be a technology available that allows us to submit XML data directly to the server without using even one line of the code we previously discussed? This article introduces the World Wide Web Consortium (W3C) Markup Working Group's current proposal to introduce XForms and explains how it's likely to simplify the interaction between a web infrastructure and a device like a browser on your workstation. I'll also discuss what resources are available for you to find out more about this set of standards.
Before We Begin: Why Do We Need "Another" Forms Technology?
HTML forms need no introduction. They're pervasive on the web—from the airline tickets that you search for on Expedia to the next DMV appointment that you schedule online. They're being used to collect information or to allow searching of information all over the web in very innovative ways. Every interaction that we have with a web site that provides dynamic content uses HTML forms in some shape or form. The ubiquitous <FORM> element, along with its range of radio buttons, check boxes, text boxes, select lists, and text areas, is found on almost every site on the web.
But there are distinct challenges to this approach. HTML forms have originated from the initial objective of HTML to provide user-readable information. This implies that the data in these forms is very closely coupled with how the information needs to be presented. The HTML forms require that the data submitted be validated by either some JavaScript code on the client browser or be validated at the server end by some server-based code for its integrity. In addition to validation, the scripts may be required for calculations, business logic, and ensuring that all required data is available. The data from an HTML form is submitted as URL-encoded name/value pairs (as discussed in a previous article). This implies that all data is treated as string data, unless the program on the server suitably converts it and processes the data with the associated types.
Even though HTML's <FORM> element has become so successful, it suffers from the lowest-common-denominator syndrome for its controls. Despite the number of years that the technology has been in common use, we don't have a slider control, a gliding scale to represent continuous values, a drag-and-drop for widgets, or other GUI elements that we take for granted in other user interfaces.
Also, it's fairly challenging for developers to deal with devices other than a web browser on platforms other than a workstation or a PC. Handheld devices that have similar interaction needs use a stripped-down version of HTML and HTML forms. Companies like Everypath are good examples of business models that provide services to enable web sites for handheld content, by acting as a translation layer between handheld devices and the actual web site.
Another challenging aspect for HTML form-based applications is forms that span multiple pages. For example, suppose you apply online for some insurance. Based on the questions that you answer on the first page of the form, you're provided with a series of questions on subsequent pages until you finish the application process. Typically, this interaction and flow is handled in one of the following ways:
Cookies are saved on the user's browser, containing some of the content from previous pages or the unique identifier of the user's session, which binds it to some session-information table. This session table may be persisted in the memory of the server (usually a bad programming practice) or a temporary table, which allows the information to be built on the final submit.
An easier approach is typically to hide this information as hidden form fields. As the user goes from one step to the next, the corresponding data is a payload that piggybacks on the HTML form of the next step. This continues until the final submit, when the hidden data from all the previous steps is finally committed to the application.
Needless to say, each of these approaches can be reasonably challenging.
Developers have been creating applications that are based on content-scrapping from other services or that involve interaction of two machines, by using HTTP web interfaces to exchange XHTML information. The applications rely heavily on predefined mapping templates and are prone to lot of parsing errors because any change in structure of one site affects the interaction between the two systems.
Keeping in mind the above limitations of the current HTML-based infrastructure, a subgroup of the W3C Markup Working Group has proposed XForms to improve human/machine and machine/machine interaction.