Rich Office Client Applications

In the last several years, it's become fashionable to talk about the creation and use of "RIA"s, a new acronym for "Rich Internet Applications", not to be confused with "rich client" or "smart client" applications. (The distinctions between the three are marginal at best, but never has technical accuracy mattered much in the selection and use of buzzwords or new three-letter acronyms.)

The driving force behind this new wave of client applications is simple: users are tired of the fairly limited user interface capabilities of HTML, even when coupled with client-side scripting, a la AJAX. Still, developers don't want to lose the benefits of server-side deployment, since going around to every user's PC to install a traditional client-side executable, the so-called "fat client," is at best, impractical, and at worst, absolutely impossible. So a new, hybrid form of client application was born, one which executes mostly on the client tier, thus taking advantage of local processing power and (hopefully) avoiding too many network traversals, but continues to be updated in some fashion from the server. Thus was born the "rich client". Or "smart client". Or "rich internet application". Or whatever.

What technology to use for the rich client is a subject wide open to debate and discussion. Some prefer the Eclipse Rich Client Platform (RCP), since it already incorporates much of the tools and technology necessary to manage automatic updates to the client-side codebase, while others prefer AJAX, making it easier to morph existing HTML-based servlet/JSP applications into richer clients. Still others have been effusive in their praise of Adobe's Flash player, and the corresponding Flex development kit, citing the near-ubiquity of the Flash player in almost every user's browser.

One interesting aspect that continues to elude even the savvy Java developer is another client platform that's already present on nearly every user's desktop, one which provides an amazing amount of power and flexibility in its user interface options, and provides a familiar user-interactive style that undergoes intensive study with every release. I speak, of course, of the Microsoft Office platform: Word, Excel, Outlook, PowerPoint, and InfoPath.

Office Extensibility

Large forests have been clearcut in order to provide the paper for all the books, magazines, articles and papers on how to extend Office, and there's not nearly enough room on the InfoQ webserver-much less this article-for all the ways that a developer can extend and/or use Office to build applications. Those seeking more knowledge on Office itself are strongly encouraged to check out some of the resources at the end of this article; Office's extensibility includes the ability to create custom toolbars inside of the Office applications, to extend Excel by adding new formulas, and more. For now, however, we're going to focus on one of the more obvious UI elements of Office 2003¹: smart tags.

Smart Tags

A smart tag is that purple dotted line that appears under a word in Word, or the purple right triangle that appears in a cell in Excel, and the little "i" button that shows up when the mouse hovers over it, allowing you to click and drop some kind of context menu related to that word. For example, in Word when I type in a phone number, like 916-555-1212, the drop down menu contains "Add to Contacts", allowing me to add this phone number to Outlook's address book. See Figure 1, below, for what it looked like in Word as I typed this paragraph:

Essentially, a smart tag works by recognizing certain text within the document, and when recognized, makes the icon and drop-down menu available. This is known, respectively, as the "recognizer", and its associated set of "actions"; more on this later. This particular smart tag, which ships with Office and is installed (but not turned on) by default, is enabled by turning on the "Telephone Numbers" SmartTag functionality, found in the "AutoCorrect" dialog of Word or Excel ("Tools" | "AutoCorrect Options", then select the "SmartTag" tab):

Notice how the Telephone Number smart tag is selected; clearing the check box will, obviously, disable that behavior for that particular SmartTag. Users can turn off all smart tags by clearing the "Label text with smart tags" checkbox.

When using smart tags from Excel, PowerPoint, or any of the other Office applications, the exact behavior and configuration is slightly different-for example, as we'll see in a bit, Excel's configuration dialog is slightly different, and as already mentioned, the smart tag's visual cue is a small triangle in the corner of the cell, rather than the purple-dotted-line we see in Word.

Smart Tag Implementation

Smart tags can be built via two means, one that offers less power but is far simpler, the other involving much more code and development time but provides much more flexibility. While in some respects it would be a more interesting/exciting example to show writing a smart tag DLL (the second option) in .NET using the Visual Studio Tools for Office (aka VSTO) package, there's a simpler way to get smart tags into Office, and it happens to suit Java quite nicely: create a "Smart Tag List" XML file, and simply store it in the proper location on the user's hard drive. (For more information on how to create a smart tag in a .NET language, see Visual Studio Tools for Office by Carter and Lippert, or download the VSTO 2005 Second Edition bits.)

