Working around security restrictions

Script that modifies the sourceSet model or its children makes the form's certification invalid and the form can no longer be trusted. Because a form can become certified at any time during its life cycle, it is important to use scripting techniques that prevent the form from failing after it is certified.

You must work with clones of the model rather than with the model if you intend to use scripts that modify the sourceSet model or any of its children. Cloning prevents the form from failing when scripts modify a data model. For example, forms that execute common tasks, such as displaying records in a database or selecting specific records in a database, require the modification of data connection nodes contained within the sourceSet model.

To clone the sourceSet model, you must create a method on the script that defines the data connection that you want to modify within the sourceSet model and make sure that the script keeps using the clone instead of the definition.

Consider the following script from a data drop-down list. The script populates the list from data from a from a data source.

var oDB = xfa.sourceSet.nodes.item(nIndex); 
// Search node with the class name "command" 
var nDBIndex = 0; 
while(oDB.nodes.item(nDBIndex).className != "command") 
oDB.nodes.item(nDBIndex).query.recordSet.setAttribute("stayBOF", "bofAction"); 
oDB.nodes.item(nDBIndex).query.recordSet.setAttribute("stayEOF", "eofAction");

To clone the sourceSet model, you need to change the line that accesses it by appending the clone (1) method to the end of the statement:

var oDB = xfa.sourceSet.nodes.item(nIndex).clone(1);

Note: You can store the cloned data connection node in a variable or a variable defined in a script object.

// Ethnio survey code removed