InfoPath s Three Validation Tools

 <  Day Day Up  >  

InfoPath's Three Validation Tools

Validation of form data is a basic need, whatever the form tool used. If the server-side processes are presented with unexpected data structures from a form, errors or other undesired effects (such as dropped or incorrect data) sometimes result. As the processing of data becomes increasingly detached from human appraisal, any errors or omissions need to be picked up automatically. Therefore, any forms-based application needs to ensure that submitted data conforms to a structure defined in a reliable way.

In traditional HTML/XHTML forms, validation of form data is typically done on both the client side and the server side. On the client side, custom JavaScript code is a typical tool. On the server side, a variety of languages, including Perl and JavaScript, can be used.

InfoPath 2003 needs to accommodate the validation needs of many business and workflow scenarios. The W3C XML Schema approach defines the structure of data and the allowed data types, but it lacks rule-based validation. For example, there is no way in W3C XML Schema to express the notion that the shipping date must be later than the order date. To provide rules like this, you can use custom VBScript or JScript code; or, if suitable logic is provided, use the rule-generating interface provided in InfoPath. In this chapter, we will look at these three validation techniques ”W3C XML Schema, custom scripting, and InfoPath rules generation.

Before we move on to look at the three techniques in detail, it's appropriate to consider several aspects common to all three.

Visual Cues to Invalid Data

InfoPath offers several ways you can indicate to users that one or more pieces of data they entered are not valid.

To illustrate some visual cues, I have created a simple form that consists of two text boxes to contain a first name and a last name. The First Name text box is set to require content ”in other words, it can't be blank. When we first view the form in preview mode, the First Name text box is underlined in red (see Figure 10.1).

Figure 10.1. The First Name text box is underlined if it is blank.

graphics/10fig01.gif

In addition to the automatic underlining of the text box, a ToolTip is displayed (see Figure 10.2) when you move the mouse pointer over the text box.

Figure 10.2. The First Name text box ToolTip.

graphics/10fig02.gif

When an undesirable value is entered in the First Name text box and focus has passed out of the text box, the text box is outlined in a heavy red dashed line (see Figure 10.3).

Figure 10.3. A heavy dashed line indicates an unacceptable value.

graphics/10fig03.gif

In conjunction with the heavy dashed line that indicates an unacceptable value, a ToolTip might be available when the mouse pointer hovers over the text box (see Figure 10.4). In this example, I want the first name text box to hold the text string Fred .

Figure 10.4. A ToolTip indicating why the dashed line is present.

graphics/10fig04.gif

You can also provide an extended explanation of why a validity error is being signaled. The user can access the extended text by right-clicking the text box and selecting the Full Error Description option.

The full error description is displayed in a modal dialog box (see Figure 10.5). Users must respond to the message before they can continue to fill in the form.

Figure 10.5. The full error description displayed in a modal dialog box.

graphics/10fig05.gif

The techniques for controlling the ToolTip text and the full error description are described in the " Rules-Based Validation" section later in this chapter.

ORIENTING USERS

First-time users of InfoPath forms might be puzzled or confused by the visual cues that indicate invalid data. It makes sense to let users know that they are likely to see visual cues indicating invalid data, and to explain the typically simple things necessary to specify and resolve the problems. Depending on your local circumstances, you might choose to include that information during initial training or as a Help file for new users of InfoPath.


Interaction of Validation Constraints

The validation constraints defined in W3C XML Schema, script, and InfoPath rules can potentially interact with each other. For example, using W3C XML Schema, you can specify that a numerical value must lie between 1 and 10. You can also specify rules for the same component of the data source using InfoPath rules-based validation. You can use this to specify a new maximum of 5, which wouldn't cause a conflict. Clearly, if you use rules-based validation to specify that the number must lie between 11 and 20 while a W3C XML Schema rule specifies that it must lie between 1 and 10, you can expect problems to occur.

In simple form templates, the use of W3C XML Schema alone may be perfectly adequate. However, for many business scenarios, the additional constraints that can be defined using the InfoPath user interface provide more precise constraints than W3C XML Schema can express.

 <  Day Day Up  >  


Microsoft Office InfoPath 2003 Kick Start
Microsoft Office InfoPath 2003 Kick Start
ISBN: 067232623X
EAN: 2147483647
Year: 2004
Pages: 206

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net