This is the first in a short series of posts to describe the new functionality found in XFA 3.0.
If you have developed a form with even modest complexity, you have almost certainly manipulated the presence property of fields, subforms and exclusion groups. With XFA 3.0 we have extended the possible values of this property to include "inactive".
The existing presence attribute can be one of these properties:
- visible - (default) Object is visible
- invisible - Object is invisible, but still participates in layout and event processing. i.e. space is allocated in the layout to display this object, its calculations and validations still fire.
- hidden - Object is invisible and excluded from layout. No space is reserved for this object. Its calculations and validations still fire.
In XFA 3.0 we now add:
- inactive - Object is hidden and excluded from event processing. Calculations, validations and other events do not fire.
Scenario
A mortgage application form is sent to a client. The form has an optional section where the user may apply for mortgage life insurance. The life insurance application section is pre-populated with client information from the server. If the user chooses not to apply for life insurance:
- the optional section will remain hidden
- The calculation and validation scripts in the optional section will not fire
- Other event scripts such as layout:ready, form:ready, prePrint, preSubmit etc. do not fire
- We do not check for mandatory fields
All these behaviours will be true as long as the subform that defines the life insurance application is set to presence="inactive".
Once the user checks the box to apply for insurance, we toggle the setting to presence="visible" and then that section of the form becomes fully functional.
Containers, Properties
The new behaviour for presence applies only to these container objects: subform, field, exclGroup. The presence attribute is also found on draw, fill, items, edge, border, caption and corner -- however in these contexts it will not introduce any new behaviour. It will behave the same as "hidden".
The Deep End
In a previous post, I described the various stages of processing we go through when we open a form:
- Loading content
- Merging data with template (create Form DOM)
- Executing calculations and validations
- Layout (pagination)
- Render
The enumeration of the presence attribute determines which of these stages a form object will participate in:
- Loading content
- Merging data with template (create Form DOM) (visible, invisible, hidden, inactive)
- Executing calculations and validations (visible, invisible, hidden)
- Layout (pagination) (visible, invisible)
- Render (visible)
I'm wondering how inactive interacts with a schema mapping. If there is data in fields in a inactive subform and those fields map to fields in the schema will the data from those fields be include in XML generated for a submission or for something like a call to saveXML() on the overall form?
Also if the user saves and then reopens such a form will the data in the fields of the inactive subform still be there?
Keith:
That's a really good question.
When designing this feature we debated whether the inactive presence ought to impact XML serialization. Initially we thought that we would exclude data bound to inactive objects from serialization. However there were two problems:
1. we realized that there were valid use cases for both behaviours. i.e. some users would want the XML excluded and some would want it included.
2. We would want presence="inactive" to impact only some serializations. e.g. exclude when submitting, but include when saving from Acrobat.
In the end we decided that presence="inactive" would have no impact on XML serialization. If it becomes apparent that we want this level of control, it would be best to introduce a new setting that controls serialization independent of the presence attribute.
John