Rules-Based Validation

InfoPath 2003 allows the form developer to define rules relating to allowed values for form controls. Many of the rules that the InfoPath user interface allows the form designer to create could be created in scripting code, but it is often much easier to create them using the InfoPath user interface.

Let's create a simplified form template, RulesExample.xsn , which can be used for collecting some human resources data. Figure 10.11 shows the form template in design mode. A custom layout table is used to lay out the form controls and their labels.

Figure 10.11. The RulesExample.xsn form template in design mode.

Giving Fields Informative Names

As you can see from Figure 10.11, the fields in the data source are not informative at present. We can rename the fields to be more meaningful:

1. Right-click on the field1 field in the Data Source task pane and select Properties from the context menu. The Field or Group Properties window opens (see Figure 10.12).

   Figure 10.12. The Field or Group Properties window.

   

2. Edit the content of the Name text box for each field so that the data source task pane becomes more meaningful (see Figure 10.13).

   Figure 10.13. Meaningful field names in the Data Source task pane.

   

Renaming fields to create meaningful names is useful when we create rules because the field names are, as you will shortly see, used in the creation of the rules.

Writing Rules to Prevent Blank Fields

Let's create simple rules for the FirstName and LastName fields to specify that they cannot be blank. There are two ways to do this. For the first name, we will use the Cannot Be Blank check box on the Data tab of the Text Box Properties window (shown earlier in Figure 10.9). Right-click on the text box and choose Text Box Properties to access the Text Box Properties window.

For the last name, we will use a user interface rule to achieve the same effect:

1. Right-click on the Last Name text box, and select Text Box Properties.

2. On the Text Box Properties window, click the Data Validation button. The Data Validation (LastName) window opens.

3. To create a validation rule, click the Add button. Another, different Data Validation (LastName) window opens. In Figure 10.14, you can see the interface that we use to create validation rules.

   Figure 10.14. The second Data Validation (LastName) window.

   

4. The left drop-down contains a list of the names of fields used in the form template, plus an option to create an XPath expression. Choose LastName.

5. In the middle drop-down menu, select the Is Blank option (see Figure 10.15). If that condition is not satisfied, the error message that we will shortly create is displayed.

   Figure 10.15. Specifying that the LastName field is invalid when it is blank.

   

6. Specify how the alert about any error is displayed by using the Error Alert Type drop-down menu (see Figure 10.16). The default option, Inline Alert (ScreenTip, and Message If Requested) is used with the Cannot Be Blank check box that we used for the FirstName field. For the LastName field, use the alternate option, Dialog Box Alert (Immediately Show Message).

   Figure 10.16. Selecting how the error alert is to be displayed.

   

7. Add a custom ScreenTip and message (see Figure 10.17).

   Figure 10.17. Creating a custom ScreenTip and message.

   

8. For this part of the example, we don't need to use the right drop-down menu in the Data Validation (LastName) dialog box. Click OK to close the dialog.

Let's test whether we have created the rules correctly. When we open the form in preview mode, both the First Name and Last Name text boxes are underlined in red, because both are (not surprisingly) empty, and therefore not valid. To trigger the error message for the Last Name text box, we need to enter some text, tab out of the text box, return to the Last Name text box, delete the text, and then exit the box again. The error message is displayed.

Specifying Possible Field Values

Now let's move on to the Department text box. Let's specify that the department can be either Development or Marketing:

1. Right-click the Department text box. Select Text Box Properties.

2. In the resulting dialog box, click the Data Validation button to open the Data Validation (Department) window.

3. Click Add. The second Data Validation (Department) window opens (see Figure 10.18) with default values displayed.

   Figure 10.18. Ready to create rules for the Department text box.

   

4. Leave the left drop-down menu at its default value, Department, and change the middle drop-down menu from its default value (Is Equal To) to Is Not Equal To. In the right drop-down menu, select Type Text and then type Development in the text box (see Figure 10.19).

   Figure 10.19. The first rule for Department created.

   

5. We have now created a validation rule that currently specifies that Department must have the value Development . However, we want that to be one of two options. Click the And button to the right of the three drop-down menus and a new set of drop-down menus appears (see Figure 10.20), allowing us to create another validation rule.

   Figure 10.20. A new row of drop-down menus appears.

   

   SHOP TALK
   EASY TO INVERT LOGIC IN RULES

   I often find that I enter (at least, the first time around) the reverse of the logic that I intend to specify. For example, to specify that Department is only allowed to be equal to Development , remember to specify Is Not Equal To because that specifies when the data is not valid.

   Remember that when you create validation rules, you are specifying the conditions when the data is not validwhich naturally are the opposite of the conditions that describe valid data. Therefore, I find it useful to test rule-based validation in preview mode immediately after I create the rule(s), so I can catch those inversion-of-logic errors.

   Another potentially more subtle problem to watch out for can occur when you use an XPath expression in a validation rule. If you make an error in defining the expression and it never selects the node you intended, the validation rule will not be applied as you intended and likely will never be applied. Users will then be able to enter incorrect data. Again, I strongly recommend testing validation rules that use XPath expressions in preview mode as soon as you have finished creating the rule(s).

   
   

