XForms user interface controls are used to collect user input. The various XForms user interface controls provide a consistent markup interface to ease authoring. The XML markup is designed to be familiar to today's HTML authors, while overcoming some of the idiosyncrasies found in HTML forms. This section presents a high-level design overview before presenting the syntactic details of the various user interface controls. In doing so, we will cover all aspects of common markup found in XForms user interface controls. 3.2.1 Anatomy of a User Interface ControlXForms defines a set of abstract user interface controls that collect and display user input. The XForms design separates these user interface controls from the data that is collected from the user. Abstract user interface controls are designed to capture the underlying intent of the user interaction, rather than its final presentation on any given device or in any specific modality. This makes it possible to deliver XForms applications to different devices and modalities. More generally , this design enables the creation of editing interfaces that allow the user to view and modify XML data and documents. The separation of the user interface from the underlying model and the design of this user interface as a set of abstract user interface controls result in all XForms controls having the following structure:
These aspects are authored via a set of attributes and child elements common to all XForms user interface controls. These characteristics of a user interface control can be grouped according to their functionality as pertaining to the model, presentation, and interaction behavior, respectively ”see Figure 3.1. We summarize these for easy reference in Table 3.2. Figure 3.1. Anatomy of an XForms user interface control.
3.2.2 Binding Controls to the ModelXForms user interface controls are connected to the underlying data model using binding attributes . Attribute pair ( model , ref ) specifies the portion of the instance to be populated by a given control. We use a pair of attributes here since XForms permits the creation of Web applications that use multiple models, for example, when creating a complex application that needs to submit data to multiple locations on the Web. Binding attribute model identifies the model that contains the instance being populated; Attribute ref holds an XPath locator that identifies the location in the instance that is being populated. Binding user interface controls to the model was illustrated in Figure 1.5 and Figure 1.7. Table 3.2. Common Aspects of XForms User Interface Markup
Thus, binding attributes wire user interface controls to the appropriate portion of the underlying XForms model. In addition to attribute pair ( model , ref ) described earlier, XForms provides a syntactic shortcut for creating binding expressions that involve complex XPath expressions. When defining the XForms model, the author can identify certain locations with a designated id declared via element bind . Such binding sites can be later used when binding user interface controls by specifying the id of the binding site as the value of attribute bind . This mechanism is useful when binding multiple controls to the same location in multipage forms. For instance, consider a tax form that collects multiple items of information and displays the most important items on a summary page ”see Figure 3.2. Figure 3.2 Using binding sites for connecting user interface controls to the model.< html xmlns ="http://www.w3.org/1999/xhtml"> < head > < model xmlns ="http://www.w3.org/2002/xforms"> < instance > < data xmlns ="">...< wages />...</ data > </ instance > <!-- identify binding site --> < bind ref ="/data/wages" id ="wages"/> </ model ></ head > < body > < h1 >Page 1</ h1 > < group xmlns ="http://www.w3.org/2002/xforms"> ...< input bind ="wages">...</ input >... </ group >... < h1 >Summary Page</ h1 > < group xmlns ="http://www.w3.org/2002/xforms"> < output bind ="wages"> < label >Total Wages Reported</ label > </ output ></ group > </ body ></ html > The author can identify those information items that appear on multiple pages as binding sites when defining the model. Later, when authoring the user interface, attribute bind can be used when binding user interface controls to these binding sites. This has the advantage if the structure of the instance needs to be changed at a later date. When such changes are made, the XPath locators need be edited only in one place, namely the model where the binding site is declared. If the attribute pair ( model , ref ) were used in this scenario, this would require the editing of the binding attributes on the different user interface controls. This said, using attributes ( model , ref ) is more convenient , except in such complex examples, since the extra level of indirection introduced by the use of binding sites makes the resulting markup less obvious. 3.2.3 Rendering User Interface ControlsEnd-user experience is controlled via a set of attributes and child elements common to all XForms user interface controls. These common markup constructs hold metadata associated with the user interface control, for example, the label to be displayed to the user; they also encapsulate presentation hints that can be used in delivering the desired presentation. Common Presentation Attributes
Common Presentation Child Elements
Note that elements label , help , hint , and alert when used must appear in this specific order. Element label is required on all XForms user interface controls. In addition to providing a label for the user interface control, the content of this element can be useful to accessibility aids; for example, an accessibility aid might speak the contents of this element when the user navigates to a control. Element label was designed to be a child element of the user interface control in order to improve accessibility of electronic forms. Traditional HTML form controls did not capture the label as part of the markup for the user interface control; this resulted in authors visually aligning labels for user interface controls using HTML tables. Though this delivers a visual presentation that clearly displays the association between labels and user interface controls, it presents a serious accessibility problem. Accessibility aids were forced to guess the association between labels and controls by examining the visual layout. By making element label a required child of all user interface controls, XForms takes a major step forward with respect to enhancing the accessibility of Web applications. Elements label , help , hint , and alert can directly encapsulate the information to be shown to the user. Alternatively, this metadata can be specified indirectly by specifying a URI as the value of attribute src . Specifying such metadata indirectly can be helpful when creating user interfaces that need to be localized. In such cases, one can create locale-specific sets of messages and use attribute src to refer to the messages. 3.2.4 Interaction Behavior of Form ControlsEnd-user experience ”the look and feel delivered by a user interface ”is a function of the end-user presentation as well as the behavior exhibited by the user interface in response to user actions such as key presses and mouse clicks. Interaction behavior of XForms user interface controls can be customized via the common attributes and child elements described in this section. Common Interaction Attributes
Attributes accesskey and navindex are important accessibility features first introduced in HTML4. Specifying keyboard shortcuts via attribute accesskey can enhance the usability of an online form by enabling the user to navigate directly to a control via the keyboard. Specifying the position of a user interface control in the navigation sequence via attribute navindex gives the author the ability to influence the order in which the user navigates through a sequence of controls. Common Interaction Child Element
|