InfoPath: My Rules of Engagement

Okay, Microsoft Office System InfoPath Team. I finally built an InfoPath form that I can use. Oh, feel free to console yourselves that I am some… whatever person you condescend to… But the new concepts that I needed to learn you guys probably already have mentioned in some Contoso.com demo in a green-colored comment on line 3215 in a sea of JavaScript code. The concepts:

• Data-driven conditional formatting. This one is an easy one to get. So this one gets listed first. We get a gee-whiz Wally Cleaver rant in “Collapsible Sections” on the InfoPath Team Blog. Or we can get some serious Knowledge in “How to use a script or a secondary data source field for conditional formatting in InfoPath 2003.” The danger here is that you can ‘pollute’ your ‘pure’ XML data with user interface ‘meta’ data. I find myself using an attribute like linksVisible to allow InfoPath to act something like an editable tree view. Feels dirty.
• Calculated Elements/Attributes. Another ‘dirty’ move feels like storing calculated data in an XML file—data based on other data in the same file. This is definitely not recommended for old-school database management systems so I am wary of doing this for InfoPath—and I do this being fully aware of the Expression Box. When, say, you want to have a Hyperlink control in your form that is ‘calculated’ (or concatenated) with data from other fields, an Expression Box is no help (and unbound controls are not welcome by InfoPath 2003 SP1).
• Use Rules never* code.* This is a concept made up by me for me. I expect InfoPath to be butt-easy (easy like trying to figure out where to put your posterior in a chair). I have too many C# obligations to write code for an InfoPath form. I fully expect the Microsoft Office System InfoPath Team not to slowly drift into depending too much on code to get serious stuff done. I was almost tempted to use code to submit multiple “Rich Text” nodes to a Web Service. And I am still a little tempted to use VSTO to cache secondary data sources from a Web service in the InfoPath form. Very little.
• Building forms from XSD files. InfoPath is teaching me quite a bit about XSD. I enjoy developing a form and it’s XSD at the same time. I enjoy making design changes by selecting Tools > Convert Main Data Source—again and again at design time. Most of the enjoyment comes from finding a use for the XSD editor in Visual Studio. This is the way of developing InfoPath solutions—almost entirely by declarations—no JavaScript and no VSTO. Designing a form from a formal and external XSD also prevents that stupid my: namespace from showing up—I’ll take ns1: any day—but tomorrow we need to be able to declare our own namespaces without digging inside of the XSN archive.

rasx()