In this particular scenario, we're going to take the traditional Spring "JPetStore" sample application, running inside of Tomcat (on my local machine-obviously this could and likely will be on a public server someplace in a real-world scenario), and we're going to teach Excel how to recognize the JPetStore Product and Item ID numbers. When recognized, the smart tag will display a context menu offering the user the opportunity to bring up a browser with the appropriate Product or Item displayed in the browser page-in essence, giving them an opportunity to verify that they're talking about the right pet² . In a real-world scenario, this tag would likely be in a nicely-formatted Excel document template for users to use when ordering the pets online, or for salespeople to use when interacting with customers.

Cutting quickly to the chase, in order to make it easier to create smart tags, Microsoft has created a single smart tag that will recognize XML files in a well-known location that follow a particular schema (described in the Smart Tag SDK documentation). This is known formally as the Microsoft Office Smart Tag List (MOSTL), and the XML documents used are called "smart tag lists". To create one is fairly straightforward; assuming a normal Office installation, in the C:\Program Files\Common Files\Microsoft Shared\Smart Tag directory, there is a subdirectory called "LISTS", in which we will create a standard XML document that looks something like the following³ :

Ignoring for a moment the complexities of the regular-expressions described here to recognize phone numbers, the smart tag list file is pretty straightforward:

• Notice the use of the two namespaces; these are for Office 2003, and those tags wishing to be available to Office XP use a different namespace URI (described in the documentation). The documentation also suggests that the "FL" prefix is mandatory, and all the examples use it. Even if it's not required, it's highly suggested to continue to use it, if for no other reason than consistency.
• <FL:name> is self-explanatory, and is required. <FL:lcid> describes the locale for which this smart tag is enabled, and is optional (meaning it's available for all locales). <FL:description> is required. <FL:updateable> and <FL:autoupdate> are used to allow the smart tag list to update itself, something we'll use in a bit.
• <FL:smarttag> describes each smart tag, which in our case will consist of recognized text and actions, rather than the regular expression support seen above. The "type" attribute must contain a unique namespace, however, and it must be in the form above, meaning it must be a URI with a "fragment" suffix (the portion following the "#" character). Forgetting the fragment qualifier will invalidate the tag, which is frustrating, because Office won't tell you if the smart tag list file is wrong-it just simply won't show up in the Smart Tag dialog.
• <FL:caption> is what will be displayed in the drop-down menu.

Not shown above, what we'll use is <FL:terms>, which will contain text terms for the smart tag to recognize, and <FL:actions>, which will describe the actions available in the drop-down menu. So, putting this together, what we see for the first cut of our JPetStore smart tag looks like:

Notice how here we've listed two smart tags, one to recognize a subset of the JPetStore Product IDs, and the other to recognize a subset of the JPetStore Item IDs. Each then opens a browser window to the appropriate page in the JPetStore web application, passing the term recognized in place of the "{TEXT}" placeholder in the URL. Be careful when assigning values to the "id" attribute of the "action" element; any duplication here will silently fail, essentially creating a "last one wins" solution.

Save this file to the subdirectory mentioned above, but make sure no Office program is running, including Internet Explorer-the smart tag lists are read once on startup, and shared across any running instances of Office. When we fire up Excel, then, our smart tag will be listed in the Smart Tag tab of the AutoCorrect dialog, and once checked, will recognize the entered Product or Item IDs in the spreadsheet and offer the user the chance to visit the appropriate Web page inside the running web application.

One thing that's painfully obvious about the simple XML file above is that it not only does it only have a small subset of the available Product and Item IDs, it currently has the Product and Item IDs hard-coded inside the smart tag list itself. Neither of these will do for a real-world scenario. We want the smart tag list to update itself with whatever the latest Product and Item IDs are available on the server, which fortunately is fairly straightforward to do: we just need to change the smart tag list to include some update information, including a URL for the smart tag to hit, and then provide the appropriate resource inside the web application to provide an updated, dynamically-generated smart tag list file.

To do that, we change the original smart tag list file just a bit:

Now, every five minutes (as given by the <FL:updateFrequency> element), Office will issue an HTTP POST request to the URL given by the <FL:updateURL> element. The resource on the other end of the HTTP request must look something like:

(The JSP syntax is used here for simplicity; this could easily be a Struts or Spring MVC view, so long as it sets the MIME type of "text/xml".) This then tells Office to download the contents of the <FLUP:smarttaglistdefinition> element, which will contain the new smart tag list definition. Note that the <FLUP:checkpoint> element here corresponds to the <FL:lastCheckpoint> element in the smart tag list definition-if the checkpoint on the server is greater than the lastCheckpoint on the user's machine, an update occurs. Here, we've hard-coded the value to be 400 (which is obviously greater than the 0 we had in the smart tag list definition before), but in a real-world application this would likely be an incrementing value, changing each time the product IDs or item IDs changed inside the running container.

Summary

We've only really scratched the surface of just what smart tags are capable of, and various ways we can integrate them together with Java applications or services. If we write a custom smart tag, for example, the tag could easily query the server directly (via an RPC call to the Spring container, or perhaps by examining data held locally on the server and updated via an externally-driven process) for current information on the item: inventory, pricing, and so forth.

Office also has numerous other extension capabilities, such as "research panes", in Word: the pane to the right of the document in Word can be used to allow users to type in text "to look up in a variety of research and reference services", which are essentially services which implement a particular WSDL-defined interface. Obviously these services need not be written in .NET, but could easily be JAX-WS services running inside of any J2EE container.

Some developers will balk at the notion of using Office, simply because Office is a proprietary product from Microsoft, and requires licensing for use on end-users' machines. While part of the point of using Office is because users will often have it installed already, particularly in business environments, Microsoft also makes available free, unlicensed "viewers" for Word, Excel and PowerPoint, allowing users to "open, view, and print" documents. In some cases (such as sending users a receipt for an online purchase), a read-only view of the document, particularly one that's easily saved, is sufficient.

Finally, some developers will point out that much of these features and capabilities are also available in OpenOffice, an open-source, platform-portable competitor to Office 2003 and Office 2007. No argument with that point is intended, and if the user base in question already has OpenOffice installed, then it should certainly be considered in much the same way we're discussing Office here. With all due respect to the OpenOffice developers, however, Microsoft has a great deal of experience in building Office to be extensible, and more importantly to the developer, there is a huge body of knowledge and samples to draw from.

Regardless of which office productivity platform chosen, using your users' already-installed software base as the basis for a rich client application can lead to some incredibly powerful solutions, and some incredibly happy users. Although Office may not be the right client solution for all projects, it's a fair bet that for a certain class of systems, using Office as the client will be a far cry easier than trying to build something entirely from scratch in Swing, SWT, or AJAX.

Resources

Microsoft Visual Studio Tools for Office Second Edition Runtime (VSTO 2005 SE) (x86), at http://www.microsoft.com/downloads
/details.aspx?familyid=f5539a90-dc41-4792-8ef8-f4de62ff1e81&displaylang=en is the latest-and-greatest VSTO package, for use with Office 2007. Notice that this is just the runtime; to build VSTO extensions, you need the SDK, below.

Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System, at http://www.microsoft.com/downloads/details.aspx?familyid=
5E86CAB3-6FD6-4955-B979-E1676DB6B3CB&displaylang=en is the actual VSTO 2005 SE SDK itself (despite the name differences between the two web pages).

Office 2003: Smart Tag SDK, at http://www.microsoft.com/downloads/details.aspx?familyid=
c6189658-d915-4140-908a-9a0114953721&displaylang=en is the download page for the Smart Tag SDK, of which the principal benefit is the documentation; the docs can also be found online, at http://msdn2.microsoft.com/en-us/library/bb190881(office.11).aspx . Of particular interest is the "Microsoft Office Smart Tag List" section, which documents fully the XML format used above.

Visual Studio Tools for Office: Using C# with Excel, Word, Outlook, and InfoPath, by Carter and Lippert, Addison-Wesley. Highly recommended text by the guys responsible for VSTO itself.

Building Microsoft Office Applications, by .... Somewhat dated, this text talks more about building old-school Visual Basic for Applications (the predecessor to VSTO) extensions and applications, but it does offer some interesting insights into the world of Office applications, particularly the various "use cases" and solutions he cooks up.