The XML Events specification provides a clean declarative way to call out actions that should be performed under certain conditions. Under what conditions, exactly? That depends on a processing model—including the definition of what events are involved, and when they become active.
At the time of this writing, the topic of XML processing models was still under fervent discussion in various pockets of standards activity, with no obvious end in sight. Each XML specification contains details of its own self-contained processing model, but nowhere is there a description of how different specifications interact or relate to one another. XForms is no different.
An entire chapter in the XForms specification is devoted to the processing model. Much of this material, however, is mainly of interest to programmers who happen to be implementing an XForms support in some product. For form authors, a simpler view is possible.
The life-cycle of an XForms processor can be divided into several categories, which is a useful viewpoint for a form author. By scrutinizing what you want to accomplish, you can narrow down the potentially huge list of events to a more manageable list. Figure 7.3, “Stages of XForms processing” shows the stages of XForms processing.
- Initialization
Obviously, the first step is to initialize all the machinery underlying XForms. In true committee style, the initialization process was extensively discussed, the main decision point being how much stuff gets initialized before versus after the event happens. To make everybody happy, no fewer than three separate initialization events were defined, some of which fire multiple times.
- Interaction
The major portion of XForms processing involves interacting with the user, to the end of producing an XML document. During interaction, two different kinds of events are important: events that provide a notification that something happened, and events that cause something to happen. Both kinds of events are important to form authors.
- Submit
Sending the form data on its way is the goal of most forms, at least in theory. In practice, the submission attempt might not get very far, such as when the form contains invalid data. Other problems too, such as a crashed server, can prevent the submission from completing. For this reason, the submission process includes extra events that help the form author determine whether the submission was successful.
- Error Condition
Error processing is a tricky subject. In HTML forms, nearly any error is tolerated without generating error messages (but often at the expense of erratic or unpredictable behavior). In XForms, any number of problems can cause a fatal error, which will prevent a form from displaying properly.
Following the approach in Chapter 4, XML Schema in XForms, the following sections categorize events into the useful and (politely) less-useful categories. Most of these events come from the XForms specification, but a few truly useful ones come from other places. Events are one of four major types:
Another important part of the description of an event is whether it bubbles, and whether it is cancelable, in terms of XML Events. Each event description contains all of the preceding information.
The following XForms events are included here for completeness, even though they are not very useful for form authors.
Inevitably, problems can happen during form processing. XForms defines events for such situations, with each event categorized as either an error, which is recoverable, or an exception,[4] which is serious enough to immediately terminate form processing with a message.
When an error condition occurs, application-specific handling (such as logging) is always a possibility and, in fact, is a good way to investigate problems.
[4] Those with some programming background might think of an exception as something that can be "caught," in order to prevent a terminating error condition. XForms 1.0, however, doesn't provide any means to catch or re-throw an exception, so they're always fatal.