One of ' most powerful and useful features is its ability to automatically ensure that any submitted form generates a set of XML documents that are valid with respect to their corresponding XML schemas. The application does this by:

always generating valid XML instance documents and
disabling the submit button for a form which is invalid.

On this page:

controls may be marked as required or optional by setting the control's required property in edit mode. Controls that are generated from an uploaded schema will automatically be designated as required or optional depending on the schema (for example, whether the control is required based on the minOccurs value).

When a form is initially created, will automatically disable the Submit button if there are any required controls that do not contain valid values. Validation for controls you generate from schema elements depends on the element’s XSD type and other schema-specific information.

Any controls with invalid values have a visual indicator. For example, an invalid control has a yellowish background when a required field is missing a value, and additionally, a warning icon when a control (either required or not) contains an invalid value.

Here is a form that is missing values in required fields.

Here is the form when the user has entered valid values into the required fields.

And another that has a value in the field but the value is invalid for the given field type. Notice the error message, yellow background and the warning icon.

When the user enters a valid value in the control, the submit button will automatically get enabled. Until that point the submit button remains disabled. This automatically ensures that it is not possible to submit a form with an invalid value.

Note that controls that are optional do not cause the submit button to be disabled unless the value entered is invalid. As the figure above shows, there are no values in the optional Email Address and Phone fields but the form may be submitted. However, if the user enters an invalid value in one of the fields (required or not), the submit button will again be disabled by .

And here is a form missing values in required fields. Therefore again the submit button in disabled.

When a form has sections or tabs, the submit button may be disabled due to invalid controls that are not currently visible. For example, a section that is collapsed or a tab that is not currently selected may have an invalid control. This is indicated in the header section and tab label color changing to red.

Optional Sections

Optional sections can cause the validity of a form to change dynamically. For example, consider the following form:

The only required field in the form is Name and since it contains a valid value, the Submit button is enabled and the form may be submitted. The entire Address section is optional. However, if the user chooses to enter an address, then the entire address is required as indicated by the yellow background when the user tabs to the City field. If the user enters a value in the Street field, the City, State and Zip fields will become invalid and the Submit button will be disabled until valid values are entered in the three newly required fields.

If the user changes his/her mind and removes the value from the Street field, will recalculate the validity of the form and infer that the Address section is no longer invalid since it is optional. The generated XML instance document will also not contain an address element. Once again, is automatically ensuring that it is not possible to submit a form that is in an invalid state and that would generate an invalid document.

You can find information about the section Required property here.

