InfoPath 2003 installs effortlessly as a separate tool within Office 2003. The program will be familiar to anyone who’s seen Microsoft Visual Basic or almost any other modern programming tool.
InfoPath Form We tested InfoPath using sample data from PC Magazine Labs’ inventory system for tracking products, vendors, and items for review. First, we connected to an SQL Server 2000 database. (InfoPath also supports Access.) Connecting to other databases must be done via Web services. (Luckily, vendors like Oracle already provide this capability, but we would like to see the addition of OLE DB support for other databases.)
A wizard let us select which tables and fields to include in our electronic form. This tool, which is comparable in difficulty to Excel’s query designer, lets you point and click your way through designing queries. The wizard had no trouble with a single table, but with a more complex one-to-many join to track invoices and invoice details, the wizard required some tweaking. A second source for new forms is standard XML Schema files (with the extension .xsd). We had no trouble importing a model order form created with Microsoft Visual Studio .NET.
Best online Microsoft MCTS Training, Microsoft MCITP Certification at certkingdom.com
Finally, we tried tapping into several simple Web services built with C#, which simulated processing orders for a sample online store. This met with mixed results. There is some debate over how to structure Web services—whether to use multiple calls to pass smaller amounts of data or fewer calls to send larger chunks of information. InfoPath generally requires the latter. If your Web services are highly focused (meaning they don’t pass large XML documents back and forth), you should think about redesigning them. This is easy enough to do, but it was evident that tweaking Web service APIs is a fairly important step before jumping into InfoPath form creation.
On the plus side, the Web services wizard lets you browse UDDI (Universal Description, Discovery and Integration) directories to locate available Web services and choose whether you will be sending and/or receiving XML calls. It then parses the WSDL (Web Services Description Language) and generates a form based on the shape of your Web service data.
In fact, from various data sources, InfoPath generates a default form, with labels and input boxes for all the fields in your file. Database tools and report generators have done this sort of thing for years, of course, but InfoPath is aimed at general business users rather than database programmers. And it does a good job, for the most part, at hiding the complexity from end users.
There are about a dozen control types that can be placed on a form, including drop-down lists and repeater-type controls for creating repeating sections (for example, the details or line items common to many business documents). We found the repeating controls a little tricky, but we had little trouble generating a custom invoice form with multiple rows for shipped items. The resulting form automatically creates new rows to fit the data, which can save space in real-world forms if lines aren’t always required. Certain kinds of forms will really benefit from such streamlining, since they can actually shrink and grow to fit the data at hand. And we appreciate that Office 2003 includes more than two dozen sample forms to work with, covering such items as absence requests, project-planning documents, meeting agendas, and purchase orders.
Within InfoPath, it’s generally easy to customize the positions of controls, and you can set properties and add validation to each control. Power users can even add VBScript and JScript statements for more complex processing.
When you are satisfied with your form, InfoPath saves it to an XML file with the .xsn extension. A quick look at our invoice form showed use of XML Schema including name spaces and attributes (with the schema stored on our SharePoint Services server when we published it for teams). Once your organization decides on the shapes of commonly used forms that fit your databases or Web services, reusing them is a cinch via the built-in shared library or team workspace window.
In form entry mode, InfoPath turns into a facile data entry utility with powerful ease-of-use features. First of all, we like that all date fields can easily be selected using the standard calendar control. Using auto-complete, we easily picked by value, even for standard input boxes. For extensive data entry, you can expect users to type a lot less using this feature. For example, common phone numbers and ZIP codes can be reused effortlessly.
In our experience, InfoPath is a very capable data entry tool. With some additional effort (which will inevitably involve help from IT), you can get users to edit XML data in the software they are most familiar with, like Word and Excel. To use InfoPath forms with Word, you should create an XLST file in Microsoft FrontPage, which can apply visual formatting to raw XML. Without an XLST file, you can view and edit the contents of XML, which will display within tags. In Excel, you can import raw XML data into a row of cells in a spreadsheet. Still, we expect InfoPath will be used most of time for data entry. Although it will take some time to get everything set up for editing XML in Word and Excel, these features can be very useful for working with certain kinds of files, such as reports (in Word) or budgets (in Excel).
