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). Validation for controls you generate from schema elements depends on the element’s XSD type and other schema-specific information.

On form load, required controls that do not contain valid 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 Image Removed warning icon when a control (either required or not) contains an invalid value.

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

Image Removed

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

Image Removed

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 phone control and clicks the Submit button the form will be submitted.

Image Removed

Note that the Email Address and Phone controls are optional. The form may be submitted even though there are no values in these controls. However, if the user enters an invalid value in one of the fields (required or not), will prevent form submission.

Image Removed

When a form has sections or tabs, the submission may not be allowed 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.

Image Removed

Invalid Form Notification for Users

Consider the scenario where there are several required fields in a form and the user clicks the submit button having missed a few of them.  will not allow the form to be submitted due to the empty required fields. The user must provide the information for these fields but it is not immediately obvious what data is missing. The user is forced to scroll up the form to find the errors.

provides a method to show validation errors at the time of submission. Here's how it works:

• The Submit button is never dimmed.
• If you click Submit and the form is invalid (cannot be submitted) all invalid control fields are highlighted with a background color. The color shown in the image is the default. The designer can specify this color by changing the value for (Submit Error Highlight) in a Style and then applying that style to the form.

Image Removed

...

 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). Validation for controls you generate from schema elements depends on the element’s XSD type and other schema-specific information.

On form load, required controls that do not contain valid 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 Image Added warning icon when a control (either required or not) contains an invalid value.

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

Image Added

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

Image Added

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 phone control and clicks the Submit button the form will be submitted.

Image Added

Note that the Email Address and Phone controls are optional. The form may be submitted even though there are no values in these controls. However, if the user enters an invalid value in one of the fields (required or not), will prevent form submission.

Image Added

When a form has sections or tabs, the submission may not be allowed 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.

Image Added

Invalid Form Notification for Users

Consider the scenario where there are several required fields in a form and the user clicks the submit button having missed a few of them.  will not allow the form to be submitted due to the empty required fields. The user must provide the information for these fields but it is not immediately obvious what data is missing. The user is forced to scroll up the form to find the errors.

provides a method to show validation errors at the time of submission. Here's how it works:

• The Submit button is never dimmed.
• If you click Submit and the form is invalid (cannot be submitted) all invalid control fields are highlighted with a background color. The color shown in the image is the default. The designer can specify this color by changing the value for (Submit Error Highlight) in a Style and then applying that style to the form.

Image Added

• Once the required fields have been filled and/or invalid data has been corrected, the highlight color will disappear and the form can be submitted by clicking the Submit button.
• The designer can add a message control(s) to the form with a customized message to alert the user that the form cannot be submitted and what they need to do to correct it.
  • The message control must contain your text in the message area and the CSS class f-submit-error specified in the CSS class property.
    
  • A message control with this CSS class is invisible by default. When the error condition is met, these message controls become visible.
  • You can use select a Message Type and use all the properties on the Style tab to style your message.

...

<xsd:simpleType name="emailType">       
          <xsd:restriction base="xsd:string" 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: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.  The built-in values are shown in the image below:

Image Removed

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:

1. Stop  if it is running. 
2. Unpack the frevvo.war file to a temporary location of your choice: e.g. c:\tmp\frevvo-war.
3. Edit c:\tmp\frevvo-war\WEB-INF\data\users\types.xsd,
4. Change the element phoneType as shown in the code block below: Save the changes to the types.xsd file. 

5. Rezip all the files in the c:\tmp\frevvo-war directory, even the ones you did not edit.

6. Zip will often give your zipfile a .zip extension. Make sure you change this to a .war extension. 

7. Copy the updated frevvo.war file to <frevvo installdir>/tomcat/webapps.
8. 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>

If you are using  Online, you will not have access to types.xsd. You 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.

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

...

</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

1. Apply patterns to a control - Like other control properties, the pattern property will not need to be redone when you upgrade .
2. 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.

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

1. Drag a Text control to your form
2. Add your pattern to the Text control's pattern property: \d{2}-\d{4}-\d{4} or \d{4}-\d{3}-\d{3}
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:

Image Added

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:

1. Stop  if it is running. 
2. Unpack the frevvo.war file to a temporary location of your choice: e.g. c:\tmp\frevvo-war.
3. Edit c:\tmp\frevvo-war\WEB-INF\data\users\types.xsd,
4. Change the element phoneType as shown in the code block below: Save the changes to the types.xsd file. 

5. Rezip all the files in the c:\tmp\frevvo-war directory, even the ones you did not edit.

6. Zip will often give your zipfile a .zip extension. Make sure you change this to a .war extension. 

7. Copy the updated frevvo.war file to <frevvo installdir>/tomcat/webapps.
8. 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>