| Section | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Required Controls and Validation
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.
...
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.
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.
...
- 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 error message will automatically clear when the form becomes valid.
Sometimes, you click the Submit button and see that the form will not submit even when all required fields appear to be filled with valid data. The cause is always a hidden required field with no data or a hidden field with invalid data. You can find troubleshooting tips to resolve the issue here.
| Note |
|---|
|
Optional Sections
Optional sections can cause the validity of a form to change dynamically. For example, consider the following form:
The Required property is selected for the Name field and all the controls inside of the Address section. The Required property is NOT selected on the Address section control making the section and the controls inside of it optional. If the user enters a valid value in the Name field then clicks Submit the form may be submitted. However, if the user chooses to enter an address, then the controls in the Address section become required as indicated by the yellow background in the City, State and Zip fields.
If the user enters a value in the Street and City fields, then clicks Submit, the Zip field is highlighted with a background color and the form will not be submitted 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.
| Warning |
|---|
Message controls can be included inside an optional section provided the Save Value property is unchecked. |
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 |
| 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 |
If a user clicks submit and any of the controls listed above fails validation, the controls will be highlighted with an orange color indicating that the form cannot be submitted. See above for other methods to notify users when forms are invalid.
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.
| Note |
|---|
|
If a user enters a value in a field that does not match the required pattern, a validation error displays when the user tabs out of the field. If the user clicks Submit without correcting the invalid data, then the field will be highlighted with a background color and submission will not be allowed. See above for other methods to notify users when forms are invalid.
Here are examples of typical scenarios where designers may want to apply patterns:
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#).
...
Troubleshooting Hidden Required Fields
Designers may come across an issue while testing their forms/flows in which the Submit or Continue buttons do not work even when all the required fields in the form are filled in. This usually happens when you have a hidden field that is required or that has invalid value. Please check if your form has any hidden fields or sections where the required property is set.
Use developer tools in your browser to find hidden controls which are invalid or required, and are causing the submit button to remain disabled.
- Open your form in Test Mode or using the Share URL. Fill it out and attempt to click Submit/Continue. If Submit/Continue remains disabled, continue to step 2.
- Open your browser developer tools. This varies by OS and browser, but on a PC you can use the keyboard shortcut Ctrl-Shift-i.
- In Elements/Inspector tab of developer tools, search for all instances of s-invalid. This will take you to the HTML of all the controls which are in invalid state.
- You can generally get the name, indicated by cname, of the control from that HTML.
Note that if a required control is inside a hidden section, then that section will also be invalid and you will see s-invalid in its HTML. You will have to continue searching further to get to the actual control. Once you locate the section(s)/control(s) that are invalid, check your business rules to see if they are being mistakenly set to required or invalid.
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.
- 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.
- The message control must contain your text in the message area and the CSS class f-submit-error specified in the CSS class property.
- 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 error message will automatically clear when the form becomes valid.
Sometimes, you click the Submit button and see that the form will not submit even when all required fields appear to be filled with valid data. The cause is always a hidden required field with no data or a hidden field with invalid data. You can find troubleshooting tips to resolve the issue here.
| Note |
|---|
|
Optional Sections
Optional sections can cause the validity of a form to change dynamically. For example, consider the following form:
The Required property is selected for the Name field and all the controls inside of the Address section. The Required property is NOT selected on the Address section control making the section and the controls inside of it optional. If the user enters a valid value in the Name field then clicks Submit the form may be submitted. However, if the user chooses to enter an address, then the controls in the Address section become required as indicated by the yellow background in the City, State and Zip fields.
If the user enters a value in the Street and City fields, then clicks Submit, the Zip field is highlighted with a background color and the form will not be submitted 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.
| Warning |
|---|
Message controls can be included inside an optional section provided the Save Value property is unchecked. |
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 |
| 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 |
If a user clicks submit and any of the controls listed above fails validation, the controls will be highlighted with an orange color indicating that the form cannot be submitted. See above for other methods to notify users when forms are invalid.
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.
| Note |
|---|
|
If a user enters a value in a field that does not match the required pattern, a validation error displays when the user tabs out of the field. If the user clicks Submit without correcting the invalid data, then the field will be highlighted with a background color and submission will not be allowed. See above for other methods to notify users when forms are invalid.
Here are examples of typical scenarios where designers may want to apply patterns:
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#).
| Code Block |
|---|
>(\d{5}(-\d{4}))|(\d{5})|([ABCEGHJKLMNPRSTVXY]{1}\d{1}[A-Z]{1} *\d{1}[A-Z]{1}\d{1}) |
...
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.
...
control by editing the ''types.xsd'' file included in the <frevvo home>/tomcat/webapps/frevvo 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.
| Code Block |
|---|
<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 base="xsd:string"> </xsd:restriction> <xsd:pattern value="[a-zA-Z0-9\-_]</xsd:simpleType> |
You can also create a custom email pattern on Text control. This would be useful to ensure users only enter their work or school email, for example. Drag a text control from the palette and set the pattern as follows, replacing "@domain.com" with your domain.
| Code Block |
|---|
[a-zA-Z0-9\-\+_]*(\.[a-zA-Z0-9\-\+_]+)*@([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,6}"/> </xsd:restriction> </xsd:simpleType>\.[a-zA-Z0-9\-\+_]+)*@domain.com |
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.
...
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.
| Tip |
|---|
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
...
- 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.
...
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.
| Tip |
|---|
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
...
Modify the types.xsd file
frevvo OEM partners may choose this method when customizing . The built-in values are shown in the image below:
...
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 Open <frevvo home>/tomcat/webapps/frevvo file and copy the WEB-INF\data\users\types.xsd 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.xsd,
- Change the element phoneType as shown in the code block below: Save the changes to the types.xsd file.
Replace the original file with the updated version.
- Restart your form server. Now all your phone controls will validate against this pattern.
| Code Block |
|---|
<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> |
...