2.3 DOM2 Events

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.

[5] http://www.w3.org/tr/DOM-Level-2-events/

[6] http://www.w3.org/tr/xml-events

2.3.1 Introduction to DOM Events

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

  • By invoking an action

  • By stopping the event

  • By canceling the default action for the event at the place it is responded to

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 Events

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

  1. Author the triple by itself (see Figure 2.2)

  2. Attach the event and handler to the element (see Figure 2.3)

  3. Attach the element and event to the handler (see Figure 2.4)

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 .
 <  listener   event  ="DOMActivate"  observer  ="button1"  handler  ="#do-it"/> 
  • Call handler identified by #do-it , and

  • Event DOMActivate occurs, and

  • Element id=button1 , and Or any of its children.

Figure 2.3. Attaching event listener on the observer .
 <  p   xmlns:ev="  http://www.w3.org/2001/xml-events"> <  a   ev:event="  click"  ev:handler="#  popper"  ev:defaultAction="  cancel"  href  ="link.html"> special link</  a  ></  p  > 
  • Catch click targeted at element a or its children,

  • Invoke action at #popper , and

  • Stop further propagation of this event.

Figure 2.4. Attaching event listener to the handler .
 <  head   xmlns:ev="  http://www.w3.org/2001/xml-events"> <  script   type  ="text/javascript"  ev:event="  xforms-submit"  ev:observer="  form1"> return do_check(); </  script  > </  head  > 
  • Declares script handler for event submit , and

  • Arrives at element id="form1" .

XForms. XML Powered Web Forms with CD
XForms. XML Powered Web Forms with CD
Year: 2003
Pages: 94

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