Chapter 9, Automation Objects
XFA Specification
Order of Precedence for Automation Objects Activated by the Same Trigger
316
soapFaultCode
The fault code returned by the SOAP operation within the
faultcode
child of the
Fault
element, as described in [SOAP1.1]. If no
Fault
element is returned this defaults to the empty
string ““. This is a secondary property.
soapFaultString
A human-readable string returned by the SOAP operation within the
faultstring
child of the
Fault
element, as described in [SOAP1.1]. If no
Fault
element is returned this defaults to the
empty string ““. This is a secondary property.
target
The object whose change of state triggered the event. This property is of type
XFANode
.
Order of Precedence When Multiple Actions Are Defined for an Event
A single event may contain any combination of the actions: script, execute, submit, and signData. When
the event is triggered, the order in which these actions are satisfied are application-dependent.
Note:
This information will be provided in a future release of this specification.
Order of Precedence for Automation Objects Activated by the
Same Trigger
One might expect that the template schema would include an element for each event, with each event
containing the script to which it is bound. In fact the schema does just the opposite. Scripts are usually
located inside the element that declares the object which being modified by the script. Each script
identifies the particular event to which it is bound by name and the object which gives rise to the event by
SOM expression. This can be thought of as a “come from” notation, in contrast to the more conventional
“go to” notation. The advantage of this inverted notation is that a complete object, including all the scripts
it requires, can simply be dropped into a template intact. The included scripts plug themselves into the
required events using the inverted notation.
One consequence of the above-described notation is that one event can be bound to any number of
scripts. Note that when a single event is bound to multiple scripts, the order of execution of the scripts is
not defined and the scripts may even run concurrently. For example, given the following template
fragment, when the form
ready
event occurs the order of execution of the two scripts is not defined.
<subform name="outer">
<subform name="sub1">
<event name="ready" ref="$form">
<script>… </script>
</event>
</subform>
<subform name="sub2">
<event name="ready" ref="$form">
<script>… </script>
</event>
</subform>
</subform>