You are reading O'Reilly XForms Essentials by Micah Dubinko. (What is this?) - Buy XForms Essentials Online
Table of Contents
"This element encodes how, where, and what to submit."
—XForms Candidate Recommendation, 12 November 2002, section 3.3.3, "The submission Element"
Data collection is a multibillion-dollar industry, so it's not surprising that XForms includes a rich set of options for submitting form data. Getting data out of old HTML forms is an exercise in jumping through hoops, due largely to the limited data format defined for forms—name/value pairs generally. XForms can still provide data in these legacy formats, though it shines the brightest when sending XML data.
The four main questions in submitting form data are when, what, where, and how. The following sections discuss each of these questions.
Submit happens when the user presses the big button labeled "Submit," right? Well, sure, but there's more to the story than that.
Formally, a submission is initiated when an event called xforms-submit arrives at the submission element (described in detail later in this chapter) For more on XML events, see Chapter 7, Actions and Events. The reason for a separate event is so that submission can be requested in other situations, such as pressing Enter or meeting other conditions. The XForms Action send can explicitly send out the submission event, and the form control named submit, which otherwise behaves exactly like trigger, also dispatches an xforms-submit event, thus providing the click-to-submit feature...except that dispatching the xforms-submit event doesn't guarantee that the submission will complete successfully. Several things have to happen first:
The event has to actually reach its target element. The previous chapter discusses event processing, which includes ways to stop an event before it reaches its mark. If the event gets blocked for any reason, no submission happens.
Another submission on the same XForms Model must not be in progress already. Countless Internet surfers have suffered from duplicated message postings, or duplicated orders (or worse) because of clicking on a (seemingly) unresponsive submit button more than once. Clicking submit multiple times is safer under XForms processing because all clicks after the first will be ignored, at least until the submission completes and the user has been notified.
The form data must validate. One of the first things that submit processing does is to perform a full validation of the instance data in question. If any problems are found, the XForms processor will send out notifications to the invalid form controls and stop the submit-in-progress. This additional processing is a major benefit of XForms over earlier web forms systems.
Finally, it's possible for problems, such as a crashed server that can't accept any data, to occur during the submit process. In such cases, the submission can't be successful, and a notification event is sent.
Once a submit is underway, one of two things will always happen: either an xforms-submit-done event will be dispatched to the originating submission element, or an xforms-submit-error event will be dispatched to the model element that contains the originating submission element.