6. Notice that an And drop-down menu now appears to the right of the three original drop-down menus. Click it and ensure that the And option is selected, because we want to also allow the Department to have the value of Marketing .

7. Create a second rule that specifies that the Department field can also take the value Marketing (see Figure 10.21).

   Figure 10.21. A pair of validation rules.

   

8. Add a screen tip and a message (see Figure 10.22). Close the various dialog boxes.

   Figure 10.22. The two rules, complete with screen tip and message.

   

Click the Preview Form button. If the value in the Department text box is not either of the allowed values, an error message is displayed in a dialog box.

Specifying Rules for Date Fields

Now let's move on to create validation rules for the two date picker form controls for the StartDate and EndDate fields:

1. Right-click in the date picker for the StartDate field and choose the Date Picker Properties option.

2. This field cannot be blank (all employees must have a start date), so we check the Cannot Be Blank check box in the Data tab of the Date Picker Properties window.

3. Click the Data Validation button. On the next window, click the Add button.

4. StartDate is selected by default in the left drop-down menu. In the middle drop-down menu, select the Is Less Than option. In the right drop-down menu, select Type a Date and then type 01/01/2000 in the resulting text box (we are assuming that the company was created on January 1, 2000 so no employee can have a start date earlier than that).

5. Add a screen tip and a message (see Figure 10.23).

   Figure 10.23. The validation rule specifying that StartDate cannot be earlier than January 1, 2000.

   

6. To specify a rule for the EndDate field, right-click in the date picker, and choose the Date Picker Properties option.

7. On the Data tab, leave the Cannot Be Blank check box unchecked, because not all staff must have an end date (current staff obviously don't). Click the Data Validation button. Click the Add button.

8. We want to specify that the EndDate cannot be earlier than the StartDate field (which makes sense if we assume that a member of staff is employed only once). If we create that rule, we won't need to create a rule about January 1, 2000 because any valid start date already satisfies that rule. On the right drop-down menu, select a Field or Group. In the resulting Select a Field or Group window, select the StartDate field (see Figure 10.24).

   Figure 10.24. Selecting the StartDate field.

   

9. Click the OK button. Add a screen tip and a message. Click OK three times.

Click the Preview Form button. If you attempt to enter a start date before January 1, 2000, the date picker control is outlined in a dashed red line; and when you hover the mouse pointer over it, the date picker displays the screen tip we created (see Figure 10.25).

Figure 10.25. An invalid date entered for the StartDate field.

Similarly, with a valid date in the StartDate field, if we add an EndDate before the StartDate , the EndDate date picker is outlined in dashed red and the screen tip is displayed when the mouse pointer hovers over the date picker.

Other Rule Options

There are many more options for creating rules. The fields you can use in the left drop-down menu in the Data Validation dialog depend on the fields in the data source. The options in the middle drop-down menu are standard (refer back to Figure 10.15).

The options available in the right drop-down menu are determined by the data type of the corresponding field in the data source. Typically, that will also appear to correspond to the type of form control, such as a date picker, and will have only a date displayed in the right drop-down menu.

As you saw in the EndDate example, you can use a field in the data source when creating rules. When that functionality is combined with the capability to combine rules using AND or OR logic, you can see that InfoPath provides a highly flexible and powerful spectrum of rules for use in InfoPath form templates.

SHOP TALK
DOCUMENT VALIDATION CHOICES

When you are creating complex form templates, you need to take care how and where you create validation rules to be sure that you don't introduce some subtleor not so subtleinconsistency. Not only are there three potentially interacting types of validation within InfoPath 2003, but you likely also have validation rules in, for example, the Access database to which you might be connecting.

I haven't yet worked out a method of documenting InfoPath 2003 forms in a way that completely satisfies me. However you choose to document your InfoPath form templates, I suggest you pay particular attention to documenting the question of validation. If you come back in, say, six months' time to modify a form template, having decent documentation that specifies which of the available validation techniques you have used and the ways you used each technique will save you, or whoever works with your form templates later, from scrabbling around between a W3C XML Schema document, InfoPath user interface validation, and script-based validation. I assure you that you will be glad you took the time to adequately document how the form template works.