Here is the second in a series of impromptu hints and pointers for Microsoft Office SharePoint Server 2007.

InfoPath. Have you used it? You’re not still using Microsoft Word and form fields, are you? In addition to being a great alternative to locked Word documents for departmental form filling, InfoPath is a great development platform.

You can use InfoPath forms for a number of tasks: capturing form data and saving it as a document (of course); uploading into SharePoint to start a workflow; using custom InfoPath forms to allow admins to configure reusable workflows; rendering in a browser via ASP.NET.

Which brings us to:

Popular Misconception #1 – “InfoPath forms need InfoPath installed on the desktop. We don’t have control over what’s installed on our users’ PCs, so we can’t use InfoPath.”

Admittedly, the user experience is better when InfoPath forms are opened in InfoPath Client 2007, but you can publish a form with a high degree of fidelity either through a browser-enabled SharePoint Document Library, or on a custom ASP.NET page in MOSS using the <XmlFormView /> control.

[Gotcha: the Document Library containing the browser-enabled form and your custom ASP.NET page have to live within the same Site Collection! Here is a great article on the MSDN site detailing the steps to use the XmlFormView control.]

Popular Misconception #2 – “I can publish an InfoPath form as browser-enabled, and it will look and feel just like InfoPath Client.”

Well, no. It’s good, but it’s not *that* good. The rendering is pretty faithful, but there are some features that are just incompatible. There are others features that behave quite differently in the browser-enabled version.

The images below show how the a simple for can render in both a browser and the Office Client, left and right respectively.

Some field types available in the Office Client just aren’t available in (this release) of the browser-enabled forms. For instance, instead of Combo Box fields, you have to use List Box fields. Instead of Rich Text fields, you have to use multi-line text boxes. It can’t be long before this gap is closed. With the current crop of AJAX frameworks (Microsoft, ExtJS, others) these controls should be able to be represented. Maybe next version.

There are other differences too: browser-enabled forms with complex logic, multiple data sources, business logic events and a raft of other conditions can cause your form to require a postback during editing. This is all handled automatically, but it can still cause a downgraded user experience, and increased server load.

[Gotcha: You can’t publish InfoPath 2003 forms as a browser-enabled, Office Forms Server form! InfoPath 2003 uses a COM APIs, whereas InfoPath 2007 and Office Forms Server 2007 use .NET APIs.]

Popular Misconception #3 – “InfoPath forms are just Xml. I can create them in Notepad if I wanted to.”

“Close,” as Roy Walker would say, “but not right.” The principle is that InfoPath forms are defined as Xml. When you create one and save it, you get an .xsn file. As with much in the world of WSS and MOSS, these files are re-purposed and re-named .cab files. Here’s something you can do: create a simple InfoPath form, save it as an .xsn file and rename it – changing the extension to .cab.

When you double click it, Windows Explorer should open up the .cab and show you the contents.

Typically, an .xsn file you create will contain by default a few different Xml files:

File Type	Purpose
manifest.xsf	The core InfoPath form definition file. Defines the fields, repeating blocks and controls used in your form.
myschema.xsd	Xml Schema Definition file that defines the shape of your Xml data. In the case of InfoPath forms that consume web services, this is generated from the WSDL.
sampledata.xml	Specifies what the default values should be for each of the fields on your form.
template.xml	The Xml document that InfoPath will populate with data and submit.
view1.xsl	An Xslt file describing how to render the form. Incidentally, forms are rendered, even in the InfoPath Client, as Html.

It will also contain any media files that you embed in your form, such as images and logos, and any further view*.xsl files specifying additional views on your form. If you have .NET business logic in your form, the resulting .NET assemblies will also be included in the archive.

Popular Misconception #4 – “I can only create InfoPath forms in the designer of Office InfoPath Client.”

Visual Studio Tools for Office 2005 and Visual Studio 2008 form a great environment for developing InfoPath forms. This gives us two choices:

• A combination of InfoPath Client 2007 designer to design the form and Visual Studio Tools for Applications (VSTA) to create .NET business logic
• Visual Studio 2005/8 with Visual Studio Tools for
  Office (VSTO)

The picture below shows the a similar form being designed in both environments.

There are pros and cons with each method.

• Visual Studio 2005/8 requires a license! If you aren’t developing other .NET projects, VSTA and InfoPath Client provide a robust and flexible development experience.
• Visual Studio 2005/8 with VSTO uses its own rendering engine in the designer – there are some discrepancies between what gets rendered in each. The InfoPath Client offers the more faithful reproduction during design.
• The premium development environment is still Visual Studio 2005/8. VSTO and Visual Studio integration is very close indeed. With InfoPath Client and VSTA you are using two separate applications.

For the hardened developer, Visual Studio 2005/8 will be the better of the two choices.

Here you can read Microsoft’s Andy Whitechapel discussing the differences between VSTA and VSTO.

Happy coding!