InfoPath encompasses both a development environment for building business forms and a run-time forms application meant to be deployed on the end user's desktop. InfoPath "solutions," as they're called, are developed to enable end users to create and edit particular kinds of XML documents without having to know anything about XML. A different solution is developed for each kind of information that needs to be gathered, where "each kind of information" corresponds to an XML document type, or schema. Figure 10-1 shows one of the sample forms that come bundled with InfoPath. An average business user can fill out this form to create a valid instance of an XML schema for meeting agendas in this case. Notable features of this form include the use of InfoPath's built-in date picker control and the use of repeating sections (one for each agenda item).
Figure 10-1. One of InfoPath's sample forms being filled out
InfoPath solutions are heavily standards-based. Apart from an XML-based manifest file, called a form definition file, you can build a solution entirely using XSLT, XSD, and HTML. Form controls, text, and layout are described using HTML and CSS, supplemented with InfoPath-specific annotations. XSLT is used to transform the XML document being edited into the HTML-based form view. And information from an associated XSD schema serves to enforce validation on-the-fly, as the user fills out the form. By accessing the InfoPath object model, you can use ECMAScript and the DOM to further customize the behavior of the editor as necessary. Most importantly, when a user fills out a form, the data created by InfoPath is pure XML, valid according to your schema. Unlike Word, there is no InfoPath equivalent to the .doc proprietary format, or even to WordprocessingML, Word's proprietary XML vocabulary (see Chapter 2).
The InfoPath application supports two top-level tasks: filling out forms and designing forms. The task of filling out forms is the responsibility of end users, but the task of designing forms is up to you, the developer. InfoPath running in design mode is an indispensable tool for building InfoPath solutions, but it ultimately is not the only way to develop solutions. Since solutions themselves are thoroughly XML-based, you can develop them "by hand," by using InfoPath in design mode, or by using your XML toolkit of choice. In many cases, a combination of these approaches is appropriate.
This chapter will walk through two complete InfoPath solutions, one quite minimal and the other more feature-rich, that were developed "by hand," in order to expose the technical details of how a solution is put together. Only then will the InfoPath form designer be introduced in all its WYSIWYG convenience and power. At that point, you'll have a greater understanding of what InfoPath in design mode does under the hood, and you'll be able to use it to greater effect. If you're like me, you want the freedom to escape the confines of the GUI when necessary to treat the form designer as just another tool in your arsenal, rather than the sole crutch on which your development depends. In the final section of the chapter, called Section 10.5.5, we'll take a look at various approaches to developing solutions using a combination of hand editing and InfoPath in design mode.
Section 10.2, compares InfoPath to similar XML editing products and approaches. If you would rather go straight to the technical details, skip ahead to Section 10.3.
Please understand that since the InfoPath application is an extremely feature-rich product, we cannot hope to cover it exhaustively in a single chapter. Instead, we'll try to cover the essentials of what goes into the creation of an InfoPath solution. Along the way, we'll make key observations about the InfoPath processing model and include tips on using InfoPath design mode in conjunction with manual modifications to the solution files themselves.