3.8 Submitting Data

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

• what to submit,

• where to submit, and

• how to submit

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

Binding

Optional XForms binding attributes, that is, attribute pair ( model , ref ) or attribute bind , is used to specify the data that is to be submitted. These binding attributes are used to address a specific portion of the instance if only a part of the data collected is to be submitted. By default, the first data instance is submitted in its entirety.

Where to Submit

action

Attribute action specifies the protocol and location for data submission. The name was chosen to retain consistency with HTML forms that use an action attribute on element form for the same purpose.

How to Submit

method

Specifies the method used to submit the data. The value of this attribute may be one of a predefined set of values designed to cover commonly used methods on the Web today. It is also designed to be extensible to allow future methods . The predefined values include

Method	Description
post	Send XML using HTTP POST
put	Send XML using HTTP PUT
get	HTTP GET
multipart-post	Send XML using HTTP POST
form-data-post	Send data using multipart/form-data
urlencoded-post	Send url-encoded data

Method names not appearing in this list may be used as long as they are qualified with the appropriate namespace. This provides an extensibility mechanism for easily incorporating emerging XML protocols.

separator

Optional attribute separator (default is ; ) specifies the separator character used when encoding multiple fields in conjunction with method get . This is present to enable authors to choose explicitly between using & and ; to separate encoded fields within a URL when using method get . The older HTML choice of & is not XML-friendly, and as a result Web forms are now beginning to use ; as the separator. This attribute is present to give the author explicit control if necessary.

encoding

Attribute encoding specifies the encoding to use when serializing the data.

replace

Attribute replace enables XForms-aware user agents and servers to process intelligently partial submission and data refresh. When using today's HTML forms, submitting data to a server results in the response being delivered as a new HTML page. As a consequence, transactions consisting of multiple stages require retransmission of the entire Web page from server to client at each stage of the transaction.

This was necessitated by the lack of separation between model and user interaction inherent in the HTML forms design. Given its model vs. interaction separation, XForms provides more design flexibility with respect to how the response to a form submission is processed on the client. Since we have separated the model from the user interface, the XForms author can specify whether a submission response is to update one of either the XForms model, the user interface, or both via submission attribute replace . XForms 1.0 specifies three predefined values for attribute replace :

Value	Description
all	Server response replaces current view
instance	Server response replaces only instance data
none	Server response treated as an acknowledgment

In addition to the values shown here, namespace qualified values may be used for attribute replace when experimenting with new interaction behaviors. The default behavior is to replace both the model and user interface to match the behavior of today's HTML forms. Replacing the instance provides a powerful means of refreshing the user interface without retransmitting all of the original markup. Note that an XForms model can contain more than one instance; this is an advanced concept that is introduced in a later chapter. When using multiple instances in a model, XForms always defaults to the first instance, and this is true in the case of attribute replace as well.

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:

indent	Boolean that specifies if the instance data should be indented when it is serialized as XML
version	Specifies the version of XForms in use
omit-xml-declaration	Specifies if the serialized instance data should include the following XML Processing Instruction: <?xml version="1.0"?>
standalone	Specifies if the serialized instance data is a stand-alone XML document
cdata-section-elements	Names elements in the instance whose contents should be escaped as XML CDATA sections when serializing as XML

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  > 

specials	Subtree rooted at specials holds special offers.
scratch	Subtree rooted at element scratch functions as a scratch pad for holding intermediate values needed by the shopping application.
cart	Subtree rooted at element cart holds one or more item elements.
open-orders	Subtree that holds information about the user's open orders. This subtree will be used by the XForms server hosting the e-store application to hold information about the user's currently open orders.

In this case, we use an appropriate binding attribute

 ref="/e-store/cart" 

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:

Trigger	User triggers control submit . As described earlier, control submit is syntactic sugar for a trigger that generates a xforms-submit event.
Target	Event xforms-submit is dispatched to the submission specified by attribute submission .
Handler	Upon receiving this event, element submission first invokes any event handlers that have been declared as child elements. In this example, invocation of action handler message displays a message indicating that the purchase order is being submitted.
Locate	Next, the binding attribute specified on element submission is evaluated to locate the portion of the instance data to be submitted. If no binding attributes are present, the entire instance is prepared for transmission.
Serialize	The located portion of the instance data is serialized in accordance with the values specified for attributes method , mediatype , and encoding .
Transmit	The resulting serialization is transmitted to the location specified via attribute action using the method specified by attribute method .
Response	The server response is processed as specified by attribute replace . The value of instance for this attribute causes the XForms client to treat the response as an update to the data model.
Refresh	Once the data model has been updated as specified by the server response, the user interface is refreshed. Here, the server response has updated sub tree /e-store/open-orders . User interface controls that binds to /e-store/open-orders are refreshed to display the newly available information.

Table 3.3. XForms Controls at a Glance

Control	Description
input	Generic input control
secret	Password entry
textarea	Multiline text entry
select	Select from a set
select1	Exclusive select from set
range	Pick from range of values
upload	Upload data
trigger	Activate command
submit	Trigger submission