Versions of InfoPath Form Templates

Changes in business circumstances over time mean that a need to make one or more changes to InfoPath form templates, other than prototypes , is almost inevitable. The reason for devoting a chapter to updating and modifying InfoPath 2003 form templates is that doing so is often far from easy. The major problems occur when the data source of the form template is modified.

InfoPath 2003 has no facility to easily and automatically modify a form template's data source. That lack of automatic form template modification means that we will need to delve into the structure of several of the files that make up an InfoPath form template.

First, let's look at why updating and modifying an InfoPath form template is much more of a consideration for the InfoPath developer than, for example, modifying a classic HTML/XHTML form.

FORM TEMPLATE FILES

The files that make up an InfoPath form template (the .xsn file) are described in Chapter 15, "Understanding the .xsn File." The InfoPath manifest file (the .xsf file) is described in more detail in Chapter 16, "The Manifest." You might find it helpful to consult those chapters if parts of this chapter contain unfamiliar material.

The Implications of Offline Form Completion

The ability to allow the completion of forms offline in InfoPath 2003 raises issues that don't occur with traditional HTML forms. A primary difference is the time period over which downloaded forms can be filled in and returned. For traditional HTML/XHTML forms, the time period is likely to be seconds or minutes. For InfoPath forms, the time period may be minutes, hours, or days, and occasionally may even be measured in weeks.

Consider the scenario with a traditional HTML form. A user uses a Web browser to access the URL at which the HTML form is located. The form is downloaded to the user 's machine and is typically filled in after a few minutes or less. If there is a need to change the server-side business processes, the URL from which the form is downloaded can be made briefly unavailable. Any forms already downloaded to a user's machine are likely to be filled in and submitted over the next several minutes.

The form at the original Web page can be replaced by a redirection page so that any new users of the (replacement) form are automatically redirected to the new form. They will, transparently , download that amended form, fill it in, and submit it to the (new) server-side process appropriate to that revised form. The authoring of the revised HTML form and the revised server-side process can all be done before making the new form publicly available. As far as users are concerned , they fill in the form presented to them and submit it successfully. Apart from the possibility of the form being unavailable (probably for only a few seconds), the user experience works well around the transition.

The timescale that applies to InfoPath forms makes the approach used for HTML forms problematic . In addition, the widespread use of W3C XML Schema in the background while processing InfoPath 2003 forms raises further issues.

For HTML/XHTML forms, the server-side process is likely to be custom-coded in a scripting language. The amended file submits to a different URL, which references the appropriate custom scripting code. For an InfoPath form template, the situation is different. The structure of the (old) form is defined by a W3C XML Schema document. If the form template is modified, it is likely that when the form data is submitted, the server-side W3C XML Schema document won't match, and an error will occur.

SHOP TALK
MINIMIZE CHANGES IN DATA SOURCE

Among the most common complaints about InfoPath are that the process of updating and modifying InfoPath form templates is far from obvious, and that modifying the data source of a form template requires fairly detailed knowledge of the structure of the files that make up the form template. Successful editing of the InfoPath files can also require a good understanding of W3C XML Schema, XSLT 1.0, and XPath 1.0. For some InfoPath developers, a primary reason for using InfoPath is that it doesn't require the developer to be proficient in these technologies, at least to achieve basic InfoPath functionality.

Suppose that an InfoPath developer creates a complex form using only or primarily the InfoPath 2003 user interface and then wants to make what seems (on the surface) to be a minor change to the InfoPath form template ”for example, in response to a customer request. Then, when a change is needed in the data source, the developer finds that either the form template must be re-created from scratch using one of the InfoPath wizards, or he must hand-edit several files inside the form template. For many developers, the need to hand-code what they naturally perceive to be minor changes is a very unpleasant surprise.

One lesson that you will quickly learn as an InfoPath developer is that planning the form template well can save you a lot of time (see Chapter 14, "Planning an InfoPath Form"), particularly with respect to planning the needed data. When budgeting for clients , make sure that you allow for the possible need to modify data sources when you calculate the delivery time and price.

This difficulty in amending the data source makes InfoPath a potentially clumsy tool for the occasional user. It places a premium on getting a form template's data source right the first time. For inexperienced or occasional users, it is often more practical to create an amended form template from scratch than to hand-edit XSLT, W3C XML Schema, and XML files whose structure is unclear and whose meaning is unfamiliar.

Let's look at the files that might need to be hand-edited and consider what purpose each of these files serves in the overall functioning of InfoPath and the form template.

Contents of an InfoPath Form Template

To understand what you might need to change, let's take a brief look under the hood at how InfoPath 2003 works.

An InfoPath form template typically consists of an .xsn file ”the form template that's a cabinet file containing several other files. So, if you wish, you can rename the .xsn file with a .cab suffix, and open the cabinet file with any tool that understands cabinet files.

An InfoPath form template, when unpacked, contains the following file types:

• A manifest ( .xsf ) file that contains many pieces of information about the files that make up the form template, and other information about how the form template is intended to function

• One or more XSLT ( .xsl ) files, each of which is an XSLT 1.0 stylesheet, which is used dynamically to create an InfoPath form template view

• One or more W3C XML Schema ( .xsd ) documents that specify the permitted structure of the form template's data source

• An XML file, template.xml , which exemplifies how an XML instance looks

• One or more script files ( .js or .vbs ), which may include XPath statements that depend on the specified structure for the template.xml file

For more information about unpacking a form template, see "Unpacking a Form Template," p. 260 .

Each of these files is discussed in more detail in Chapter 15. For InfoPath to work correctly, it is essential that the XML created from the information the user enters in the form matches the XML specified or used in the various form template files. If any discrepancy occurs, an error will take place at some point in processing a form, including the possibilities that a form won't open successfully or won't submit.

Many possible scenarios involve changes to the data source and therefore require the editing of individual form template files. We'll discuss the types of changes necessary in relevant files later in this chapter.

Visual Changes

When changes are made only to the visual presentation of a form template without any change to the data source, the situation is relatively straightforward. The data source remains unchanged, so there is no need to edit individual files to reflect any change in the structure of the data source, as no such change exists unless you hand-coded style elements using the CSS !important directive. You can make the visual changes you want using the InfoPath user interface.