Within the InfoPath design environment all work is done through the various task panes. Each of the task panes represents a specific design activity. These include layout, controls, data source, views, and publishing. After you have completed the data source wizard, InfoPath will place you in the data source task pane with a list of the design fields and a blank form to begin placing your data elements.

Build the Form
Now that we've successfully created a connection to our Web service and created an instance of our XML data we are ready to build our data entry form. The easiest way to build a form is to build around table structures, similar to building a Web page. Tables will help to control the formatting and provide an easy alignment for the various fields that you can place on your forms. The layout task pane provides a variety of table options that you can drag onto your blank form.

InfoPath provides two important types of sections or tables that can be used to improve the formatting of your form. The first is the repeating table. In this table each column represents a field and each row represents an additional occurrence of the group of fields. This would be an easy solution if, for example, you were looking to collect a series of patient insurance information and didn't want to limit the number of items that someone could enter. The second is the optional section. These are sections that can be inserted and removed by users while they fill out forms. As a form designer you can specify whether fields or groups of fields should appear by default in the blank form or if they should appear only when the user inserts them. For example, if I wanted to allow a notes section on my form I could allow the user to determine if he or she wanted to include the section or not. This allows the user to remove the entire section without having to delete the text and leave a blank field.

For the patient information form there were two sections that we needed to develop. The first was a title or header section that contained the form name and instructions for completing the form. The second area was the actual data area. This area contains the fill-in fields that users will complete as part of the form.

Moving the data fields on the tables is an easy drag-and-drop operation from the data source task pane to the columns within the table. It is important to understand that based on the data types specified by the WSDL of the Web service InfoPath will associate a specific control type. For example, if you look at the date of birth field you will see that a date picker control was automatically selected. If you decide that you want to change the default associated control you can right-click and select the specific control type that you want. Additionally, if you want to validate which field a particular fill-in field is bound to, you can hover your mouse over the field. A pop-up window with a green indicator and a schema field name will identify that your field is properly bound to the data source.

After placing all the required fields and saving the form template you are ready to fill out and submit the form to the bound Web service. In addition to Web service submission end users also have the ability to export their form to a static Web page, to Excel, or to someone through e-mail. As you begin developing InfoPath solutions, e-mail provides an easy out-of-process workflow step-for example, if you wanted to notify someone via e-mail that a particular patient has entered the physician's office.

Data Formatting and Validation
At this point we've created a fill-in form that could be distributed and used. The problem is that we haven't included any of the formatting or business logic needed to validate the entered data. InfoPath provides designers with the ability to control the formatting of plain- and rich-text boxes, sections, and repeating tables based on a set of user-defined conditions. As you create a condition, you specify the font, styles, background color, and even whether to hide the specific control. Conditional formatting is stored as part of the XSLT and is applied to form fields whenever the specific set of conditions is met. For example, one of the requirements for the patient information form was that required fields were to have a red background. Conditional formatting statements are entered through the field's display options, by selecting the conditional formatting tab. Within the tab, building the expression is done by selecting the various fields and filling in the required conditions (see Figure 2).

One of the main requirements of most data-driven forms, in addition to conditional formatting, is validation. InfoPath provides three levels of validation: schema-based validation, declarative or rules-based validation, and custom script. Depending on the complexity of your form it's possible to have all three levels implemented on a particular field. Schema-based validation and then declarative script-based validation are defined based on an InfoPath event model, so the forms developer has full control over when this occurs. InfoPath allows a form to be saved without successfully passing validation but will prevent submission to the data source until all checks are successfully completed.

For our patient information form we used an existing Web service. This allowed us to take advantage of schema-based validation. Schema-based validation occurs whenever a user fills in a form. After data is entered in a field and the user moves to another field the data is immediately checked against the schema. If the data fails the schema, check the marked field with a red dashed border. The user can then right-click the marked field and be given feedback as to the data type or schema requirements. As we are bound to a Web service our schema is predefined. For example, if I entered text into the age field, which is defined as an integer, a schema validation error would occur. By default InfoPath will check for an invalid data type, specified range, and required fields as defined within the schema definition.

The declarative engine is important based on the context of the user completing the form. For example, one important scenario in our new patient form was that all patient ages were greater than zero. The rules engine is accessed from the data validation tab of the field properties. It is another fill-in field dialog box that allowed us to visually build rules. If an applied rule fails, you can provide either a pop-up box or a tool tip as feedback to the user. For our scenario we felt it was better to provide the modal dialog as the preferred feedback mechanism.

InfoPath also provides an event model to allow programmatic access. In this scenario a developer can prewire events to script components that can occur within either the form's data fields or the entire form. Form-level events include form open, view switches, form submission, and data imports. At the field or node level InfoPath provides events around data change events (see Figure 3).

InfoPath provides a rich model of events that can occur both at the document and node level. In order to create your application correctly it is important to understand when these events are fired. Events associated with document lifestyle occur in the order shown in Table 2. Events associated with node-level data occur in the order shown in Table 3.

Events are created through script components that run in response to the type of trigger assigned. Currently, InfoPath supports either VB script or JavaScript components. Script language is defined at the form level using the InfoPath system options. The design of InfoPath requires that the client application is used to associate the event name, and script development be done through the Microsoft Script Editor (MSE). The event function is referred to within the form definition file, which means that you aren't able to change the function name or arguments. Figure 4 shows the form in run mode, and Figure 5 shows the architecture of how this solution would be developed.

Summary
Through this article we have developed a fully functional form for my health care customer to collect new patient information. Once collected and validated this information is automatically submitted to their back-end Web service.

Stay tuned for the second part of this series where we will extend this solution to leverage the back-end services of Biztalk Server 2002. When InfoPath is combined with this, you can create some dynamic workflow applications for your enterprise.We have covered only a very small portion of the InfoPath environment in this article. I leave it up to you to discover how InfoPath can help you reduce your "mountain of paper" and explore the further capabilities of the InfoPath 2003 application.

Resources
Several files are available for download at www.sys-con.com/xml/sourcec.cfm, including NewPatient.xsn, the actual form; Savedform.xml, a saved version of the form; and Webview.mht, a saved version of the form for the Web.