3.2 Common Aspects of XForms Controls


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 Control

XForms 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:

Bind

Binding attributes that wire control to model

Metadata

Metadata for giving feedback to the user, for example, labels

Presentation

Hints used to affect the rendering of the control

Style

CSS-based styling

Shortcuts

Keyboard shortcuts and accelerator keys

Navigation

Where this control appears in the navigation sequence

Behavior

Action handlers for custom behaviors

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.

graphics/03fig01.gif

3.2.2 Binding Controls to the Model

XForms 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

Markup

Purpose

Binding Attributes (Section 3.2.2)

model

Identifies the model containing the bound instance

ref

Identifies single node from the instance that is bound

nodeset

Identifies set of nodes from the instance

bind

Identifies bound instance data via a binding site

Common Presentation Attributes (Section 3.2.3)

appearance

Presentation hint ”one of full , compact , or minimal

class

CSS selector to specify rendering style

Common Presentation Child Elements (Section 3.2.3)

label

Label for the user interface control

help

Help text for the user interface control

hint

Tooltip for the user interface control

alert

Message to display in case of invalid input

Common Interaction Attributes (Section 3.2.4)

accesskey

Specifies keyboard shortcut for navigating to this control

navindex

Specifies position of the control in the navigation sequence

inputmode

Facilitates text input on small devices

eventing

XML Events attributes for wiring up events

incremental

Specifies if text input generates continuous stream of events

Common Interaction Child Elements (Section 3.2.4)

action

Declarative action handlers defined by XForms

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 Controls

End-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

appearance

Attribute appearance can be used by the author to specify presentational hints. XForms specifies three predefined values for this attribute:

  1. full

  2. compact

  3. minimal

The meaning of these predefined values is a function of the user interface control. As an example, appearance="full" might be used to request that a select selection control be presented as a list of checkboxes with all the available choices being visible to the user. In contrast, appearance="minimal" might be used to request that the same control be rendered to take up a minimal amount of display real estate and, as a result, appear as a pop-up menu in a visual interface.

In addition to the predefined values, attribute appearance encourages innovation by accepting application-specific values as long as these values are properly namespace qualified. Thus, an author creating an input control that binds to a value of type xsd:date can request that the control be presented using a custom date picker with markup (shown in Figure 3.3). The advantage of this design is that user agents not capable of using the custom date picker control can still effectively represent the user interface by using a regular text input field.

Figure 3.3 Requesting a custom date picker via attribute appearance .
 <  input   model  ="invite"  ref  ="/invitation/date"  appearance  ="my:date-picker"> <  label  >Invitation Date</  label  >...</  input  > 

class

When using XForms controls in HTML, attribute class can specify a CSS style to be used.

Common Presentation Child Elements

label

Holds the label for the containing user interface control

help

Holds help text to be displayed on request

hint

Holds tooltip information for the containing control

alert

Holds a message to be displayed if the form control is an invalid state, for example, when an illegal value is entered by the user

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 Controls

End-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

accesskey

Specifies the shortcut key to navigate to the containing control.

navindex

Specifies the position in the navigation sequence.

inputmode

Attribute inputmode was added to user interface controls that collect textual input to facilitate text entry on different devices. This feature is especially useful on small devices that need to provide the necessary aids to enable efficient user input when using various international character sets.

eventing

XML Events attribute pair ( event , handler ) is used to turn user interface controls into listeners . Attribute event specifies the event to listen for; attribute handler specifies the handler to be invoked upon receiving the specified event.

incremental

Optional boolean attribute incremental ( false by default) specifies if the containing user interface control fires events as the value is being entered. This is an advanced feature that might be used by user agents to update different parts of a form as the user is entering a value; leveraging the XForms processing model for implementing sophisticated user interfaces will be described in a later chapter.

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

action

Holds one or more action handlers. XForms defines a set of declarative event handlers that provides functionality commonly found in online forms. All of these handlers can appear within XForms user interface controls. Such handlers are executed when the user interface control is activated by the user.



XForms. XML Powered Web Forms with CD
XForms. XML Powered Web Forms with CD
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 94

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net