Avoid using message, image and video controls inside a section that contains other controls that you may want to set to required/not required (either via the Forms Designer or using Business Rules. Since these three control types always contains a value, it can cause a section, or other controls in a section, to become required. If you must include a these control types, place it outside the section. Another alternative is to write rules for the individual controls within a section to set them to visibile/invisibile or required/not required.

Input Validation

Form fields added from ' control palette have built-in validation rules. The table below details the default validation for each control type in ' palette. Patterns added to a control change the defaults.

Control Type	Default Validation Rule
Text	xsd:string
Text Area	xsd:string
Date	xsd:date
Email	xsd:string with pattern [a-zA-Z0-9\-_][a-zA-Z0-9\-\+_](\.[a-zA-Z0-9\-\+_]+)@([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,6}
Money	xsd:double
Phone	xxxxxxxxxx, xxx-yyy, xxx.yyyy, xxx-yyyyzzzz, xxx.yyy.zzzz,
Time	xsd:time
Quantity	xsd:decimal with pattern [\-+]?[0-9]+
Number	xsd:double
T/F	xsd:boolean

Patterns

Patterns imposes additional validation on what users enter in a particular control. See Designing Forms with Patterns for information on setting a pattern on any control in your form. Patterns are XML schema regular expressions.

DO NOT use the typical leading ^ and trailing $ characters in your patterns. These two characters represent the beginning and end of line markers and do not apply to form field values.

It is important to use a text control for most patterns. For example a zip code requires a '-' character. If a '-' is used in a quanty control the pattern will fail, as a quantity control does not allow non-numeric characters.

US Zip Code Pattern

A pattern that restricts a text control to only allow strings formatted as a US zip code: ##### or #####-####:

\d{5}|\d{5}-\d{4}

The form will flag an error unless the value entered is either five digits or five digits followed by the '-' character followed by 4 digits.

US/Canada Zip/Postal Code Pattern

This pattern validates US zip codes (##### or #####-####) and Canadian postal codes (L#L #L#).

>(\d{5}(-\d{4}))|(\d{5})|([ABCEGHJKLMNPRSTVXY]{1}\d{1}[A-Z]{1} *\d{1}[A-Z]{1}\d{1})

SSN

This pattern ensures that the user enters a valid Social Security Number:

\d{3}-\d{2}-\d{4}

Money

You should not try to apply a pattern to a money control. If you need to apply special behavior to a money control (for example, using three decimal places), we recommend using a text field, which affords a wider range of patterns you can apply. You could also use a number field and apply rules to it — such as rounding up to three decimal places.

Number Range

Patterns for number ranges are not as straight forward as you might imagine. If you want a quantity control to allow only numbers in the range 1-42 it is not sufficient to use the pattern [1-42]. Here is the pattern that will work:

([1-9]|[1-3][0-9]|4[0-2])

Numbers with commas

' default number control supports digits followed by an optional decimal point and multiple decimal places. Suppose instead you want to allow numbers containing commas and optionally starting with a '$' and only up to 2 decimal places. For example: $1,000.50 or 2,500. But also to allow numbers without the comma such as $1000. To do this:

Add a text control to your form
Set the pattern to: \$?([0-9]{1,3},([0-9]{3},)*[0-9]{3}|[0-9]+)(\.[0-9][0-9])?

If you do not want to allow the optional '$' then:

Set the pattern to: ([0-9]{1,3},([0-9]{3},)*[0-9]{3}|[0-9]+)(\.[0-9][0-9])?

EMail pattern

If you use In-house (downloaded and installed on your computer), you can change ' built-in patterns for the Email control by editing the ''types.xsd'' file included in the <frevvo installdir>/tomcat/webapps/frevvo.war file. This file includes the email type definition shown below, and you can edit its pattern value. See the example in the phone pattern section below for instructions to modify the types.xsd file.

<xsd:simpleType name="emailType">       
          <xsd:restriction base="xsd:string">        
                  <xsd:pattern value="[a-zA-Z0-9\-_][a-zA-Z0-9\-\+_]*(\.[a-zA-Z0-9\-\+_]+)*@([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,6}"/>         
          </xsd:restriction>    
</xsd:simpleType>

Phone pattern

Lets say you would like to change the phone control validation from the ' current built-in pattern. Cloud customers must apply Patterns to a text control while in-house customers have two options

Apply patterns to a control - Like other control properties, the pattern property will not need to be redone when you upgrade .
Modify the built-in values in the types.xsd file. Be aware that if you modify the types.xsd file, you will have to make this change each time you perform a upgrade or apply a patch.

Apply a Pattern to a Control for a Phone Number

If you are using Online, you will not have access to types.xsd. Both cloud and in-house customers, can override the pattern in the phone control by setting its pattern property. You can only restrict a built-in pattern (such as the phone control) but not change the pattern via the pattern property. For example you can add the pattern 203-\d{3}-\d{4}. Now all phone numbers must start with area code 203.

The Pattern property will not need to be redone when you upgrade .

A pattern such as ##-####-#### or ####-###-### is not a simple restriction. To impose validation against this pattern you must start with a Text control rather than a Phone control

Drag a Text control to your form
Add your pattern to the Text control's pattern property: \d{2}-\d{4}-\d{4} or \d{4}-\d{3}-\d{3}
Change the error message and help properties to assist the user in understanding the required pattern

Modify the types.xsd file

frevvo OEM partners may choose this method when customizing . The built-in values are shown in the image below:

Follow these steps to change the current buit-in pattern to ##-####-#### or ####-###-###.

If you are using In-house (downloaded and installed on your computer), you can change ' built-in patterns for the Phone control by:

Stop if it is running.
Unpack the frevvo.war file to a temporary location of your choice: e.g. c:\tmp\frevvo-war.
Edit c:\tmp\frevvo-war\WEB-INF\data\users\types.xsd,
Change the element phoneType as shown in the code block below: Save the changes to the types.xsd file.
Rezip all the files in the c:\tmp\frevvo-war directory, even the ones you did not edit.
Zip will often give your zipfile a .zip extension. Make sure you change this to a .war extension.
Copy the updated frevvo.war file to <frevvo installdir>/tomcat/webapps.
Restart your form server. Now all your phone controls will validate against this pattern.

<xsd:simpleType name="phoneType">     
    <xsd:restriction base="xsd:string">         
        <xsd:pattern value="\d{2}-\d{4}-\d{4}"/>         
        <xsd:pattern value="\d{4}-\d{3}-\d{3}"/>
    </xsd:restriction> 
</xsd:simpleType>

Browser not supported