Later in the book we’ll discuss InfoPath features in greater detail, but for now, here’s a summary of some of the key XML technologies and development approaches.
InfoPath applies a range of XML technologies recommended by W3C that we noted in the Introduction. This is a first for Microsoft, and thus a first for you as an Office developer. Additionally, InfoPath makes use of XML processing instructions and namespaces. There are also methods for accessing the XML document using the InfoPath Object Model (OM).
The following table outlines the use of some XML standards applied in InfoPath.
Name |
Description |
---|---|
XML |
XML is the format that underlies an InfoPath form. |
XSLT |
XSLT is a specification for transforming XML files. It is the format of the View files that are produced when a form is designed. The transform creates an XHTML document that is displayed in the user interface. |
XML Schema |
XML schemas provide the underlying structure of the XML form and are the primary means of data validation. XML Schema is used to define the structure of the form definition. See Appendix A. |
XHTML |
XHTML is the XML-conformant version of HTML. In InfoPath it is used to display formatted text in rich text controls. |
XPath |
XPath expressions are used to bind controls to forms. XPath is also used in data validation, conditional formatting, and expression controls. |
DOM |
The Document Object Model is primarily used in scripts to access the contents of the form document, but it can be used with any XML document in the InfoPath environment. |
XML Signature |
XML signatures are used to digitally sign InfoPath forms created by. Forms can contain multiple signatures. |
Although InfoPath supports a wide range of XML features, there are some limitations or other constraints in this release that you should note. InfoPath 2003 does not support the following:
XML Schema constructs xs:any, xs:anyAttribute
abstract and substitutionGroup attributes on elements and types
XSL Formatting Objects (XSL-FO) for the presentation of XML data
Import or inclusion of arbitrary XSL files
XML-Data Reduced (XDR) or Document Type Definition (DTD) for defining schemas
Digital signing of parts of a form
XML processor versions earlier than Microsoft XML Core Services (MSXML) 5.0
We’ve already noted a bit of a bias on the part of Microsoft toward code to extend the functionality of forms. This shouldn’t be surprising, because Microsoft and therefore many developers of Microsoft applications have come to XML quite recently and have come from a code-based programming background. The structures found in XSLT, for example, can often seem obscure and foreign. As XML becomes a more prominent component in Office applications, we may come to see that declarative programming approaches are increasingly common.
When you modify InfoPath forms, by setting values in design mode or by editing values in the form files with a text editor, you are customizing the form declaratively. When you alter a form programmatically, you are writing code using JScript or VBScript following the InfoPath Object Model.
As we’ve mentioned already, there are often two or three ways to achieve the results that you want.
Declarative development involves modifying one or more XML files, including:
XML Schema that defines the structure of the form
XSLT files that define the views on a form
XML form definition file or manifest that specifies the overall structure of a form
Why might you want to use the declarative approach? Well, one reason might be that you prefer it to programmatic development in certain cases, but there are times when InfoPath leaves you few options. Here are just some occasions when declarative programming is either recommended or necessary:
Custom form merging
New menus and toolbars
Schema and other upgrade modifications
Custom transform templates
Adding processing instructions to XML data files
Exporting form data to custom Excel schemas
Creating custom task panes and their associated files
You can customize a form programmatically by writing scripting code to perform a variety of functions. The main components that involve programmatic interaction are listed in the following table.
Component |
Description |
---|---|
Object model |
Type library composed of collections, objects, properties, methods, and events that give you programmatic control of the environment. |
Data validation |
XML schemas, expressions, and scripting code used to validate and constrain the data that users are allowed to enter in a form. |
Event handling |
Event handlers that respond to form loading, changes to content, view switching, and implement custom form submission. |
User interface |
Customizable interface components including menus and toolbars with related buttons, command bars, and a task pane. |
Editing controls |
Controls that include collections, optional items, text lists, and fields. |
Error handling |
Event handlers, OM calls, and form definition file entries used to handle errors. |
Security |
Security levels that restrict access to the OM and system resources. |
Data submission |
Predefined functions that can be used to implement custom posting and submission. |
Business logic |
Scripts to implement editing behavior, data validation, event handlers, and control of data flow. The logic can also access external COM components. |
Form integration |
Integration with other Office applications and SQL Server, SharePoint, or XML Web services. |
InfoPath includes the Microsoft Script Editor IDE (Integrated Development Environment) creating and debugging code, together with programming languages that you can use to extend your applications. However, while other Office applications use Visual Basic for Applications (VBA) as their primary programming language, InfoPath uses two scripting languages—JScript and VBScript.
JScript is an interpreted, object-based language that is the Microsoft implementation of the ECMA 262 language specification. VBScript is a subset of the Microsoft Visual Basic. However, while you have a choice of languages, you cannot mix the two languages in a single form.
You can set the default language for a form in the design mode interface. When you open Microsoft Script Editor (MSE) from InfoPath in design mode, the MSE code editor appears and the form’s default scripting file opens in the code editing window.
In debug mode, you can use all of the debugging features that MSE provides, including using breakpoints, stepping through program statements, and viewing any of the debugging windows.