Livecycle

When to use patterns

Use patterns to control how field values are processed at run time. For example, users can enter letters and numbers into a text field and any special punctuation or spacing can be applied automatically according to a predefined pattern before the value is displayed.

Capturing and displaying user input

If you are creating a form to capture data, you can specify how data should be formatted. You specify how the data should appear using a display pattern. If you do not specify a display pattern, the data appears according to LiveCycle Designer ES defaults.

If users will be entering data that does not match the LiveCycle Designer ES defaults, you must specify an edit pattern. The edit pattern describes the syntax of the user input. Given the pattern, the run-time application converts the user input into a raw value and then formats the value according to the display pattern.

If you are designing an interactive form, consider what user input must be validated. For example, a text field may or may not require validation depending on usage. A multiple line text field allowing the form filler to enter a comment does not need to be validated. Similarly, a numeric field will automatically prevent the form-filler from entering any non-numeric data. However, if the data has to be restricted to a specific range of numbers, you will want to validate the user input. You can choose to display a custom message to prompt users for a correct value at run time. If you do not specify a custom message, the system generates one automatically.

Note:

User input can be processed through FormCalc formulas and JavaScript scripts (for example, a script can request the raw value of a field). Because formulas and scripts operate on raw and formatted values, it is important to validate those fields where input is restricted.

One example of how an edit and validation pattern may be used together is a credit card or social security number entry. You could define a text field with the following edit patterns:

text{9999-9999-9999-9999}|text{9999 9999 9999 9999} for credit cards

or

text{999-99-9999}|text{999 99 9999} for a US social security number

In both cases, the user may enter the number with hyphen(-), space ( ), or just the 16 or 9 digit number. The canonical, or simplest form of the number is the 16 or 9 digit number.

You may also choose to add the following validation pattern:

text{9999999999999999}

or

text{999999999}

In this case, only the number is stored and the validation checks for the correct number of digits. However, in this case, it might be more useful to specify a validation script rather than a pattern. There are algorithms that will checksum a credit card number to ensure that it looks like a valid credit card number and not just a random 16 digit number. An example is the Luhn Algorith for credit cards.

The result is a form that has a text field where the edit pattern allows user entry in one of three typical ways for typing a credit number, and the validation runs a script that validates that the number looks like a valid credit card number.

Retrieving and displaying bound data

If bound data will be merged with a form, you can specify how the data should be formatted for display using a display pattern. If you do not specify a display pattern, the data is displayed according to LiveCycle Designer ES defaults.

If the bound data does not match LiveCycle Designer ES defaults, you must specify a data pattern. The data pattern describes the syntax of the bound data. Given the pattern, the run-time application converts the retrieved data into raw values and then formats them for display.

See also 

About field patterns and value formatting

Defaults for value formatting

When to use patterns