The designers of XForms put lots of thought into ways of making the design flexible enough to be customized at all the critical points. The following sections describe areas where XForms has explicitly been designed to be extended.
It’s true that XForms eliminates the need for a great deal of scripting. But not all. This is a good thing, since any system that could replace an entire scripting language (and associated libraries) would end up nearly as complicated as what it tried to replace—or worse. Instead, if a system replaces the 20% of the most commonly used functionality, it can still eliminate 80% of the need for script.
XForms doesn’t include a
element to hold any script—that’s a job for
the host language. Typically, a script will be called as a result of
XML Events processing, as described in Chapter 7.
The XML-centric design of XForms influences the way script access to data works. Since a form at all times has a well-formed bit of XML behind it, represented by an XPath data model, script authors have a natural and familiar data structure with which to manipulate the form data. Availability of DOM access isn’t a given—there’s no requirement for an implementation to be based on the DOM. In fact, of the existing XPath engines, they seem to be split fairly evenly between DOM-based and not. However, in implementations that support the DOM, a special function callable from a script returns a DOM document representing the form data, which can be ...