The previous sections have described the various XForms user interface controls for collecting data from the user. Data collection apart, user interface controls are used to trigger specific actions. In traditional visual interfaces, such controls manifest themselves as buttons. Buttons in a visual interface are wired to an underlying action to be executed upon activation of the button. The visual rendering of the button is styled to indicate whether the underlying action is currently available to the user. A specific user action, for example, pressing the button, causes the underlying action to be triggered. XForms defines abstract control trigger that provides a generic framework for connecting user events and actions. Notice that this is in line with the rest of the abstract user interface markup provided by XForms. The design of user interface control trigger is not specific to a given representation, for example, buttons in a visual interface; nor does it restrict the interaction behavior to specific user events, for example, pressing a button. Element trigger holds all the metadata needed to produce appropriate renderings of the control on a given target modality or device. The event that activates the trigger, as well as the action to be invoked upon activation of the trigger, is authored using XML Events described in Section 2.3. XForms defines a number of declarative action handlers that can be used within trigger to create specialized interactions. This section first describes the design of element trigger and then describes XForms action handlers that can be used with element trigger . A complete catalog of XForms event types and declarative actions is given in Chapter 7 and Chapter 8. 3.7.1 Anatomy of Element triggerElement trigger uses all of the common attributes and child elements described in Section 3.2. In addition, it uses markup defined by module XML Events, described in Section 2.3, to wire up events and actions. Unlike other XForms control, trigger does not operate directly on instance data stored in the XForms data model. As a result, binding attributes are not mandatory on control trigger . Binding attributes may, however, be used to enable or disable the trigger conditionally. The XForms data model can hold dynamic properties that determine if a piece of instance data is relevant at run-time (see Section 5.3). Binding control trigger to such instance data results in the control becoming enabled if and only if the bound instance data is relevant . Figure 3.25 shows an example use of trigger . Figure 3.25 Using trigger to wire up events and actions.< body xmlns:ev ="http://www.w3.org/2001/xml-events"> < trigger xmlns ="http://www.w3.org/2002/xforms" id ="getPersonal"> < label >Collect Personal Information</ label > < setfocus control ="personalInfo" ev:event ="DOMActivate"/></ trigger >... < group id ="personalInfo"> < label >Personal Information</ label > ...</ group > </ body >
Figure 3.25 shows a fragment of a user interface consisting of multiple conceptual pages . Each group of controls is authored within a separate group construct described in detail in the next chapter. Depending on the characteristics of the target device, each group might be displayed on a separate screen. The trigger shown here is used to move to the section in the user interface that collects personal information by invoking XForms action handler setfocus . It achieves this by listening for event DOMActivate ”a generic event that might be raised when the user activates the control, for example, by clicking a mouse when using a visual interface. Action setfocus specifies the control to move focus to the attribute control as shown in this example. Notice that action setfocus appears as a direct child of element trigger in this example. If there were multiple actions to be executed in response to the DOMActivate event, we would have used element action to group the various actions. Notice further that attribute ev:event has been placed on element setfocus , as opposed to placing it directly on element trigger . This usage is consistent with XML Events and affords the ability to create triggers that invoke different actions based on the received event as illustrated in Figure 3.26. The trigger shown in that example responds to two separate events, DOMActivate and xforms-focus . It invokes action setfocus upon receiving event DOMActivate , as in the earlier example. In addition, it has been set up to refresh the XForms user interface when this control receives focus. This is achieved by attaching a refresh action that responds to event xforms-focus . Figure 3.26 Element trigger can invoke different actions based on the received event.< body xmlns:ev ="http://www.w3.org/2001/xml-events"> < trigger xmlns ="http://www.w3.org/2002/xforms" id ="getPersonal"> < label >Collect Personal Information</ label > < action ev:event ="DOMActivate"> < setfocus control ="personal"/> < refresh ev:event ="xforms-focus"/> </ action ></ trigger >... < group xmlns ="http://www.w3.org/2002/xforms" id ="personal"> < label >Personal Information</ label >...</ group > </ body > |