4.14 Deploying the Template


There are a number of different ways to deploy XML editing solutions for Word. In this section, we'll look at one possible way to deploy the press release template that works best in a corporate environment. Since deployment is an even bigger topic in the context of Smart Documents, Chapter 5 will cover this topic in greater detail.

So far in this chapter, we have seen the contents (or partial contents, in the case of pr2word.xsl) of four of the press release template's source files:

  • pressRelease.xsd (the press release schema)

  • pr2word.xsl (the onload stylesheet)

  • harvestPressRelease.xsl (the onsave stylesheet)

  • saveDataOnly.xsl (imported by the onsave stylesheet)

There are two more files we need to include (making a total of six): the initial XML template file, New Press Release.xml, and a deployment manifest called manifest.xml. Together, these files help fulfill the generally twofold aim of deployment:

  • Give users a way to create new XML documents (such as a template file to open)

  • Populate the schema library on each user's machine so that the solution will be invoked automatically when opening existing XML documents

Now let's look at New Press Release.xml and manifest.xml in turn to see how they fulfill these goals.

4.14.1 The Initial XML Template File

The New Press Release.xml file, which we mentioned at the very beginning of the chapter, is what the IT department delivers to the PR department. This could be deployed, for example, on a web site or on a local network share. Example 4-12 shows the contents of this file.

Example 4-12. The initial XML template, New Press Release.xml
<?xml version="1.0"?> <?mso-application prog?> <?mso-solutionextension URI="http://xmlportfolio.com/pressRelease"                         manifestPath="\\intra\pr\manifest.xml"?> <pressRelease xmlns="http://xmlportfolio.com/pressRelease">   <company>     <name/>     <address>       <street/>       <city/>       <state/>       <zip/>       <phone/>       <fax/>     </address>   </company>   <contact>     <firstName/>     <lastName/>     <phone/>   </contact>   <date/>   <title/>   <body>     <para/>   </body> </pressRelease>

This document consists of an empty "skeleton" instance of our schema. All of the expected elements are present, but the leaf nodes are empty. They have not been filled out yet. When a user who already has the press release template installed in their schema library opens this document, the pr2word.xsl stylesheet is applied to it, producing the press release view we saw originally in Figure 4-1.

The key line that concerns us here is the mso-solutionextension PI:

<?mso-solutionextension URI="http://xmlportfolio.com/pressRelease"                         manifestPath="\\intra\pr\manifest.xml"?>

This processing instruction doesn't add any value for users who already have the press release template installed on their machine. For users who don't, however, it instructs Word to retrieve the manifest file for this "solution." (The URI pseudo-attribute contains the target namespace URI for the schema.) In this way, Word can automatically install the necessary files into the machine's schema library without manual intervention. It automatically retrieves the manifest file located at \\intra\pr\manifest.xml after confirming from the user that this is okay.

4.14.2 The Manifest File

The manifest file contains a reference to the schema and onload stylesheet files for the press release template. It could also include other files, such as Smart Document code, secondary view stylesheets, etc. Example 4-13 shows the manifest file for the press release template, manifest.xml.

Example 4-13. The manifest file for the press release template, manifest.xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <manifest xmlns="http://schemas.microsoft.com/office/xmlexpansionpacks/2003">   <version>1.0</version>   <uri>http://xmlportfolio.com/pressRelease</uri>   <solution>     <solutionID>sdfa097sdfa0</solutionID>     <type>schema</type>     <alias>Press Release</alias>     <file>       <type>schema</type>       <version>1.0</version>       <filePath>\\intra\pr\pressRelease.xsd</filePath>     </file>   </solution>   <solution>     <solutionID>9a871342098vxcasdf</solutionID>     <type>transform</type>     <alias>Elegant</alias>     <documentSpecific>false</documentSpecific>     <context>http://schemas.microsoft.com/office/word/2003/wordml</context>     <file>       <type>primaryTransform</type>       <version>1.0</version>       <filePath>\\intra\pr\pr2word.xsl</filePath>     </file>   </solution> </manifest>

When Word installs this "XML expansion pack," it retrieves each of the files referenced within the manifest. In this case, it downloads the pressRelease.xsd and pr2word.xsl files and installs them into the schema library.

Ideally, the manifest would include all the files of our template, not just the schema and onload stylesheet files. This would allow for a central point of deployment. However, as of this writing, we have not yet figured out a way to reference onsave stylesheets installed in the schema library. Recall the relevant line from our onload stylesheet, pr2word.xsl:

  <w:saveThroughXSLT w:xslt="\\intra\pr\harvestPressRelease.xsl"/>

The w:xslt attribute must point to the file location of an onsave stylesheet. According to the WordprocessingML schema, the w:saveThroughXSLT element can also have a w:solutionID attribute, which sounds like precisely what we would use to reference a stylesheet installed in the schema library. Unfortunately, Microsoft has not documented how to go about making that reference, and everything we've tried so far has failed. For that reason, the manifest for the press release template does not install the onsave stylesheet. Instead, the stylesheet must remain in a shared location to be accessed directly each time it is used. In this case, that location is \\intra\pr\harvestPressRelease.xsl.



Office 2003 XML
Office 2003 XML
ISBN: 0596005385
EAN: 2147483647
Year: 2003
Pages: 135

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net