When creating a form that uses XForms, you can improve the performance of your form by using XForms binds to make calculations instead of XFDL computes.
XForms binds have a number of properties that you can set to modify nodes. These properties often correlate to computes that can be set on XFDL options. The XForms properties and the XFDL computes offer the same functionality, but the binds run faster than computes.
If you are creating an XForms form, you can use binds to set the following properties:
Applies a calculation that sets the content of a node. This calculation is written as an XPath expression that is evaluated relative to a node in the bind's nodeset.
For example, if you had a purchase order form, you might use the following expression to set the value of the "total" node to equal the value of the "subtotal" node plus the value of the "tax" node:
calculate="../subtotal + ../tax"
Do not link a data node with a calculation to a UI element that has a value set by a an XFDL compute. When the XForms UI binding transfers data to the UI element, the XFDL compute is destroyed.
Allows you to set a constraint for a node. For example, you could specify that the value of the node must be greater than one, or that it must not equal the value of a different node.
This property is set by any XPath expression that results in a boolean value. True means the constraint has been met, false means it has not.
For example, the following expression would ensure that the value for the upperPage node was always greater than or equal to the value of the lowerPage node:
constraint=". >= ../lowerPage"
If a constraint is set for a data node, and a different constraint is set for a linked UI element, then the validity of the data is determined by considering both settings. If the data is invalid for either setting, the data will be considered invalid overall.
If a node is relevant (see below) and has a failed constraint, then an XForms submission is not permitted.
sets whether the associated node is readonly. If a UI element is linked to a readonly node, then the UI element will also be readonly. However, if the UI element has the readonly option set, it will override the setting for the data node.
This property is set by any XPath expression that results in a boolean value. True means the node is readonly, false means the node is not.
For example, the following expression would make the associated node readonly:
Determines whether a node is relevant. Non-relevant nodes are omitted from XForms submissions. Additionally, if a UI element is linked to a non-relevant node, then that UI element is not displayed to the user. However, if the UI element has either the active or visible options set, they will override the setting for the data node.
This property is set by any XPath expression that results in a boolean value. True means the node is relevant, false means the node is not.
For example, the following expression would make the node relevant if another node named “paymentType” had a value of “credit”:
relevant="../paymentType = 'credit'"
Sets whether the node requires input. If a UI element is linked to a required node, then the UI element inherits the setting. Furthermore, if the node does not require input, but a linked UI element does, then input is still required.
This property is set by any XPath expression that results in a boolean value. True means the node is required, false means the node is not.
For example, the following expression would set the node to require input:
If a relevant (see above) data node is required but empty, then an XForms submission in not permitted.
Sets the data type of the node. The valid data types are defined by XML schema.
For example, the following expression sets the node to a date type:
If the data type set for the node conflicts with the data type set for a linked UI element, then the validity of the data is determined by considering both settings. If the data is invalid for either setting, the data will be considered invalid overall.
For example, if you set a data node to be type int and you set a linked XFDL field to be type string, then typing in "abc" (a valid XFDL string) would still result in an error, since it does not match the int type.
If a relevant (see above) data node's content does not match its type, then an XForms submission is not permitted.
The following code samples both multiply the value of the "total_days" field by the "cost" field and place the total cost in the "total_cost" field. The "total_cost" field is invisible until the "equip_returned" checkbox is selected.
Figure 1. Bind that calculates the total cost of equipment rental and determines whether the "total_cost" field is displayed.
<xforms:bind calculate="../total_days * ../cost" nodeset="customer
/rented_machines/total_cost" relevant="../equip_returned != ''</xforms:bind>
Figure 2. Computes that calculate the total cost of equipment rental and determine whether the “total_cost” field is displayed.
<value compute="PAGE1.total_days.value * PAGE1.cost.value"></value>
<visible compute="equip_returned.value == 'on' ? ('on') : 'off'">on</visible>
Exceptions to this practice
XForms binds cannot change the visual aspects of a form directly. To make a calculation that affects the presentation of a form item, such as the font color or background color of the item, use an XFDL compute.
For example, if you want an entry field to turn red to indicate a negative account balance, use the following XFDL compute to make the field display a red background color whenever the field contains a negative number value:
In this case, the field displays a white background color because it contains a value of 1. If the value had been -1 instead, then the field would display a red background color.
Back to: Performance best practices