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 numberIn 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.

 

 

If you want to permit form fillers to edit field values in a format other than the default, you can specify the edit pattern on the Field tab. If the user's input does not conform to the edit pattern, the data is input as-is.

 

The edit pattern can be different from the display pattern. For example, because it is easier for users to enter short dates and read long dates, you could consider specifying a short date for a date/time field's edit pattern and a long date for its display pattern.

 

When display and edit patterns differ, the value is formatted to match the display pattern as soon as the user exits the field.

 

The edit pattern describes the syntax of the user input. Given the pattern, the runtime application converts the user input into a raw value and then formats the value according to the display pattern.

 

The next and last technique we want to present in this lesson is the validation script. If all standard features are not sufficient, you could use your own script to proof the user input. This FormCalc or JavaScript coding, of course, could proof for everything the developer wants and react on all data constellations that users might enter.

 

 

In addition to a validation pattern, or in cases where a validation pattern is not supported (for example, for radio button groups and checkboxes), you can validate user input using a validation script. Validating input through a script ensures that the data is acceptable for your application. A custom message and runtime error/warning is also supported in this case.

 

Example:

There are algorithms that will checksum a credit card number to ensure that it is a valid credit card number and not just a random 16 digit number (one example is the Luhn Algorithm 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.

 

Finally lets think about a data pattern that is not often used:

 

If bound data will be merged with a form, you can use a display pattern to specify how the data should be formatted for display. If you do not specify a display pattern, the data is displayed according to defaults. If the bound data does not match the defaults, you must specify a data pattern. The data pattern describes the syntax of the bound data. Given the pattern, the runtime application converts the retrieved data into raw values and then formats them for display.