Livecycle

Considerations for testing form designs with data

When setting up forms to support merged data, you need to analyze the data-merging requirements of the form against the input data. The form design should be created based on the structure of the input data.

It is recommended that you review the input data and consider preparing a sample data file, or have LiveCycle Designer ES automatically generate a sample data file for testing purposes.

Sample data may be used to determine the behavior of a form and should not be considered a replacement for thorough testing. To obtain the best results, the form design should be tested with system-generated data. You can generate the sample data as suggested in the following list to determine whether the layout, formatting, content, and behavior of a form responds as expected:

•	To verify whether data formatting (for example, font type, font size, and paragraph alignment) is correct, generate data for every field in the form. The data will also let you verify any calculated field values.

•	To verify whether field objects are large enough to accommodate all data values, generate data to reach the maximum number of characters permitted per field.

•	To verify the operation of multiple-line and expand-to-fit settings, generate multiple lines of data.

•	If your form design contains repeating subforms, you can generate repeating data groups to test the rendering of those subforms in the sample data file that you create. If you are using an automatically generated sample data file, you can specify the number of times you want a data group to repeat.

•

If your form design contains overflow leaders or trailers, generate the data necessary to test every overflow leader or trailer and their occurrence settings. You should generate enough repeating data groups to flow over three pages, which will also let you verify page numbering. Use the sample data (add one repeating data group at a time) to verify how a repeating subform looks when it flows onto a new page.

•	To test the data pattern setting for bound data, ensure that all data values are in the same format generated by the system, especially if the syntax of the source data does not match LiveCycle Designer ES defaults.

•	Generate enough data to employ the layout of every master page in the rendered form.

Caution:

Ensure that the form data does not contain hexadecimal values between 0×00 and 0×20, except for carriage return, line feed, and horizontal tab. These values are invalid XML characters that LiveCycle Forms ES does not recognize.

Creating a sample data file

The following guidelines will help you to create a simple test file that contains representative input data:

•	The input data file must be a valid XML file. For example, a flat file would have elements of this format:

<root_node>

<first_node>value</first_node>

<second_node>value</second_node>

…

<last_node>value</last_node>

</root_node>

•	Compare the flow of the input data to the physical layout of the form. If you are using implicit binding, the names of the data nodes must match the corresponding containers and fields in the form and be presented in the same order as the fill order in the form.

•	If the input data file has more levels of nesting compared to the items in the Hierarchy palette, data bindings for all of the nested objects must be set explicitly through the Binding tab in the Object palette.

•	In the input data file, look for data that is repeated but not part of every record. This information could possibly be handled on master pages as boilerplate objects or in subforms that repeat the data for unique records only.

See also 

Working with data sources

About form designs

Form design layouts

To preview and test forms in the Preview PDF tab

Previewing an HTML form

Considerations for testing form designs with data