XFA Specification
Chapter 9, Automation Objects
Events
310
The first parameter in the
originalXFAVersion
processing instruction is an XFA namespace URI. When
this indicates version 2.4 or later, meaning the template started life in XFA version 2.4 or greater, the
processing instruction is ignored and the XFA 2.4 behavior is always followed. Otherwise any remaining
parameters are inspected. If there is an additional parameter with the value
LegacyEventModel:1
the
pre-2.4 behavior is followed. Otherwise the XFA 2.4 behavior is followed.
In the example the XFA schema in use by the template is 2.4 but there is an
originalXFAVersion
processing instruction, the original XFA version is 2.1, and there is a
LegacyEventModel:1
parameter so
the pre-2.4 behavior is followed.
Connection Events
Connection events trigger in response to activity in a link between the XFA processor, acting as a client,
and some external processor providing a web service. Because connection events are not directly linked to
user actions, they are triggered in both interactive and non-interactive contexts.
An script binds to a connection event by expressing a
ref
property whose value is a SOM expression
identifying the connection.
The connection events are as follows:
postExecute
This event triggers when data is sent to a web service via WSDL, just after the reply to the request
has been received and the received data is marshalled in the Connection Data DOM. A script
triggered by this event has the chance to examine and process the received data. After execution
of this event the received data is deleted.
preExecute
This event triggers when a request is sent to a web service via WSDL, just after the data has been
marshalled in the Connection Data DOM but before the request has been sent. A script triggered
by this event has the chance to examine and alter the data before the request is sent. If the script is
marked to be run only at the server, the data is sent to the server with an indication that it should
run the associated script before performing the rest of the processing.
For example, consider the following template fragment:
<subform name="root">
<subform name="sub1">
<field name="field1" … >
<event ref="$" activity="click">
<execute connection="service1" … >
</event>
</field>
<field name="field2" … >
<event ref="$" activity="click">
<execute connection="service1" … >
</event>
</field>
</subform>
<event ref="$connectionSet.service1"
activity="postExecute">
<script>… </script>
</event>
</subform>