The purpose of Web applications created using XForms is to deliver dynamic user interfaces. User interfaces come to life when integrated with an eventing mechanism that enables application authors to listen for user and system events and to invoke handlers that trigger application-specific behavior. Today, Web programmers commonly achieve this by using ECMAScript event handlers that operate against the Document Object Model (DOM). XForms uses this same DOM2 eventing model as specified in DOM2 Events [5] to specify how user and system events are processed in the context of XForms applications. However, instead of relying exclusively on ECMAScript, XForms provides a set of declarative event handlers that covers many common use cases, thereby obviating the need for custom scripts. In addition, rather than using the somewhat ad hoc events syntax used by HTML, XForms authors access the events model via markup specified by XML Events [6] an XML module that provides XML languages with the ability to integrate event listeners and associated event handlers uniformly with Document Object Model (DOM) Level 2 event interfaces. The result is to provide an interoperable way of associating behaviors with document-level markup. This section gives a brief overview of the syntax defined by XML Events.
2.3.1 Introduction to DOM EventsAn event is the representation of some asynchronous occurrence, for example, a user interface event such as a mouse click or the onset of speech, or a system-generated event, for example, an alert to warn the user about invalid input. In the DOM events model, an event is said to target the element in the XML document with which it is associated. The general behavior is that, when an event occurs, it is dispatched by passing it down the document tree in a phase called capture to the element where the event occurred (called its target ). It may then be passed back up the tree again in the phase called bubbling . In general, an event can be responded to at any element in the path (by an observer ) in either phase:
We illustrate this in Figure 2.1. Figure 2.1. The DOM2 event propagation model.
An action is some way of responding to an event; a handler is some specification for such an action, for instance, using scripting or some other method. A listener is a binding of such a handler to an event targeting some element in a document. 2.3.2 XML EventsUnderstanding XML events depends on one key fact that is independent of the authoring syntax used. Creating an event listener at an element in the document tree requires three pieces of information: the element, the event to listen for, and a handler. Thus, we need to specify a triple (element, event, handler). Depending on the usage scenario, it may be convenient to do one of the following:
The XML Events specification supports all three forms of authoring, thereby creating a generic eventing syntax for use in XML languages. We illustrate these three forms of event binding in the examples shown in Figure 2.2, Figure 2.3, and Figure 2.4. Figure 2.2. Authoring event binding via element listener .
Figure 2.3. Attaching event listener on the observer .
Figure 2.4. Attaching event listener to the handler .
|