The user interface controls described so far can collect user data and enable the triggering of actions in response to user interaction events and are sufficient to implement a large number of online interaction. When designing XForms, we felt that enabling the user to trigger the specific action of submitting the collected data to the Web server was sufficiently important to deserve its own user interface control. HTML4 had achieved such submit buttons by overloading the input control with a value of submit for attribute type . We decided to define element submit as a separate submit control because submit processing is significantly different from the role played by controls that allow the user to input data.
User interface control submit can be implemented using a trigger control that invokes action send . In this sense, element submit is syntactic sugar that is present to ease authoring.
This section describes control submit and then details submit processing as defined by XForms. As with the rest of the XForms design, submit processing relies on the XForms model for encapsulating all of the display-independent aspects of submit processing. Submission- related information is encapsulated in XForms model element submission , which will be described in Section 3.8.2.
3.8.1 Anatomy of Control submit
Control submit can use all of the common attributes and elements described in Section 3.2. Control submit , like trigger , does not directly affect the underlying instance data, and XForms binding attributes are therefore not required. However, as in the case of element trigger , XForms binding attributes may be used on element submit to enable or disable the submit control conditionally. In addition to these common markup components , required attribute submission on element submit is used to connect the submit control with the portion of the XForms model that specifies the details of the data to be submitted. Value of attribute submission specifies the id of the corresponding submission element. Details of
are encapsulated in element submission .
Figure 3.27 shows an example of control submit . When the user activates control submit , an xforms-submit event is dispatched to element submission , identified by attribute submission .
Figure 3.27 Control submit encapsulates all presentational metadata associated with the submit control.
< html xmlns ="http://www.w3.org/1999/xhtml"> < head > < model xmlns ="http://www.w3.org/2002/xforms"> < submission id ="buy">...</ submission > </ model ></ head > < body > < group xmlns ="http://www.w3.org/2002/xforms"> < submit submission ="buy"> < label >Submit Purchase Order</ label >... </ submit ></ group > </ body ></ html >
In this example, the event is dispatch to element submission , identified by buy . Notice that this design enables an XForms document to contain multiple submission elements, an advanced feature that makes authoring applications containing multiple forms significantly easier than when using HTML forms.
Notice further that the markup for element submit is completely independent of the final form representation used to render the control in a given modality. Further, the markup does not force the author to specify the user interaction event that should trigger the submit action. Leaving both the presentation and interaction behavior of submit controls to be determined by the target user interaction environment makes the XForms submit control suitable for deployment across a wide variety of end-user devices and interaction modalities.
3.8.2 Modeling What, How, and Where to Submit
Element submission within XForms element model holds the necessary details about what, where, and how to submit. Notice that in the older HTML forms design, this information is encapsulated within element form that appears as part of the user interface markup. When designing XForms, the working group made a conscious decision to factor out all nonpresentational aspects of submit processing from the user interaction markup. This information is kept inside the XForms model element since it does not change when binding different interaction modalities to a given XForms model.
Thus, the data to be collected from the user, the location to which this data is transmitted, and the manner in which it is serialized during transmission are all independent of the user interaction that was used to collect the data. By encapsulating this information within the XForms model, this design makes it possible to bind either the XForms user interface controls described in this chapter or a different user interface vocabulary to the same underlying XForms model.
In addition, separating submission details from the user interface controls used to invoke the submission has the advantage of enabling a single XForms document to offer multiple submit controls within the same document, with each submit control possibly submitting different subsets of the data collected to a different network location. At the same time, the common use case of submitting all data collected from the user to a given location remains extremely simple.
3.8.3 Anatomy of Element submission
XForms element model can contain one or more submission elements. Here, we describe the attributes and elements that are allowed in element submission . Submission related metadata is carried within attributes on element submission . Additionally, declarative XForms event handlers may appear as child elements within element submission . Such event handlers are invoked before the data is submitted and enable authors to attach custom behaviors to form submission.
As described earlier in Section 1.3.4, element submission specifies the what , how , and where of the submission process. Attributes of element submission are described with respect to the following three categories:
What to Submit
Where to Submit
How to Submit
The metadata encapsulated by element submission about how to serialize instance data was modeled after XSLT element output . XForms allows the following attributes taken from XSLT element output on element submission . These are listed separately since they are used less often than the submission attributes described earlier:
3.8.4 Using Element submission
Next, we create element submission (see Figure 3.28 for the markup) needed to complete the shopping cart example. Submitting the purchase order by activating control submit causes the data stored in /e-store/cart to be serialized and transmitted to the location specified by attribute action .
Figure 3.28 Element submission that initiates a buy operation.
< model xmlns ="http://www.w3.org/2002/xforms">... < submission id ="buy" ref ="/e-store/cart" action ="http://example.com/e-store" method ="post" replace ="instance"> < action > < message > Ordering...</ message > </ action ></ submission > </ model >
The server responds with an XML instance that holds updated information about the user's currently open orders in subtree /e-store/open-orders . When this response is received by the XForms client, the data model is updated, and any user interface controls that bind to updated portions of the data model are refreshed. Thus, activating the buy submit control results in the user interface being updated with information about the newly opened order.
Assume that the items bought by the user have been collected into the XML subtree rooted at cart . Notice that in this example not all the nodes in the XForms model instance are to be submitted to the server. This situation often arises when an XForms application uses a portion of the data model to store intermediate computed values. Such partial submission is also useful if the XForms author has chosen to use a single model/instance pair to store all of the data for an application. For instance, the example shown in Figure 3.29 contains four XML subtrees under the e-store root element:
Figure 3.29 Skeleton data model used by a shopping application.
< model xmlns ="http://www.w3.org/2002/xforms"> < instance > < e-store xmlns =""> < specials >...</ specials > < scratch >...</ scratch > < cart > < item >< sku />< quantity />< price /></ item > ...</ cart > < open-orders >< order />...</ open-orders > </ e-store ></ instance > </ model >
In this case, we use an appropriate binding attribute
on element submission to locate the data that is submitted to the server.
Attribute action specifies where the data is to be submitted. Attribute method specifies the method to use for serializing and transmitting the data. Attribute replace is used to specify how the server response is to be interpreted. In this application, the author has specified that the server response be treated as an update to the XForms data model.
Finally, the author has set up an event handler inside element submission (by using action message ) that displays a message to the user that the purchase order is being submitted. Event handlers inside element submission are invoked before the data is transmitted to the specified location. This gives authors the ability to add custom interaction behavior when data is being submitted. Note that today's HTML authors depend on scripting for achieving similar functionality by attaching an event handler to the onsubmit event.
3.8.5 Submit Round-up
We conclude this section with a round-up that summarizes submit processing from the time the user activates control submit to the final step of updating the user interface based on the server response. We describe this process using events and the actions they invoke. The XForms processing model is defined declaratively in the XForms specification to ensure that implementations achieve the same results irrespective of variations in the underlying implementation. Following are the steps that occur in sequence during submit processing in the example covered in this section:
Table 3.3. XForms Controls at a Glance