Chapter 4, Exchanging Data Between an External Application
and a Basic XFA Form
XFA Specification
Basic Data Binding to Produce the XFA Form DOM
162
4. Re-normalize (adjust the Data DOM to mirror the Form DOM) (“Re-Normalization
5. Perform calculations and validations (“Calculations
6. Issue the form ready event (“Form
7. If scripts modify the Data DOM after the Form DOM has been created, it may be necessary to wholly or
partially repeat the data binding process (“Remerge
The following subsections expand on some of the steps above.
Create Form Nodes and Match with Data Nodes (Steps 1 and 2)
Continuing the example from the previous section, Step 1in the data-binding process is simple. Each node
in the Template DOM is copied into the Form DOM. Some nodes are not merge-able; for example, draws
can not match up with user data, nor do they contain other elements that can, so they are not merge-able.
As each node is copied into the Form DOM, if it is merge-able, it is matched with the same-named data
element. (Only merge-able nodes have been shown in the accompanying illustrations.) These are so-called
direct matches
in which, not only do the node names match, but the names of all their merge-able
ancestors match in sequence. This corresponds to the logic of SOM expressions; if a data node and a form
node directly match, they are both named by the same SOM expression relative to the current record and
the top-level subform, respectively. For example, the
city
field in the Template DOM could be expressed
by the SOM expression
"registration.city"
, relative to the root of the Template DOM. At the same
time the
city
dataValue in the Data DOM could be expressed by the SOM expression
"registration.city"
, relative to the root of the Data DOM. Hence the two nodes match and the data
binding process binds them together.
It is important to note that for a data node and a form node to bind together they must be compatible
types. A subform can bind to a data group but not a data value. A field can bind to a data value but not a
data group.
The highest-level subform and the data node representing the current record are special; they are always
bound even if their names don't match. In fact it is common for the highest-level subform in a template to
be unnamed, that is to not have a
name
attribute. In the example assume that the data holds just one
record (the
registration
data group and its content). This is a common arrangement. In this case, the
registration
data node is the one representing the current record.
If the data was missing some elements, all fields would still be placed into the Form DOM but some field
nodes would remain unbound. This corresponds to a paper form that has not been completely filled in.
However the template may specify a default values for any field, thereby forcing the field to be initialized
with the default value whenever the data does not fill it. Furthermore if a data description is present it may
force additional structure to be included. However for this example assume that the data description is
not supplied or simply mirrors the structure of the example data.
If the data had extra elements whose names differed from anything in the template, those extra data
nodes would simply be left unbound. This is true regardless of the contents of the data description. The
resulting Form DOM would in effect represent a subset of the data. Applications can therefore use multiple
templates with different template objects to present different views of the same data. In addition many
types of template nodes have a
relevant
property which gives a different kind of control. The
relevant
property affects what portions of the template are loaded into the Template DOM by particular
applications. For example, a particular element might be marked relevant only to printing. An interactive