Catálogo de publicaciones - libros

Microsoft introduced InfoPath in 2003 as part of the Office System. While it may appear to be a simple form designer, its apparent simplicity masks an incredibly powerful tool for building the user interface for any number of applications. InfoPath can cover a multitude of situations, from basic workgroup forms that produce XML to enterprise applications that submit data, via web services, to an enterprise application integration (EAI) engine such as BizTalk Server.

The InfoPath client is very straightforward—opening it presents you with a wizard that allows you to select from a number of forms in a gallery of samples, from a list of recently used forms, and from an online library of forms. In addition, you can design and publish forms, guided by wizards in the client. This Chapter will cover the fundamentals of the InfoPath interface, design concepts, and some of the underlying architecture concepts.

This Chapter will tour the InfoPath designer, cover some of the basics, and generally try to fully cover all the design features of InfoPath. It will cover some basic design concepts and tour the InfoPath form designer features. This is the entry point for building everything from basic data entry forms to powerful enterprise e-forms.

Remembering that InfoPath form data is all about the underlying XML, one has to ask the question, “If the form is just a view on the data, can I have different views?”

Once you’ve designed a form template, what are you going to do with it? If you want other people to be able to fill it out, you need to publish it to an accessible location. With InfoPath, there are a number of ways to publish form templates—you can publish to a shared file location on a server, to a web server, or to a SharePoint form library. You can also “publish” by creating an installation package that you can send to users to install and fill out.

InfoPath 2007 and SharePoint are designed to work well together. SharePoint has built-in form libraries and content types, and the newest version has Forms Services to present forms in a browser for users who don’t have InfoPath installed. In turn, InfoPath has a built-in capability to publish form templates to SharePoint, creating a form library in the process. It can also pull data from SharePoint lists for lookup lists, and leverage SharePoint workflow.

Electronic forms are somewhat pointless if you don’t actually put the data anywhere. Fortunately, InfoPath has rich capabilities for “doing stuff” with the form data once the user has entered it. In addition, you have to consider the various aspects of getting data out of somewhere and into the form (to populate both form data and lookup lists, among other uses).

Now that the basics of the client and designer have been covered, I’m going to dive into some advanced topics with InfoPath forms. The “basics” cover most of what you need to build a robust line of business forms. However, there are still some aspects of InfoPath that need to be covered to round out the “out of the box” features available to a form designer.

InfoPath’s user interface is incredibly powerful—you’ve seen how to use rules, validations, dynamic sections, and views to create very robust forms. However, there will be things that you cannot do with the standard interface. When you find that the features of the InfoPath form designer aren’t enough, you can write script or managed code (C# or VB .NET) behind the form.

Now that I’ve covered basic coding with an InfoPath form template, I’m going to discuss two more advanced (and very useful) approaches to writing code: using Visual Studio Tools for Office (VSTO) 2005, Second Edition (SE) to write an add-in for InfoPath, and creating a custom task pane using Visual Studio.