14.1. The Structure of an InfoPath Form
InfoPath form templates are packaged in ZIP files with an .XSN extension. The ZIP format makes sense for a number of reasons. It is a universally recognized archival format that is supported by most operating systems. It also handles compressed binary formats easily, which enables the form template to include both XML content and precompiled assemblies. Figure 14-1 shows the XSN file for the sample expense report form.
Figure 14.1. Figure 14-1
14.1.1. The Form Definition File (XSF)
The manifest.xsf file contains XML code that describes all aspects of the form. It includes references to the other files in the archive as well as references to the various schemas used to describe different parts of the form. If you open this file in notepad and scroll through it, you can learn a lot about how InfoPath forms are organized. For instance, you can see many XML elements that describe how the form was last viewed in the InfoPath client application. There are other elements that contain information about the views, the controls used for editing data elements, the menus to display for various parts of the form, and the event handlers to associate with individual controls.
Toward the bottom of the file, there is an xsf:extensions element that warrants some attention. This element is used to bind the form to other platforms, like SharePoint. The following code snippet appears in the manifest for an expense report form that has been published to a SharePoint site.
<xsf:extensions>
<xsf:extension name="SolutionDefinitionExtensions">
<xsf2:solutionDefinition runtimeCompatibility="client" allowClientOnlyCode="no"
xmlns:xsf2="http://schemas.microsoft.com/office/infopath/2006/solutionDefinition/
extensions">
<xsf2:listPropertiesExtension>
<xsf2:fieldsExtension>
<xsf2:fieldExtension columnId=
"{b7d7c252-0b51-45a1-9ad2-40f72ea01c85}" readWrite="no" columnName="{AE404D63-E85B-4CB9-B0D2-3A39C5411FDB}"></xsf2:fieldExtension>
<xsf2:fieldExtension columnId="{4cd5d119-c850-4290-a122-7965075ddc69}" readWrite="no" columnName="{F97879E7-2A7C-43D6-BF2B-7849DBCAFFD3}"></xsf2:fieldExtension>
<xsf2:fieldExtension columnId="{da793958-73cb-48ba-8136-bc26e0eaa0db}" readWrite="no" columnName="{9FDD772E-194F-4617-8859-1EC2F130564D}"></xsf2:fieldExtension><xsf2:fieldExtension columnId="{93506d8c-5341-4357-93ac-93651a045957}" readWrite="no" columnName="{A0594F2E-CBE7-4DBD-A0C7-DA800CBAFCEF}"></xsf2:fieldExtension>
<xsf2:fieldExtension columnId="{64f1cc9f-5384-46c5-b05a-245b5fefea27}" readWrite="no" columnName="{2EBB7411-DD28-4405-96DF-EDB2D9992FB5}"></xsf2:fieldExtension>
<xsf2:fieldExtension columnId="{3c459bfc-c753-4ce9-ada1-b46ed76f5d05}" readWrite="no" columnName="{B423D728-4EF1-4116-8808-AB0B61E17F5C}"></xsf2:fieldExtension>
</xsf2:fieldsExtension>
</xsf2:listPropertiesExtension>
<xsf2:solutionPropertiesExtension branch="share">
<xsf2:contentTypeTemplate site="http://moss/prosharepoint2007" path="http://moss/prosharepoint2007/Form Templates/Expense Report.xsn" name="ExpenseReportForm" description="This is a standard expense report." browserEnable="no"></xsf2:contentTypeTemplate>
<xsf2:share formName="ExpenseReport" path="F:Documents and SettingsAdministratorMy DocumentsMy FormsPublishedExpenseReport.xsn"accessPath="F:Documents and SettingsAdministratorMy DocumentsMy FormsPublishedExpenseReport.xsn"></xsf2:share>
</xsf2:solutionPropertiesExtension>
</xsf2:solutionDefinition>
</xsf:extension>
</xsf:extensions>Notice the fieldsExtension section, which includes child elements that signals SharePoint to promote certain form fields to list columns. If this section is included in the form, then the specified fields are promoted. Also notice the contentTypeTemplate element within the solutionPropertiesExtension section that describes how the form should be bound to a content type. As you work with InfoPath forms in your SharePoint solutions, it is a good idea to poke around inside the generated files once in a while to become familiar with the different parts of the form and how they relate to SharePoint objects.
14.1.2. The Form Schema (XSD)
Every InfoPath form has a schema that describes the data that the form recognizes. When building SharePoint solutions that rely on form data, this is the most important file in the form template. If you are writing managed code that manipulates form data, then you will typically use the XSD.EXE utility along with the schema file to generate C# or VB classes that represent the data elements. You can then call the generated methods to create new data or to work with existing data in a form.
The XSD.EXE utility is installed as part of the .NET Framework SDK.
Listing 14-1 shows the schema for the sample expense report form. It is interesting to note that although this schema was created using InfoPath 2007, the namespace references in the schema refer to InfoPath 2003. This possible oversight does not affect the functionality of the form, since these are merely placeholder URNs that are used only to define the target and default namespaces. It is also interesting to note that the schema is standards compliant with no references to Microsoft schemas other than the two placeholders shown at the top of the file, which are unique to this particular form.
By scanning the form schema, you can quickly see how the data is organized as a hierarchy of complex data types. This maps directly to the tree of elements that InfoPath displays in the Data Source panel. Each tree node maps to a complex type in the XSD file. For example, the highlighted addressType node represents an address block that can be referenced from many places in the schema.
Example 14.1. Expense report form schema
<?xml version="1.0" encoding="UTF-8"?><xs:schema targetNamespace="http://schemas.microsoft.com/office/infopath/2003/sample/ExpenseReport" xmlns:exp="http://schemas.microsoft.com/office/infopath/2003/sample/ExpenseReport" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="expenseReport">
<xs:complexType>
<xs:sequence>
<xs:element name="employee" type="exp:contactType"/>
<xs:element name="manager" type="exp:contactType"/>
<xs:element name="expenseCode" type="xs:string"/>
<xs:element name="startDate" type="xs:date" nillable="true"/>
<xs:element name="endDate" type="xs:date" nillable="true"/>
<xs:element name="reportDate" type="xs:date" nillable="true"/>
<xs:element name="purpose" type="xs:string"/>
<xs:element name="notes" type="exp:xhtml" minOccurs="0"/>
<xs:element name="currency" type="exp:currencyType"/>
<xs:element name="items">
<xs:complexType>
<xs:sequence>
<xs:element name="item" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="date" type="xs:date" nillable="true"/>
<xs:element name="description" type="xs:string"/>
<xs:element name="amount" type="xs:double"/>
<xs:element name="category" type="xs:string"/>
<xs:element name="currency" type="xs:string"/>
<xs:element name="rate" type="xs:double"/>
<xs:element name="totalAmount" type="xs:double"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="cashAdvance" type="xs:double"/>
<xs:element name="total" type="xs:double"/>
<xs:element name="subTotal" type="xs:double"/><xs:element name="signatures" type="exp:digitalSignaturesType"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="http://www.w3.org/XML/1998/
namespace" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:complexType name="addressType">
<xs:sequence>
<xs:element name="line1" type="xs:string"/>
<xs:element name="line2" type="xs:string"/>
<xs:element name="line3" type="xs:string"/>
<xs:element name="line4" type="xs:string"/>
<xs:element name="city" type="xs:string"/>
<xs:element name="stateProvince" type="xs:string"/>
<xs:element name="postalCode" type="xs:string"/>
<xs:element name="country" type="xs:string"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="companyType">
<xs:sequence>
<xs:element name="name" type="xs:string" minOccurs="0"/>
<xs:element name="address" type="exp:addressType" minOccurs="0"/>
<xs:element name="identificationNumber" type="xs:string" minOccurs="0"/>
<xs:element name="telephoneNumber" type="xs:string" minOccurs="0"/>
<xs:element name="faxNumber" type="xs:string" minOccurs="0"/>
<xs:element name="emailAddressPrimary" type="xs:string" minOccurs="0"/>
<xs:element name="webSite" type="xs:anyURI" minOccurs="0"/>
<xs:element name="ftpSite" type="xs:anyURI" minOccurs="0"/>
<xs:element name="telex" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="companyWithContactType">
<xs:complexContent>
<xs:extension base="exp:companyType">
<xs:sequence>
<xs:element name="contact" type="exp:contactType"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="contactType">
<xs:sequence>
<xs:element name="name" type="exp:nameType" minOccurs="0"/><xs:element name="address" type="exp:addressType" minOccurs="0"/>
<xs:element name="identificationNumber" type="xs:string" minOccurs="0"/>
<xs:element name="emailAddressPrimary" type="xs:string" minOccurs="0"/>
<xs:element name="emailAddressSecondary" type="xs:string" minOccurs="0"/>
<xs:element name="telephoneNumberWork" type="xs:string" minOccurs="0"/>
<xs:element name="telephoneNumberHome" type="xs:string" minOccurs="0"/>
<xs:element name="telephoneNumberCell" type="xs:string" minOccurs="0"/>
<xs:element name="telephoneNumberPager" type="xs:string" minOccurs="0"/>
<xs:element name="faxNumber" type="xs:string" minOccurs="0"/>
<xs:element name="jobTitle" type="xs:string" minOccurs="0"/>
<xs:element name="officeLocation" type="xs:string" minOccurs="0"/>
<xs:element name="department" type="xs:string" minOccurs="0"/>
<xs:element name="webSite" type="xs:anyURI" minOccurs="0"/>
<xs:element name="ftpSite" type="xs:anyURI" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="contactWithCompanyType">
<xs:complexContent>
<xs:extension base="exp:contactType">
<xs:sequence>
<xs:element name="company" type="exp:companyType"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="digitalSignaturesType">
<xs:sequence>
<xs:any namespace="http://www.w3.org/2000/09/xmldsig#" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="nameType">
<xs:sequence>
<xs:element name="prefix" type="xs:string" minOccurs="0"/>
<xs:element name="givenName" type="xs:string" minOccurs="0"/>
<xs:element name="middleName" type="xs:string" minOccurs="0"/>
<xs:element name="surname" type="xs:string" minOccurs="0"/>
<xs:element name="suffix" type="xs:string" minOccurs="0"/>
<xs:element name="singleName" type="xs:string"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType><xs:complexType name="currencyType">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="symbol" type="xs:string"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="xhtml" mixed="true">
<xs:sequence>
<xs:any namespace="http://www.w3.org/1999/xhtml" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema> |
14.1.3. The Form Views (XSL)
Views are an important part of a form because they provide a way to present different information, depending on the runtime environment and other factors, including the security profile of the end user. InfoPath form views are defined as XSL stylesheets, which makes them relatively easy to work with. Because they are based on XSL, you can theoretically substitute any XSL code you wish to create your custom views. That said, the default views that are generated by the InfoPath client make heavy use of Microsoft-specific schemas, so in practice, you will not be creating your own views by hand. However, you can and probably will have occasion to edit the XSL files to modify the default behavior.
Most of the conditional formatting rules that you apply to a form end up as XSL code in one or more views. For instance, the following code snippet is taken from the view stylesheet for the report date field of the sample expense report form. The highlighted section shows an example of how XSL is used to format the date if a special formatting function is available.
<div>
<div>
<font face="Verdana" size="1">Report Date: </font>
</div>
<div class="xdDTPicker" title="Report Date" style="WIDTH: 100%; FONT-FAMILY:
Verdana; FONT-SIZE: x-small" noWrap="1" xd:xctname="DTPicker" xd:CtrlId="CTRL97" tabIndex="-1">
<span class="xdDTText xdBehavior_FormattingNoBUI" hideFocus="1"
contentEditable="true" tabIndex="0" xd:xctname="DTPicker_DTText"
xd:boundProp="xd:num" xd:datafmt=""date","dateFormat:Short Date;"" xd:innerCtrl="_DTText" xd:binding="exp:reportDate">
<xsl:attribute name="xd:num">
<xsl:value-of select="exp:reportDate"/>
</xsl:attribute>
<xsl:choose>
<xsl:when test="function-available("xdFormatting:formatString')">
<xsl:value-of select="xdFormatting:formatString(exp:reportDate,"date","dateFormat:Short Date;")"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="exp:reportDate"/>
</xsl:otherwise>
</xsl:choose>
</span>
<button class="xdDTButton" xd:xctname="DTPicker_DTButton"
xd:innerCtrl="_DTButton" tabIndex="-1">
<img src="res://infopath.exe/calendar.gif"/>
</button>
</div>
</div>14.1.4. The Data File (XML)
When you create a new form template or edit the data source, InfoPath generates a sample data file that conforms to the schema and stores it with the form. This is marginally useful during development, because if you want to create sample data, you can simply use the InfoPath client to fill out a form and save the data file, stripping out the InfoPath processing instructions. Also, InfoPath is not consistent about which data fields it populates, leaving many of the fields empty.