10.2 InfoPath in Context
| While WYSIWYG (What You See Is What You Get) and forms-based XML editing together compose a relatively new field, InfoPath is by no means the first kid on the block. Before delving into the details of InfoPath's particular approach, let's take a step back and examine some of the common design problems that engineers of related products face, and how they are often solved. Then we'll be able to understand InfoPath's design in a wider context. 10.2.1 The ProblemSay you have an application that requires data to be gathered, stored, and presented. You also need to repurpose that data in different contexts, whether doing analysis on it or presenting it via different media. So you decide to use XML. Next you design an XML schema for your documents. So far, so good. Now you face a more difficult problem. How do you get your users to enter information in the format that you need? In other words, how do you get them to create XML? Well, you could try to teach them XML. While the thought of everyone in the world speaking our favorite language is a touching one, it's also unrealistic. Your job isn't quite done yet. You need to provide a user-friendly way for people to create XML without having to know or care that it's XML they're creating. 10.2.2 Alternative ApproachesXML editing applications such as InfoPath represent just one way to solve this problem. Two other approaches to gathering XML include building a custom application and using a generic server-side framework. 10.2.2.1 Building a custom applicationOnce you've decided on a particular XML schema, you could write a custom application designed to gather information in that schema. Whether you build this as a desktop application written in VB (Visual Basic) or as a web application using HTML forms, it will be hard-wired to your particular schema. The problem with this approach is that it tends to get reinvented every time a new kind of information needs to be gathered. After going through this experience two or three times, you'll long for a more generic framework that lets you just plug in an XML schema and make a few tweaks each time you need to gather a new kind of information. 10.2.2.2 Generic server-side frameworksChances are, someone has implemented a generic form-to-data management solution for your favorite server-side web application platform, whether J2EE, .NET, Perl, Python, or PHP. An example of an XML-oriented framework that is Java-based is called JXForms. Based on Apache Cocoon, it supports the automated mapping between HTML forms and XML documents according to the schema that you specify. It's also based on XForms, a W3C recommendation which we'll talk about shortly in "InfoPath versus XForms." For more information on the JXForms framework, see http://cocoon.apache.org/2.1/userdocs/flow/jxforms.html. Server-side frameworks such as JXForms can save you a lot of development time building repetitive custom applications, but they also have some severe limitations:
10.2.3 Rich-Client XML EditorsA number of products designed to address the limitations of HTML forms have been cropping up in various shapes and sizes in the last few years. In comparing the various rich-client XML editors, I've found it helpful to see where they land across different dichotomies. These aren't always true dichotomies, as some products clearly fall on both sides. InfoPath, for example, could be characterized as both data-oriented and document-oriented (to a limited extent). Rather than trying to navigate the shifting landscape of XML editors here, I'll limit my focus to InfoPath and how its approaches compare to other products in general. 10.2.3.1 Browser-based versus desktop deploymentThere is a growing number of browser-based XML editors on the market, built to run on a variety of different platforms. Deployment formats include ActiveX controls (Windows only), Java applets, and Mozilla-only JavaScript modules. Browser-based editors, in many ways, provide the best of both worlds when it comes to XML editing and web functionality. As a browser plug-in, the editor is automatically installed or updated when a user loads a page in which it's embedded. This makes it possible to deploy XML editing applications over the Web at large. And in a corporate environment, it means that the IT department won't have to worry about yet another installation or upgrade on users' machines. InfoPath is not a browser-based application, and at the time of this writing Microsoft has not revealed any plans to release it as such. As a member of the Office family, it must be installed on the desktop of each user who intends to use it to fill out forms. There are, however, some significant advantages of this approach. Most notable is the ability for users to save filled-out forms on their own machines, in addition to being able to submit them, for example, to a web service. Before a user has finalized his work, he can save it to his machine for later editing, or email it to a co-worker for further review just like any other Office document. Security restrictions make this impossible for the browser-based editors. As a desktop application, InfoPath also provides sophisticated native functionality not available in any of the browser-based editors, such as the ability to export to an Excel spreadsheet, or merge multiple filled-out forms into the same view. 10.2.3.2 Document-oriented versus data-orientedThe distinction between document-oriented and data-oriented XML is a tenuous but useful one. Whether a given XML editor can rightly be called document-oriented depends at least partially on its support for mixed content, i.e., elements that can contain both elements and text content. Mixed content is used wherever words or phrases within a passage need to be semantically marked up, or formatted, inline. Mixed content, in many ways, is where XML shines in comparison to other data formats. Unfortunately, while InfoPath provides very powerful structural editing constructs, it does not currently support the use of mixed content. The one exception and this may just suffice for many use cases is InfoPath's support for "rich text" editing. The vocabulary used for embedded rich text is XHTML, to varying levels of restriction ranging from plain (no formatting) to rich (font formatting, paragraphs, lists, hyperlinks, etc.). Despite lack of general support for mixed content, the embedded XHTML editor makes it conceivable to use InfoPath as a frontend to a web content management system. 10.2.3.3 Bundled versus standalone development toolVendors of some XML editors provide a development tool that helps speed the development of XML editing solutions, in whatever format they're represented. To varying extents, you will need to rely on the development tool at least to get started developing editing applications. Unless the vocabularies and formats used to define a solution are fully documented and/or standardized (i.e., they use XForms), you should count on spending some time with the development tool. InfoPath is no exception to this rule. It does not support XForms, and neither does it come, at least at the time of this writing, with documentation for every aspect of solution development. Fortunately, in the case of InfoPath, that doesn't mean you have to buy an extra license. On the question of whether the development tool comes "bundled" or "standalone," InfoPath has a unique answer: not only is the form design tool bundled with the run-time form module, but they are one and the same application. This peculiar packaging may make perfect sense from a marketing perspective, but it's potentially confusing from a user's perspective. Fortunately again, InfoPath solutions can be configured such that a form's design can be "protected," so that an end user filling out the form won't accidentally drop into design mode, in which they find themselves editing the controls themselves rather than their values. 10.2.3.4 Declarative versus procedural configurationMost editors allow a certain amount of their behavior to be configured declaratively. For example, an XML Schema is a declarative specification of constraints on the values and structure of instance documents. It can be used to validate a document as it's being edited. And XSLT can be used to describe how the document looks while it's being edited. InfoPath employs both XSD and XSLT within editing solutions. Most editors can also be configured through a procedural scripting interface, such as a JavaScript API (Application Programming Interface). Ideally, scripting will be kept to a minimum used only in cases where the declarative configuration mechanisms do not suffice. For those kinds of customizations, InfoPath provides a complete object model and lets you choose between JScript and VBScript for accessing it.
In addition to using XSD and XSLT, InfoPath allows a remarkable amount of custom functionality to be configured declaratively. The form definition file that's included with every solution allows you to create custom menus and buttons, associating them with named actions from a set of built-in "editing components." You can also specify custom error conditions for business rules that can't be or aren't described in your XSD schema. This too is done declaratively, using XPath expressions, which by the way is much like the approach that Schematron (http://xml.ascc.net/schematron/) takes to validating XML. Finally, InfoPath allows you to declaratively specify a remote submission mechanism, such as:
For other submission mechanisms, such as HTTP POST with application/x-www-form-urlencoded content, you can specify the submission behavior using custom scripting. We'll see an example of this in the second example solution in this chapter. 10.2.3.5 "Mapping" versus "Merging"All XML editing products oriented to end users have the same basic problem to solve. They must somehow translate back and forth between the underlying XML being edited and the friendly editing view that the user sees. They generally have both of the following:
In Word and InfoPath, we have examples of each of the two broad approaches to solving this problem. Word's approach could be characterized as "merging," because its editing view consists of WordprocessingML with embedded custom XML tags from the XML document being edited. It translates between the editing view and pure XML by way of two XSLT stylesheets:
For more information, see "Word's Processing Model for Editing XML," in Chapter 4. On the other hand, InfoPath's approach could be characterized as "mapping" rather than "merging." InfoPath's editing view vocabulary consists of HTML and CSS, as rendered by the Internet Explorer engine. Unlike Word, the editing view itself does not directly contain custom XML tags. Rather, HTML nodes in the editing view are mapped, or bound, to XML nodes in the source document being edited. This is done by way of a single XSLT stylesheet, supplemented as necessary with annotations in the InfoPath namespace. Separate onload and onsave stylesheets are not necessary. The bindings established by the stylesheet specify a complete, round-trip mapping between the source document and the editing view. 10.2.4 InfoPath versus XFormsA discussion of InfoPath in context would be incomplete without reference to XForms, a W3C recommendation for the next generation of web forms. XForms is slated to replace traditional HTML forms altogether in XHTML 2.0. It is completely XML-based, from the vocabulary through which a form's controls are declared to the format of the data as it is submitted back to a web server. InfoPath and XForms have some major similarities:
Despite their similarities, XForms and InfoPath ultimately have different emphases. InfoPath represents a single implementation that runs only on the Microsoft Windows PC platform. Accordingly, it is optimized for usability on that platform. In contrast, XForms is a specification meant to have many different implementations, enabling the interoperability of web forms on a wide range of different clients. Rather than optimizing for a single user interface, XForms abstracts away from the particular device by separating form controls from how they are presented. While InfoPath provides some minimal accessibility features such as tab indexes and access keys, XForms is designed from the ground up for accessibility. Illustrative of this design goal is XForms' requirement that every form control have a label. Despite InfoPath's heavy emphasis on web services integration, it is ultimately not meant to serve as the next-generation web client. Rather, it is designed to thrive in corporate intranet environments, replacing paper forms and supporting enterprise data and content management applications. As a member of the Microsoft Office System, it provides sophisticated offline functionality not addressed by web-based technologies such as XForms. There has been some hubbub over the fact that InfoPath does not support XForms even though in many ways it seems like just the type of application the XForms specification is meant to address. There is a wide range of perspectives one can choose to take on this. Some may decry InfoPath as yet another Microsoft product that chooses to go its own way rather than following the standards. While there may be some validity to this claim, it starts to appear untenable when you consider the actual extent to which InfoPath solutions are based on existing W3C standards, such as XSLT, XSD, and HTML. Still others may side-step the debate altogether, choosing instead to go out and implement an XForms profile that compiles to an InfoPath solution (hint hint), something not entirely inconceivable given the open format of InfoPath's form templates. Ultimately, it's hard not to get excited when products like InfoPath come on the scene, whether they support XForms or not. In either case, the most important electronic asset, our data, remains open. Products like InfoPath and implementations of XForms help to make vendor lock-in a thing of the past. The XForms specification can be viewed at http://www.w3.org/TR/xforms. To learn more about XForms, consider these books:
|
EAN: 2147483647
Pages: 135