XFA Specification
Chapter 9, Automation Objects
Validations
302
<field name="LoanAmount" y="30.00mm" x="70.00mm" w="72.00mm" h="13.7137mm">
…
<value>
<integer/>
</value>
…
<bind>
<picture>zzzzz9</picture>
</bind>
<validate formatTest="error" scriptTest="error">
<message>
<text name="formatTest">
You must enter a number between 0 and 999999.
</text>
<text name="scriptTest">
You are a security risk, so we cannot loan you more than $1000.
</text>
</message>
<picture>zzzzz9</picture>
<script>
(not SecurityRisk) | (SecurityRisk & (LoanAmount < 1000))
</script>
</validate>
</field>
<field name="SecurityRisk" y="30.00mm" x="13.49mm" w="12.44mm" h="9.26mm">
<value>
<integer>1</integer>
</value>
…
</field>
Interacting with the User to Obtain a Valid Value
Though a value just entered may be invalid, interactive processing applications are recommended
not
to
force the user to remain in the current form object until the validation constraints are satisfied. Complex
forms often contain validations that compare values across a number of form objects. Disallowing the user
from navigating out of the currently active form object may make it impossible for the user to satisfy the
validation of the current form object by altering one or more other values on the form.
The processing application may choose to prevent the form from being committed if any part of the form
is invalid. For example, a processing application may choose to prevent the submission or saving of a form
until it is considered valid.
Responding to Test Failures
This section explains how the processing application responds to errors in the validation tests applied to a
field, subform, or exclusion group. The validate element’s attributes specify how the XFA processing
application should respond in the event of an error. For example:
<validate formatTest="error">
In the case of the datatype test, the error response is implied, as described later in this section.
The following sections describe the error response levels for each type of test.