One significant improvement in Microsoft Office SharePoint 2010 is the ability to easily create custom Microsoft Office InfoPath 2010 forms to perform create, read, and update operations against SharePoint lists. You create custom InfoPath 2010 forms to replace the out-of-the box forms for performing these typical list operations.
A common reason for using custom forms is to include in your form client-side field validation rules, such as verifying that a value entered by a user falls within a certain range of allowed values.
The information in this article will help you with deploying your own custom InfoPath forms to external lists across multiple SharePoint farms while managing your InfoPath forms in a source control system.
Publishing a Form to an External List
The steps you follow to create and publish a custom form to a single external list aren't difficult. One way is to open the list using SharePoint Designer 2010, and click Design Forms in InfoPath in the ribbon's Action tab.
Figure 1 shows this option for an external list named Currencies. When you click Item under Design Forms in InfoPath, an additional ASP.NET forms page will appear under the Forms section in SharePoint Designer 2010 for each supported operation.
For example, the Currencies list includes three new ASP.NET forms that host the BrowserFormWebPart: editifs.aspx (for the update item operation), newifs.aspx (for the new item operation), and displayifs.aspx (for the view item operation).
SharePoint Designer automatically sets these ASP.NET forms as the default forms for the list and generates the custom InfoPath form, template.xsn. The BrowserFormWebPart hosts the custom InfoPath form in WebPart pages. SharePoint Designer saves all the ASP.NET files and the .xsn file to the Item folder of the target list.
After these SharePoint Designer operations are complete, SharePoint Designer launches InfoPath Designer 2010 to load the template.xsn file for subsequent user customizations and for publishing to the SharePoint list. (See the Sidebar "Designing an InfoPath Form after Closing It.")
You can publish the .xsn file to the SharePoint list by clicking the Quick Publish button in InfoPath 2010, as Figure 2 shows. This procedure is called Quick Publish because InfoPath modifies the .xsn content slightly and saves the .xsn file back to the location from where it was opened.
You'll encounter one additional step the first time you click Quick Publish for an external list form. You must save the form locally.
As a result of the local save operation, InfoPath stamps the form definition file (manifest.xsf) inside the compressed .xsn file with the local save location to further process the file contents for Quick Publish. Note that Quick Publish isn't available if you have full-trust code behind the InfoPath form.
In that case, you must publish the form template to Central Administration, then deploy the form to a site collection, as you had to do in SharePoint 2007.
The custom form creation and Quick Publish process is simple for a single SharePoint farm deployment. However, there are some pitfalls you'll encounter when developing a solution that must deploy rapidly, is customized by more than one developer or forms designer, must be versioned in source control, and must be promoted from one farm to the next.
Code and artifact promotion are common when you move your solutions from development through Q&A and into production.
Managing the Development Lifecycle of InfoPath
If you add your InfoPath form (.xsn file) to a source control system, you'll gain fundamental benefits, such as check-in, check-out, work-item associations, conflict resolution, and per-computer/per-user workspaces.
The problems with source control and artifact promotion relate to dependencies injected into the manifest.xsf file, which is part of the .xsn template package. The .xsf file is an XML document that you can view and edit with a text editor.
The first hard dependency is the publishUrl attribute’s value in the xsf:xDocumentClass element. InfoPath Designer 2010 uses this attribute to determine where the template.xsn file was saved previously.
Each time a form designer gets the latest content from source control, the designer’s local workspace updates with the latest checked-in version of template.xsn. After checking out and making changes to the form using InfoPath, then clicking Quick Publish, a dialog box appears stating that you must save the form before it’s published.
Saving the file to a designer’s local workspace will change the publishUrl path to the designer’s local workspace path. The next form designer who opens the form will encounter the same save-location problem, unless both form designers have their workspaces mapped to the same location on a disk.
Sharing a single workspace or enforcing that everyone maps to a single workspace location on a disk is not common when working within a source control system. The extra Save dialog probably sounds inconsequential, but it is a time waster when working with more than one or two forms.