InfoPath Development Basics

There are two ways to construct forms for use within a SharePoint environment. The first is to build an InfoPath form and publish it to a SharePoint Form Library. The second is to build a custom WebPart containing the appropriate child controls to collect information from the user and send it into SharePoint via an event handler. Each technique has some advantages and disadvantages, but generally you will find that the InfoPath experience is the easiest and fastest. Furthermore, MOSS directly integrates a new feature called InfoPath Forms Services, which supports users who don’t have the InfoPath Smart Client application installed by supporting form interaction for remote users who only have an appropriate browser installed.

Introduction to InfoPath Forms Services and InfoPath Object Model

Using InfoPath and InfoPath Forms Services over other methods of forms development provides several benefits that greatly extend the power of paperless forms and speed the time to production for a corporate electronic forms solution. Prior to the release of InfoPath Forms Services, InfoPath 2003 as a form development tool used to be frustrating for users, developers, and network engineers for several reasons. Developers were forced to use MSXML (Microsoft XML Core Services) as opposed to traditional .NET XML methods and native development environments were not robust. End-users and network engineers used to need the InfoPath client application in order to open the form to enter and submit relevant data, therefore mandating the required Client Access Licenses. If accessing the form from a separate machine other than one that had the InfoPath Smart Client installed, there was no mechanism by which to natively cast the InfoPath form to an HTML compatible form for remote data entry.

Design Once Programming Paradigm

Leveraging the capabilities of InfoPath Forms Services allows a majority of the Smart Client InfoPath form rendering to be parsed out to a comparable HTML form when the InfoPath client is not discovered on the requesting client machine. The InfoPath 2007 object model supports this by facilitating the Design Once programming paradigm.. By introducing the capabilities of InfoPath Forms Services where forms can be both rendered by the server in a browser as well as on a client machine running the InfoPath client, the option to develop against the InfoPath object model necessitates support for both scenarios of forms rendering. Under normal circumstances, providing the facility of both client and server side rendering would require the use of two separate InfoPath Object Models, one dedicated to form browser rendering and another dedicated to client form rendering. However, the object model in InfoPath 2007 is built to be uniform in that code written against a form will render in both environments, with certain exceptions in regards to particular controls, custom add-in, and custom task pane integration. InfoPath 2003 developers are most likely familiar with the COM-based solution development that InfoPath 2003 depending heavily upon. COM-based development likewise will only render within the InfoPath Smart Client, and not within any of the browser based forms.

The Design Once programming paradigm is supported by a feature in InfoPath 2007 called the Design Checker which allows the verification of form templates targeted for deployment to InfoPath Forms Services by generating information about backward-compatibility for controls and functionality that only renders within the InfoPath Smart Client. You also have the option when designing a new form in InfoPath to Enable Browser browser-compatible features only with the form content being created, which creates a browser complaint form by using only those controls which will parse to a cast HTML form. When designing the new form, you are also afforded the option within the Design Checker settings to point to a Forms Server where the URL can be entered in order to verify the settings.

Once the InfoPath forms designer is aware that the form being developed needs to be browser based, it will run a remote check and allow verification against the server, displaying both errors that occurred and important messages regarding the verification for zero footprint form fill-in.

Development Object Model and Development Tools

The InfoPath 2007 Object Model is fully CLR 2.0 compliant, which negates the interaction of PIA references as required previously and is based off the System.Xml namespace as opposed to MSXML so the .NET XML semantics developers are familiar with can be exploited. The caveat to this of course is if developing a custom InfoPath add-in or TaskPane that is targeting the InfoPath Smart Client the old PIA references need to be used, since the new OM is targeted towards both server and browser rendering.

The introduction of a new object model allows the leveraging of Visual Studio Tools for Applications (VSTA) or Visual Tools for Office (VSTO) IDE’s in order to develop managed code for custom forms. In short, VSTO enables a .NET project to use Office functionality, such as manipulating Word or Excel documents. VSTA enables an Office application (or any other app that incorporates VSTA) to use .NET code for customization. Typically, a customized InfoPath 2007 form will use VSTA coding which is why when using the programmability options within InfoPath VSTA can quickly be brought up under the programming menu or by selecting ALT+SHIFT+F12 (See Figure 14-10).

Figure 14-10

VSTO and VSTA are very similar development environments; however VSTA is a branched project off of VSTO. VSTO was designed for managed code development to construct various types of extensions for Office application consumption. VSTA extends the concepts that are presented in VSTO with the option to develop unmanaged, as well as managed code. Since VSTO is specific for building extensions for Office applications, if planning development environments for building applications besides Office extensions, VSTA would be a wise decision since VSTA leverages the Managed Add-in Framework (MAF) as its core engine. Using VSTO will allow you to host InfoPath development elements directly in your Visual Studio IDE, and allowing the creation of Form Template Projects if it is a known requirement that there is going to be custom backend business logic.

It is not necessary to choose just either VSTO or VSTA, VSTO is a subset of VSTA, consequently when using VSTO you can still leverage VSTA, therefore it is up to the developer to choose which track is appropriate for their purpose given that both still support both Smart Client and browser targeted form rendering.