Export (0) Print
Expand All
Expand Minimize

Customizing Microsoft Content Management Server 2002 Authoring Connector

Content Management Server
 

Microsoft Corporation

March 2003

Applies to:
    Microsoft® Content Management Server® 2002

Summary: Microsoft Content Management Server (MCMS) 2002 Authoring Connector allows authors to quickly create and update content on a Web site, with minimal knowledge of the site architecture or structure, using tasks predefined by a site administrator. Learn best practices and solutions to common challenges when deploying MCMS Authoring Connector. (37 printed pages)

This document also contains a description of, and a link to, the Publishing Task Editor. The Publishing Task Editor enables easier creation and manipulation of Publishing Task files, which are used with the MCMS 2002 Authoring Connector. The Publishing Task Editor ensures that any files created or modified conform to the requirements of the Authoring Connector. This is an unsupported, untested tool. Documentation and the link to the tool are at the end of this article.

Contents

Introduction
Reader Guidance
MCMS 2002 Authoring Connector Architecture and Components
Preserving Word 2002 Formatting and Styles in MCMS 2002 Templates
Using Authoring Connector in a Multilingual Environment
Customizing the Publishing Task List
Using Publishing Event Handlers with Authoring Connector
Authoring to Multiple Placeholders
Securing Office Connector
Appendix A
Publishing Task Editor

Introduction

MCMS 2002 introduces new functionality that enables authors and other content contributors to submit content to targeted MCMS servers, with minimal effort, directly from Microsoft Word 2002 (part of Microsoft Office XP). Authoring Connector is a stand-alone tool that can be installed on the client computer, without the need for Site Manager or other MCMS 2002 components. Using Authoring Connector, authors can quickly create and update content on the site, with minimal knowledge of the site architecture or structure, using tasks predefined by a site administrator. This document shows best practices and addresses common concerns that may rise during the use and/or integration of Authoring Connector into the existing environment.

Business Benefit

In today's world, knowledge workers are required to be proficient in an ever-increasing number of tools and applications. In most cases, the introduction of new systems in an organization results in additional tools that knowledge workers have to learn. Authoring Connector is intended to minimize the impact on MCMS content contributors by integrating with Word 2002. Word 2002 is widely used. Therefore, the extension of the capabilities of Word to publish an MCMS site can be very intuitive. Authoring Connector can also be beneficial in situations where relatively simple and/or repetitive updates are required, using content based primarily in Word documents. Authoring Connector simplifies content contribution tasks, thereby increasing productivity, while decreasing the amount of the time that may otherwise be required to train content authors.

Reader Guidance

This document contains information geared toward Web site managers and Web site architects. The primary focus of this document is to present solutions and best practices for common challenges that ite architects may face while deploying and/or integrating Authoring Connector into an MCMS 2002 environment. This document does not explain basic MCMS concepts; therefore, some understanding of basic MCMS concepts is expected. In addition, this document assumes knowledge of ASP.NET and the MCMS application Publishing API for the sample code included in this document. For more information about the MCMS architecture and MCMS concepts, see Microsoft Content Management Server 2002 Help.

MCMS 2002 Authoring Connector Architecture and Components

Authoring Connector contains both client and server components. While the Authoring Connector client component needs to be installed on each computer that will use Authoring Connector, the server requires no additional configuration, and should already have all software components installed by default. Word 2002 needs to be installed on client computers prior to installation of MCMS Authoring Connector client components. Authoring Connector client components are included on the MCMS 2002 product CD, and can be placed on a shared network drive for easy installation. Additional product licenses are not required, since all clients accessing the MCSM 2002 server are covered by the server license.

The following figure shows the high-level architecture requirements for MCMS Authoring Connector.

Figure 1. High-level architecture requirements for MCMS Authoring Connector

By using a client system with Word 2002 and Authoring Connector, an author can publish any Word document from local drives or shared storage to one or more MCMS Web sites. The author has also the option of selecting only a subsection of the document and submitting it instead of the entire Word document. To the author, Authoring Connector is represented as a simple-to-use wizard that efficiently guides the user step-by-step through the publishing process. When a document is published, the information about where it has been published is saved in the Word document properties for future reference. The next time the author attempts to publish the document, this author is presented with the option of updating an existing posting. The Word document remembers the last location and server where it was previously published. In the document, Authoring Connector creates two custom properties—CmsServerUrl and CmsPostingGuid. The following table lists the functionality of these properties.

Property Name Functionality
CmsServerUrl Contains the full path to the location of the sever side component. Do not modify the path unless the server name has changed or the location of the server side component on the server has changed. By default the value should look like the following: http://<servername>/mcms/MCMS/OfficeWizard/oc.aspx. Only system administrators should consider changing this value.
CmsPostingGuid Contains the posting GUID where the content of the document has been posted. Do not change the value of this property unless the posting has been deleted and recreated. Only system administrators should consider changing this value. Deleting this value will prevent Authoring Connector from finding the posting where this document was published.

These two properties will be available to the Word document, regardless of where the document is located on your Web site. For example, the Word document can be copied and sent through e-mail. The addressee will be able to update the document, and consequently update the same posting on the MCMS site. Another common use would be to store the original of the Word document in Microsoft® SharePoint® Portal Server, SharePoint Team Services, or another document management solution. Anyone editing the document would be able to republish it to the proper location.

The following figure provides a more detailed view of the client/server interaction of the different components involved in Authoring Connector.

Figure 2. Client/Server interaction with MCMS Authoring Connector

As mentioned previously, the Authoring Connector wizard guides an author through the selection of a publishing task, and through setting the properties of the content to be published. During the process, the wizard interacts with the MCMS security service, the OC.aspx file, and the MCMS Publishing API. Upon completion of the wizard, Authoring Connector creates a new posting and then copies the content from the Word document into all available Office HTML placeholders defined on the target posting. Alternatively, Authoring Connector updates the existing posting by copying content from Word into all available Office HTML placeholders. Note that there is no direct interaction with the template file (.apsx file on the file system) and Authoring Connector. Therefore, any custom code that may be included in the template file will not be executed. This may be the desired behavior in situations where a template programmer requires a different set of operations to be performed during Web authoring and/or authoring from Word. Custom code, which is to be executed when both Office and Web authoring actions are performed, should be integrated using the Publishing API event handlers in the global.asax file, or in a custom HTTP module. For information about enabling and customizing the Publishing API event handlers for Authoring Connector, see "Using Publishing Event Handlers with Authoring Connector" in this document.

Authoring Connector Wizard

The Authoring Connector user interface is contained in the OC.aspx file. The OC.aspx file is an ASP.NET-based page that is essentially a collection of APS.NET-based Web forms. Such an approach provides great flexibility and a unified interface on all clients. Most updates and changes to the user interface or Authoring Connector logic need to be performed only one time on the server.

From a performance standpoint, you should limit the number of objects (channels and postings) in each channel to no more than 300. If a channel contains more than 300 postings, the Authoring Connector wizard may require a more significant amount of time and resources to render the browse tree on the channel selection screen.

Note   This document discusses potential modifications to the OC.aspx file. However, before proceeding, you should understand that modifications to the OC.aspx file are not supported. Any changes to the OC.aspx file may be lost when applying service packs, hot fixes, or upgrades, and may have to be reapplied. If you are considering altering the OC.aspx file, back up the original and modified version of the OC.aspx files before proceeding with any software update. After the software update is complete, carefully examine the new OC.aspx file and reapply your modifications in the appropriate sections. It is recommended that all custom logic be kept in a separate class or file for ease of integration and transition.

Preserving Word 2002 Formatting and Styles in MCMS 2002 Templates

One of the initial challenges most site administrators face is the preservation of Word document formatting and styles in the resulting MCMS Web page. It is generally recommended that styles and formatting selections be set in the templates used on the site, in order to maintain consistent formatting and styles across the site. However, there may be situations when you want to give other authors direct control over the visual representation of the content. When dealing with Word documents you have to account for two different types of styles—inline styles and document styles. Inline styles, as the name suggests, are stored inline with the text to which they are applied. Document styles are stored in the header of the document and can be applied and changed globally. Therefore, the approach to represent them in MCMS templates differs as well.

There are a few limitations when a Word document is translated into HTML styles. For example, it may be challenging to get an image aligned in the middle of a two-column paragraph and have the text flow around it on both sides. However, such complex formatting is relatively easy to achieve in Word 2002. Office authors should be trained and have their expectations set appropriately. Not all the content on an MCMS page will be reproduced exactly as viewed in Word.

Note that Office authors can submit content using any template, and into any channel to which they have rights, even if the templates are not designated as Word authoring templates and may not contain OfficeHtmlPlaceholder and/or OfficeAttachentPlaceholder. In such cases, content is simply inserted into the first available HtmlPlaceholder, and the source document is uploaded into the first available AttachmentPlaceholder. Keep in mind that submitting content through templates that have not been designed for Authoring Connector may yield unexpected results. Setting up publishing tasks properly and providing author training is very important, as it will help circumvent many issues that may arise from improper use. For information about restricting an author's access to specific, predefined tasks, see "Customizing the Publishing Task List" in this document.

The following table summarizes the expected behavior for different placeholder permutations. Column one represents the number of placeholders of a particular type. In the first column, 1+ represents one or more placeholders, and 0 represents that no placeholders of that specific type are defined. The second column represents the placeholder type. The third column represents the number of placeholders of this specific type that will be targeted if content is submitted using Authoring Connector. The Result column indicates the expected behavior in detail.

Number of placeholders Placeholder Type Targeted
Result
1+ OfficeHTML All All OfficeHTML placeholders will contain the submitted content. Attachment of the source document will be uploaded to all OfficeAttachment placeholders.
1+ OfficeAtt All All OfficeHTML placeholders will contain the submitted content. Attachment of the source document will be uploaded to all OfficeAttachment placeholders.
1+ HtmlPlaceholder None All OfficeHTML placeholders will contain the submitted content. Attachment of the source document will be uploaded to all OfficeAttachment Placeholders.
1+ AttachmentPlaceholder None All OfficeHTML placeholders will contain the submitted content. Attachment of the source document will be uploaded to all OfficeAttachment placeholders.
1+ OfficeHTML All All OfficeHTML placeholders will contain the submitted content. Attachment will be uploaded to the first available AttachmentPlaceholder.
0 OfficeAtt - All OfficeHTML placeholders will contain the submitted content. Attachment will be uploaded to the first available AttachmentPlaceholder.
1+ HtmlPlaceholder None All OfficeHTML placeholders will contain the submitted content. Attachment will be uploaded to the first available AttachmentPlaceholder.
1+ AttachmentPlaceholder First one All OfficeHTML placeholders will contain the submitted content. Attachment will be uploaded to the first available AttachmentPlaceholder.
0 OfficeHTMLl - First HtmlPlaceholder on the page will contain the submitted content. Attachment of the source document will be uploaded to the first AttachmentPlaceholder.
0 OfficeAtt - First HtmlPlaceholder on the page will contain the submitted content. Attachment of the source document will be uploaded to the first AttachmentPlaceholder.
1+ HtmlPlaceholder First one First HtmlPlaceholder on the page will contain the submitted content. Attachment of the source document will be uploaded to the first Attachment placeholder.
1+ AttachmentPlaceholder First one First HtmlPlaceholder on the page will contain the submitted content. Attachment of the source document will be uploaded to the first AttachmentPlaceholder.
0 OfficeHTML - First HtmlPlaceholder on the page will contain the submitted content. No attachment will be uploaded.
0 OfficeAtt - First HtmlPlaceholder on the page will contain the submitted content. No attachment will be uploaded.
1+ HtmlPlaceholder First one First HtmlPlaceholder on the page will contain the submitted content. No attachment will be uploaded.
0 AttachmentPlaceholder - First HtmlPlaceholder on the page will contain the submitted content. No attachment will be uploaded.
0 OfficeHTML - First AttachmentPlaceholder on the page will contain the submitted content. No content will be uploaded.
0 OfficeAtt - First AttachmentPlaceholder on the page will contain the submitted content. No content will be uploaded.
0 HtmlPlaceholder - First AttachmentPlaceholder on the page will contain the submitted content. No content will be uploaded.
1+ AttachmentPlaceholder First one First AttachmentPlaceholder on the page will contain the submitted content. No content will be uploaded.
0 OfficeHTML - First HtmlPlaceholder on the page will contain the submitted content. Attachment of the source document will be uploaded to all OfficeAttachmentPlaceholders.
1+ OfficeAtt All First HtmlPlaceholder on the page will contain the submitted content. Attachment of the source document will be uploaded to all OfficeAttachmentPlaceholders.
1+ HtmlPlaceholder First one First HtmlPlaceholder on the page will contain the submitted content. Attachment of the source document will be uploaded to all OfficeAttachmentPlaceholders.
0 AttachmentPlaceholder - First HtmlPlaceholder on the page will contain the submitted content. Attachment of the source document will be uploaded to all OfficeAttachmentPlaceholders.

The setting that will affect the styles and formatting behavior is the Formatting property of the OfficeHtmlPlaceholder or HtmlPlaceholder definition, as shown in the following figure. See the HtmlPlaceholderDefinition.SourceFormatting enumeration in the HtmlPlaceholderDefinition class (located in MCMS 2002 Help) for information about the formatting flow, text markup, and HTML styles that are used with different settings.

Figure 3. Microsoft® Visual Studio® .NET property grid for OfficeHtmlPlaceholder and HtmlPlaceholder

Inline Styles

To use Set formatting property to
Inline styles FullFormatting
Bold, Italics, and so on TextMarkup, TextMarkupAndHtmlStyles

An inline style is created when a user selects a section of the document and assigns formatting changes—for example, a font size and font color. The definition of the style encapsulates the selected content and therefore can be represented in HTML code. The resulting HTML will be rendered properly in the placeholder without any additional effort. A template designer has the control over allowing or excluding inline styles in each placeholder in the template. In order for inline styles to be represented properly in an MCMS template, the corresponding OfficeHtmlPlaceholder definition should be set to allow FullFormatting. If other formatting is selected, inline styles may be partially or fully lost in the resulting placeholder. Setting the formatting property to TextMarkup will allow only a subset of inline styles to be shown. For information about what a subset of inline styles can be used for, see the HtmlPlaceholderDefinition.SourceFormatting enumeration in MCMS 2002 Help.

Note   In some cases, the resulting HTML representation may not look exactly the same as the Word 2002 document. This may be caused by a different implementation of style sheets in different browsers and/or user-defined settings in the browser options.

Document Styles

To use Set formatting property to
Document styles FullFormatting, TextMarkupAndHtmlStyles, HTMLStyles

Document styles can be created and selected from the styles and formatting toolbar or side bar. The document style information is stored in the header of the Office document and a reference to a style is enclosed around the selected content. The document style information in the document header is not carried over by Authoring Connector. However, an effective technique for preserving the styles is to have a corresponding cascading style sheet in the MCMS template. In other words, while the name of the style is still wrapped around the appropriate content, the intended formatting cannot be applied unless the style is defined in the template as well. Fortunately, in most cases, organizations have corporate Word templates defined. In such cases, the best practice is to capture the styles from the Word document template(s) and embed them into the MCMS templates that are used by the authors. Note that if an author defines new or updates existing styles in an existing Word document, the change will not be reflected on the site until the MCMS template or cascading style sheet is updated. Such changes will be applied to all postings based on the templates—which may or may not be the outcome you want. As a general rule, if single-line, single-paragraph formatting, for use only one time for a specific purpose, is required, inline styles should be used.

Although setting up templates for document styles requires slightly more work, it is the preferred method, in order to maintain consistent formatting and look of all postings.

To open the styles and formatting sidebar in Word 2002

  • In Word 2002, on the Format menu, click Styles and Formatting.

To extract HTML styles from Word 2002 documents

  1. In Word 2002, open a document that contains the style definitions you want to import.
  2. Select part of the content in the document to which you want to apply a particular style.
  3. Apply the style by selecting a particular style from the Pick formatting to apply drop-down list.
  4. Save the document as an HTML page, filtered.
  5. Open the resulting .htm file in a text editor, such as Notepad.
  6. Locate the relevant style in the <head> section.
  7. Copy the relevant style into the <head> section of the MCMS template(s), or copy it to your cascading style sheet (CSS) that will be included in the MCMS template(s).

Another approach is for the MCMS template designer/programmer to define a new Word template with the styles that are used on the site, and distribute the template to the authors. However, such an approach may be limited, since it is best used only with new documents.

No Styles

Some situations may require template designers to discard both document and inline styles. In such cases, all style and formatting will be stripped from the document. Template designers may choose to add style and/or formatting definitions around the placeholders in the templates. This ensures that all content has the appropriate style and formatting.

To strip all style and formatting information

  1. In the Placeholder Definition dialog box, select the placeholder.
  2. In the formatting drop-down box, select NoFormatting.

Using Authoring Connector in a Multilingual Environment

Regardless of the language or the character set used in the Word document, the language should be preserved when the page is displayed on an MCMS Web site. During the submissions process from a Word document, the content is translated to the UTF-8 character set before it is submitted to the server.

In general, you should not need to modify any charset or codepage settings in order to display different languages.

Globalization Directives

Microsoft Internet Information Services (IIS) and ASP.NET use the Globalization directives (codepages) to determine what languages are being used on the Web site. Codepages translate the information in the MCMS server repository, so that the browser understands what language the Web page is using. Codepages can cover more than one language, and some Unicode-based codepages support all major written languages. Codepages are an important consideration when building multilingual sites, because MCMS uses them to convert dynamic strings from Unicode. By default, the encoding of all documents is set at the application level specified in the Web.config file. The default selection can also be overridden by specifying page level directives.

In Use
Web.config <globalization requestEncoding="utf-8" responseEncoding="utf-8" />
Template <%@ Page ResponseEncoding="utf-8" RequestEncoding="utf-8"%>

Character Sets

The character set used on the site tells the user's browser how it is supposed to get the information from the server. The character set value is set in the HTML <META> tag in the MCMS template. It should be set to the same language as your codepage. The following code example represents the Japanese character set:

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=shift_jis">

Universal character sets (UTF-8) are available in Microsoft Internet Explorer 4 and later. However, keep in mind that UTF-8-compliant browsers are not as widely used in some countries/regions outside of North America.

Fonts

When choosing the fonts for your MCMS template, remember to choose fonts that match the character set for the language you are using. For example, the font Arial does not contain Japanese characters. You should create a style guide for each language that indicates the fonts, font size, and attributes (such as bold or italic) you want to use on your site.

Accessing Codepages and Character Sets Using the Publishing API

You can use the following methods to access codepages and character sets from the Publishing API:

  • Template.CodePage read only
  • Template.Charset[=charset] read/write

Customizing the Publishing Task List

The Publishing Task List is available for use by authors in the Publishing Wizard to streamline their authoring experience. In essence, it is a server-based mapping between a list of publishing tasks and the corresponding MCMS publishing details required to complete the task. Certain parameters of the publishing details may be difficult to understand. Examples of these details are the channel location and the template. In order to make this content submission process more convenient to an author who may not know a great deal about MCMS, a Publishing Task List can be created in MCMS 2002. A Publishing Task List contains a list of publishing tasks, and each publishing task contains a description of the task in plain language. An example of a publishing task might be "Create an HR Job posting". More importantly, each task in a Publishing Task List associates the appropriate default values of the publishing details for that publishing task. Once the author selects the task, the default values are automatically made available to the author. Therefore, in most cases, the author does not need to manually enter the publishing details. Only the tasks for which an author has rights to will appear in the Publishing Task List.

The Publishing Task List is an XML document located on the target server. This enables all clients connecting to the server to view the same list of publishing tasks. In order for a specific task list to be displayed on the Publishing Task List menu, the author must have rights to the channel and the template that are specified in the Publishing Task List XML document on the server. The location of the XML document is by default <install drive>:\Program Files\Microsoft Content Management Server\Server\IIS_CMS\OfficeWizard\PublishingTasks.xml; however, you can change this default location. See the "Securing Authoring Connector" section in this document for more information. When multiple authoring servers in a Web farm are used, you may want to place the same PublishingTasks.xml file on all servers, in order to enforce consistency.

Adding and Modifying Publishing Tasks

Adding a new publishing task is relatively simple. The detailed, step-by-step tutorial is available in MCMS 2002 Help, under "Site Developer Tutorial; Lab 2: Creating MCMS Authoring Connector Templates and Publishing Tasks."

The following is a sample XML tasks list:

<?xml version="1.0" ?>
<tasks>
    <task>
        <name>AttachmentGuid</name>
        <description>Office attachment placeholder taks</description>
        <templateGuid>{4066E028-E51D-4ABE-BF50-5A4E8F5E8A8D}</templateGuid>
        <channelGuid>{790BAFCE-49EC-4D84-BD76-2E60672EE162}</channelGuid>
    </task>
    <task>
        <name>Html&lt;script&gt; </name>
        <description>Office html placeholder taks</description>
        <template>/Templates/ACT/OH</template>
        <channel>/Channels/ACT/</channel>
    </task>
</tasks>

The XML tasks list shows that the document is composed of a root element ("tasks") and child elements ("task"). Each task element should contain <templateGuid> or <template>, <channelGuid> or <channel>, name and description. Name and description elements can contain HTML escape markup. Each task has to follow the name, description, channel, and template order. You need to ensure that all characters are properly escaped in order to maintain validity of the XML document. Note that it is more efficient to provide ChannelGUID and TemplateGUID values, rather than the virtual path locations of the channel and template. The server performance will benefit, since searches by GUIDs are faster and require significantly less resources.

The Publishing Task List XML document schema is defined in the PublishingTasks.xsd file. The following table contains a summary of allowed values for a Publishing Task List XML document.

Parent Node Child Node/Element Allowed Values
tasks Task  
task Name Any text and properly-escaped HTML characters
task Description Any text and properly-escaped HTML characters
task channelGuid OR Valid MCMS GUID in {4066E028-E51D-4ABE-BF50-5A4E8F5E8A8D} form
task Channel Valid channel path, for example "/channels/Intranet/Products/"
task temaplteGuid OR Valid MCMS GUID in {4066E028-E51D-4ABE-BF50-5A4E8F5E8A8D} form
task Template Valid template path, for example, "/Templates/Intranet/Admin Templates/Product Summary"

If any of the required elements are not defined, an error will occur and no tasks will be shown in the Publishing Task List. Site administrators should test their Publishing Task List whenever changes are made.

Restricting Users to a Predefined Publishing Task List

Authoring Connector gives authors great flexibility, enabling them to manually select the template and channel into which they want to post their Word document. In cases where a greater level of control is required, this manual override feature can be disabled, effectively restricting the authors to the Publishing Task List only.

To disable the manual override option in Authoring Connector

  1. Navigate to the OC.aspx file at <install drive>:\Program Files\Microsoft Content Management Server\Server\IIS_CMS\OfficeWizard\.
  2. Back up the original OC.aspx file to OC.aspx.original.
  3. Open the OC.aspx file in Visual Studio .NET, or in your preferred text editor.
  4. Modify line 145 by adding the keyword disabled, as shown in the following code:
    <td style="PADDING-TOP: 12px"><asp:checkbox id="chkManualEntry" 
       accessKey="M" runat="server" AutoPostBack="True" Text="<u>M</u>anual 
          entry of channel and template"></asp:checkbox></td>
    
    

    To

    <td style="PADDING-TOP: 12px"><asp:checkbox id="chkManualEntry" 
       disabled accessKey="M" runat="server" AutoPostBack="True" 
          Text="<u>M</u>anual entry of channel and 
             template"></asp:checkbox></td>
    
    

After making the modification, the Manual entry of channel and template check box is disabled. The following figure shows the Authoring Connector Wizard Publishng Task dialog box.

Figure 4. Authoring Connector Wizard Publishing Task dialog box

Furthermore, it is possible to add custom logic to the OC.aspx file, which could give some authors a full-feature set, while other authors would be presented only with options from the Publishing Task List. For example, the decision process could be based on whether or not an author (for example, a user publishing from Word) has MCMS author or MCMS editor rights.

Preventing Users From Modifying Custom Properties

Authoring Connector gives authors flexibility to change custom properties on the posting that they are creating or updating. In some situations, you may want to disable such functionality—for example, when access to custom properties is also restricted in Web Author.

To disable Advanced Options

  1. Navigate to the OC.aspx file at <install drive>:\Program Files\Microsoft Content Management Server\Server\IIS_CMS\OfficeWizard\.
  2. Back up the original OC.aspx file to OC.aspx.original.
  3. Open the OC.aspx file in Visual Studio .NET, or in your preferred text editor.
  4. Modify line 570 by adding the keyword disabled, as shown in the following code:
    <td style="PADDING-TOP: 10px" colSpan="3"><asp:checkbox 
       id="chkPageDetails" accessKey="v" runat="server" 
          Text="Ad<u>v</u>anced page properties"></asp:checkbox></td>
    
    

    To

    <td style="PADDING-TOP: 10px" colSpan="3"><asp:checkbox 
       id="chkPageDetails" disabled accessKey="v" runat="server" 
          Text="Ad<u>v</u>anced page properties"></asp:checkbox></td>
    
    
Note   Modifications to the OC.aspx file are not supported. Any changes to the OC.aspx file may be lost when applying service packs, hot fixes, or upgrades, and may have to be reapplied. If you are considering altering the OC.aspx file, back up the original and modified version of the OC.aspx files before proceeding with any software update. After the software update is complete, carefully examine the new OC.aspx file and reapply your modifications in the appropriate sections. It is recommended that all custom logic be kept in a separate class or file, for ease of integration and transition.

Using Publishing Event Handlers with Authoring Connector

Publishing event handlers is the most accessible point of customization and integration of Authoring Connector. As previously mentioned, Authoring Connector does not directly interact with or execute any of the code included in a template file or Web controls. The server side component, the OC.aspx file, interacts only with template definitions, to retrieve placeholder definitions and to insert the content into the appropriate placeholders. (See the "Client/Server Interaction with MCMS Authoring Connector" figure in this document.) Typically, site programmers have two choices—modify the OC.aspx file to include custom behavior, or use Publishing event handlers to execute custom code on specific events. Since modifications to the OC.aspx file are not supported, the best practice is to use Publishing event handlers.

Event handlers are not available by default for Authoring Connector. This is because the default path specified in the Authoring Connector wizard is http://<server name>/mcms/cms/OfficeWizard/oc.aspx. However, if you have installed the WoodgroveNet sample into your MCMS environment, the path for the application representing your site is http://<server name>/ WoodgroveNet/, and therefore, Authoring Connector will not inherit your site's application scope, global.asax file, or any custom HTTP modules, by default. The following figure is a typical view of a default installation, showing the separate locations of an MCMS application (WoodgroveNet) and Authoring Connector.

Figure 5. Typical view of a default installation

Including Publishing Event Handlers in Authoring Connector

A site programmer has two options to enable Publishing event handlers for Authoring Connector:

  1. Instruct the authors to point their Authoring Connector wizard at an Authoring Connector component located under the specific site application that was created for the site.
  2. Create a new application in the Authoring Connector directory on the server and register the respective HTTP modules to handle the Publishing events.

The following table lists the advantages and disadvantages of each option.

Method of integration Advantages and disadvantages
Pointing Authoring Connector client to a different default location Advantages: No code changes required. Each entry point can have its own Authoring Connector entry point, enabling a different workflow to be executed, depending on what entry point the author is using. Word documents "remember" the entry point to which they have been published, and require no further involvement from the author.

Disadvantages: Requires a change in the default value when installing the Authoring Connector client component, or requires the user to change the path in the Authoring Connector wizard. May require more training if authors are to publish to multiple entry points. If requirements call for a different workflow process on Web Authoring and authoring actions, more code will need to be written into the global.asax file event handlers.

Creating a new application for the Authoring Connector server component Advantages: No changes are required to the default Authoring Connector client installation. No changes are required when publishing to different entry points of the site. Preferred method if a different workflow is required for Word authoring events than for Web authoring events.

Disadvantages: Workflow events have to be replicated in the global.asax file, possibly creating duplicate code. More code may be required if multiple entry points have different workflows. Requires creation of new files in MCMS directory on the server.

Pointing the authoring connector client to a different default location

This option is the best choice if the MCMS site has multiple entry points (applications), and each entry point has a customized workflow. The main advantage of this approach is that, in most cases, no code change is required. Authors can change the path to the Authoring Connector server component during publishing time. Authors have the option of changing the path by selecting the Change server name and path check box on the first screen of the Authoring Connector wizard. Once the path is changed for a document, it is saved to the CmsServerUrl property in the Word document, so it does not need to be changed again. It also becomes the default for any other document that does not already have the CmsServerUrl property defined. Also, any Word template created with this property will pick up the target location. As a best practice, it is recommended that authors who use a single entry point to the MCSM site change their default value at installation time, in order to minimize the effort needed in publishing.

The following procedures describe how to include event handlers in Authoring Connector on the WoodgroveNet sample site, and how to verify the functionality.

To include event handlers in Authoring Connector on the WoodgroveNet site

  1. In the Authoring Connector Wizard, select the Change server name and path check box, and then click Next.
  2. Change the default path from http://<server name>/mcms/cms/OfficeWizard/oc.aspx to http://<server name>/WoodgroveNet/cms/OfficeWizard/oc.aspx.

To verify the functionality

  1. In the global.asax file for the WoodgroveNet sample site, locate the following event:
    protected void CmsPosting_Submitted( Object sender, ChangedEventArgs e ) 
    
    
  2. Add the following line to the event:
    FileStream stream = File.Open("C:\\inetpub\\wwwroot\\test.txt", 
       FileMode.OpenOrCreate, FileAccess.Write); 
    
    
  3. Rebuild the solution.
  4. Create or edit a porting, and submit it using the Web Author.
  5. Verify that the test.txt file was created in wwwroot. This confirms that the Publishing event handlers are firing for Web authoring events.
  6. Delete the test.txt file.
  7. Create or update the MCMS site using Authoring Connector. Ensure that the server name and path points to http://<server name>/WoodgroveNet/CMS/OfficeWizard/oc.aspx.
  8. Verify that the test.txt file was created. This confirms that Publishing event handlers are firing for Authoring Connector actions.

Creating a new application for the authoring connector server component

This approach is beneficial if content authored from Word follows a different workflow process than Web authored content, or when it is crucial to maintain a default setting in Authoring Connector. This approach requires more steps to implement, but may be worth the effort if a substantial amount of code or integration must be done for most Authoring Connector events. Keep in mind that you are changing the default configuration of the Authoring Connector server component installation, and that the changes may have to be reapplied if upgrades or hot fixes are deployed.

To enable a separate set of Publishing event handlers for Authoring Connector

  1. Create a new Web application project (not an MCMS 2002 Web project) in Visual Studio .NET from Microsoft® Visual C#® projects. The location of the project is not important, as the resulting files will be copied into the appropriate directory.
  2. Using Visual Studio .NET Solution Explorer, remove the WebForm1.aspx, Web.config, and AssemblyInfo.cs files from the project. The only file that is required is the global.asax file.
  3. Right-click References and add references to System.EnterpriseServices.
  4. Use the browse button and navigate to the <install drive>:\\ Program Files\Microsoft Content Management Server\Server\bin\ directory. Add references to the following files:
    • Microsoft.ContentManagement.Publishing.dll
    • Microsoft.ContentManagement.Web.dll
  5. View the code-behind page of the global.asax file and note the name of the namespace.
  6. Insert the code from the following "Sample Code" topic into the CmsPosting_Submitted event. A listing of the global.asax file is located in Appendix A in this document.
  7. Create a new global.asax.cs code-behind file in <install drive>:\\Program Files\Microsoft Content Management Server\Server\IIS_CMS\OfficeWizard\ (See the sample global.asax code in Appendix A.)
  8. Add sample code as shown in the following "Sample Code" topic.
  9. Save and build the solution.
  10. Navigate to the directory where you built the project.
  11. Copy the global.asax file, the global.asax.cs project, and the bin directory to <install drive>:\\Program Files\Microsoft Content Management Server\Server\MCMS.
  12. Verify that the following httpModule is registered (line 59):
    <add type="Microsoft.ContentManagement.Publishing.Events.PostingEventsModule,
       Microsoft.ContentManagement.Publishing, Version=5.0.1200.0, 
          Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
             name="CmsPosting" />
    
    
    Note   If a new application was created for Authoring Connector, add this line to its Web.config file.
  13. Delete the test.txt file from c:\inetpub\wwwroot directory.
  14. Publish a Word document using Authoring Connector. Ensure that the specified default path is http://<server name>/MCMS/cms/OfficeWizard/oc.aspx.
  15. The text.txt file should be created in c:\inetpub\wwwroot upon the completion of the wizard, which verifies that the Publishing events fired properly.

Sample Code

The following shows the sample code for the global.asax.cs project for enabling publishing event handlers:

protected void CmsPosting_Submitted(Object sender, ChangedEventArgs e)
{
   FileStream stream = File.Open("C:\\inetpub\\wwwroot\\test.txt", 
FileMode.OpenOrCreate, FileAccess.Write); 
}

Authoring to Multiple Placeholders

Splitting Graphics and Textual Content

Authoring Connector inserts and/or updates content in all OfficeHtmlPlaceholders present in the template. Similarly, attachments to the original document are also uploaded to all available OfficeAttachment placeholders. This is because Authoring Connector and the publishing schema do not currently have specific placeholder targeting capability. A template designer could quickly set up templates with a separate single image and other content into two separate placeholders. This configuration could be useful, for example, in a situation where Word documents are used to hold product information or a specification sheet along with the image of the product. Word authors can publish the documents directly from Word and have the image and text split up for them in the target page.

The following procedures explain how to configure a template to separate content into a single image and HtmlPlaceholder.

To configure a template to separate content into a single image and HtmlPlacehoder

In the template definition schema

  1. Add two OfficeHtmlPlaceholders to the template definition schema.
  2. On the first OfficeHtmlPlaceholder, set the AllowImages property to true.
  3. On second OfficeHtmlPlaceholder, set the AllowImages property to false.

In the template

  1. Drag the single image placeholder control onto the template.
  2. Bind the control to OfficeHtmlPlaceholder, which allows images.
  3. Drag the HTML placeholder control onto the template.
  4. Bind the control to OfficeHtmlPlaceholder, which does not allow images.

Using Publishing Event Handlers to Submit Content to Multiple Placeholders

Some business requirements may specify that content from a Word document be split into multiple placeholders. For example, a Word document may have title, headline, body, and reference sections. Each section should ideally go into its own placeholder, so that the postings can be easily summarized on single page. The default configuration of Authoring Connector does not take into account content authoring to multiple placeholders. However, it is possible to use Publishing event handlers to add code that can perform operations on the submitted content. Site developers can use either method presented in the topic "Including Publishing Event Handlers in Authoring Connector" in this document. Note that when using the global.asax file under your site application, you may have to account for events being fired by both Web Author and Authoring Connector. When creating your own global.asax file under the MCMS or other directory, you only have to account for events fired by Authoring Connector.

Designing a functional solution

There are a few areas that need to be considered when designing solutions for splitting submitted content into multiple placeholders.

First, what are the content delimiters in the Word document? Is it specific text strings, paragraphs, or bookmarks? The decision is up to the solution architect, and may differ depending on the business requirements. In most cases, using bookmarks is sufficient. Bookmarks are relatively easy to add and manage in Word documents, and are easy to parse once the content is submitted to the server.

Second, it is important to consider the targeting mechanism. In some cases, it may be sufficient to include all logic in the global.asax file. In other, more complex or dynamic cases, it may be beneficial to have the sections of content and their appropriate target placeholder defined in an XML file, or defined using custom properities on the template.

Third, it is important to consider which Publishing event handler is best suited as a trigger for the split functionality. In general, it will be the CmsPosting_Submitting event. This event is fired before submit is called in the MCMS API; therefore, the content can still be freely modified or split into multiple placeholders. Another option would be to use the CmsPosting_PlaceholderPropertyChanging event; however, you would have to "guard " against recursive calls, since each change creates another changing event, which, in turn, could call your code, again creating another changing event, and so forth. It is not very useful to add the code into a submitted event, as, at this point, the posting cannot be modified from the current CmsHttpContent.

In summary, good design is crucial in achieving a functional model for submitting content to multiple placeholders. Other information that should be considered consists of the following:

  • How is the content going to be delimited in the Word document?
  • How many placeholders are going to be targeted?
  • How dynamic does the targeting mechanism have to be?
  • What user intervention do you want for targeting of placeholders?

Sample code for splitting up content to multiple placeholders

The following sample solution involves using bookmarks in a Word document to delimit the targeted content on the client side. On the server side, during the submitting event, bookmarks are detected in the submitted content, and split using regular expressions, and are targeted to the appropriate placeholders. The content author inserts two bookmarks into the Word document—one called "CMSTitle" at the beginning of the title, and one called "CMSBody" at the beginning of the body section of the document. When the document is submitted, the title will be split between the "CMStitle" placeholder and the body to the "CMSBody" placeholder.

The following procedure explains how to create a template to work with split content functionality.

To create a template to work with split content functionality

  1. Open the WoodgroveNet project and create a template in the MCMS Template Explorer. Name it "SplitTemplate". The name will be used to detect the template in workflow events.
  2. Add an OfficeHtmlPlaceholder to the placeholder definitions. Call it "CMSBody".
  3. Add an HtmlPlaceholder to the placeholder definitions. Call it "CMSTitle".
  4. Save the template and check it in.
  5. In Solution Explorer, right-click the templates folder and add a new item. Select MCMS template file.
  6. Drag two HtmlPlaceholder controls onto the template in design mode.
  7. Name one "CMSTitle" and bind it to "CMSTitle" placeholder definition.
  8. Name the second one "CMSBody" and bind it to "CMSBody" placeholder definition.
  9. In MCMS Template Explorer, select the template definition you created in step 1. In the Properties window, set the template file property to point to the template file you create in step 5.

Use the following procedure to add simple split content functionality to the global.asax file.

To add simple split content functionality to the global.asax file

  1. Open or create a global.asax file in the appropriate application folder. See the topic "Using Publishing Event Handlers with Authoring Connector" in this document for details.
  2. Ensure that the flowing namespaces are referenced:
    using Microsoft.ContentManagement.Publishing.Extensions.Placeholders.Office;
    using Microsoft.ContentManagement.Publishing.Events;
    using Microsoft.ContentManagement.Publishing;
    using Microsoft.ContentManagement.Publishing.Extensions.Placeholders;
    using System.Text.RegularExpressions;
    using System.Collections;
    
    
  3. Add the following code to the CmsPosting_Submitted method:
    protected void CmsPosting_Submitting( Object sender, ChangingEventArgs e )
    {
    //get posting being created
    Posting p_posting = (Posting) e.Target;
    
    /*define the name of the template that
    is designed to accept content into multiple placeholders*/
    
    //string templateName = "Placeholder test";
    
    //execute the following code only for postings based on a specific template
    if(p_posting.Template.Name.ToString() == "SplitTemplate")
    {
    //loop over placeholders
    foreach(Placeholder p_placeholder in p_posting.Placeholders)
    {
    // just a sanity loop to locate the first Office placeholder with content
    if(p_placeholder is OfficeHtmlPlaceholder)
    {
    try
    {
    //separate content
    SplitContent((OfficeHtmlPlaceholder) p_placeholder);
    }
    catch
    {
    }
    break ; 
    }
    }
    }
    }
    
    
  4. Add the following method, which performs the split operation:
    protected void SplitContent(OfficeHtmlPlaceholder oPlaceholder)
    {
    // create the regular expression for the splitting operation
    Regex p = new Regex( "<A name=\".*?\"></A>");   
    // Split content
    string[] splitcontent = p.Split(oPlaceholder.Html);
    
    // define the placeholder variables and assign the placeholders
    HtmlPlaceholder p_CMSTitle = (HtmlPlaceholder) oPlaceholder.Posting.Placeholders["CMSTitle"] ;
    HtmlPlaceholder p_CMSBody = (HtmlPlaceholder) oPlaceholder.Posting.Placeholders["CMSBody"] ;
    
    //set the placeholders to empty strings as they may contain content 
       from the submission by Authoring Connector
    p_CMSTitle.Html = "";
    p_CMSBody.Html = "";
    
    // Loop over array and insert the first two matches into CMSTitle 
       and other matches into CMSBody
    
    for(int count=0; count <= splitcontent.GetUpperBound(0); count++)
    {
    if(count <= 1)
    {
    p_CMSTitle.Html = splitcontent[count].ToString();
    }
    else
    {
    p_CMSBody.Html = splitcontent[count].ToString();
    }
    }
    
    
  5. Compile the global.asax file. If needed, move the resulting files to the target application folder.

Use the following procedure to create bookmarks in the Word document.

To create bookmarks in the Word document

  1. Open or create a new Word document.
  2. Type a short title (2 or 3 words).
  3. Type a paragraph or two of content.
  4. Place the cursor immediately before the start of the title section.
  5. On the Insert menu, click Bookmark.
  6. In the Bookmark dialog box, in the Bookmark name box, type CMSTitle, and then click Add.
  7. In the Word document, place the cursor immediately before the start of the body section and repeat steps 5 and 6, using CMSBody as the bookmark name.
  8. Save and submit the content using the "SplitTemplate" created earlier in this sample.
  9. When submission is complete, the content should appear in the appropriate placeholders.

    Figure 6. Word 2002 Bookmark dialog box

The above is a simplified example of how to accomplish splitting submitted content from the Authoring Connector. A real-world solution may be more complex. For example, a site developer could develop a relatively flexible targeting mechanism, or choose to look for an OfficeAttachmentplaceholder object, and replace the attachment in Word format with a PDF format or a reference to an MCMS resource gallery item.

Securing Office Connector

MCMS Security

When using Authoring Connector, all users are subject to the same security restrictions as with the Web Author. It is important to note that Office authors do, in fact, have access to Web Author, and may choose to modify the site directly, instead of using Authoring Connector. An Office author has rights to the same posting templates and channels as they would when using Authoring Connector. In most cases, this should not cause problems. For example, in certain cases where Office authors who are restricted to using only a task from the Publishing Task List log into the Web Author, those authors will have slightly more control over the content of the channels to which they have rights. As in all other cases, end-user training is the best way to avoid misunderstanding or confusion.

IIS Security

In certain situations, you may want to make the Authoring Connector interface accessible over the Internet. Such cases include partner- or sub-contractor-based content contributions—for example, a public relations agency or a partner company contributing content to the Press Releases section of the site. A posting, either a newly-created one or an updated one, will enter the regular workflow and go through the same approval process as regular postings. IIS virtual directory security can include restrictions to specific IP addresses and/or subnets, certificates, and smart cards. For full details about IIS security options, see the IIS documentation and online help.

File System Security

In order to tighten security even further, system administrators may choose to change the location of the PublishingTaks.xml and PublishingTaks.xsd documents. The physical locations of these files are specified in the Web.config file for Authoring Connector. The default location of the file is <install drive>:\Program Files\Microsoft Content Management Server\Server\IIS_CMS\OfficeWizard. Note that the virtual and physical location of the directory containing the Authoring Connector components can also be customized, as noted in the MCMS security section above. The <appSettings> section defines the location and name of the PublishingTasks.xml and .xsd files. System administrators may also choose to change the name of the files.

<appSettings>
<add key="Publishing Tasks XML File Path" value="C:\secure\tasks.xml" />
<add key="Publishing Tasks Schema File Path" value="C:\secure\tasks.xsd" />
</appSettings>

Note that the key property must be defined exactly as specified in the above code example.

Glossary

Office Author—A business user who uses a Microsoft Office application to publish the content of Office documents to an MCMS-managed Web site.

Authoring Connector—A software component that resides on an Office author's desktop and provides the publishing ability for supported Office applications to an MCMS-managed Web Site.

Posting Attributes or Properties—A set of properties associated with an MCMS posting. Some properties (such as "Start Publishing Date/Time") are predefined, while other properties are user-defined and inherited from the template that a posting is based upon.

Publishing Details—A collection of parameters required to submit content to an MCMS-managed Web site. Parameters for each publishing task include an MCMS template, an MCMS channel, and a set of pre-defined and custom properties for an MCMS posting.

Publishing Task—A Web publishing task that an Office author needs to conduct in order to contribute content to a Web site. An example is to create a press release on a Web site.

Publishing Task List—A server-based mapping between a list of publishing tasks and the corresponding MCMS publishing details required to complete the task. The primary function of this list is to simplify the content submission process for an Office author, so that an Office author does not need to enter all details of the MCMS publishing process manually.

Submitting content—The action of submitting content to MCMS to create a Web page, and to change the state to waiting for editor approval; it does not include the action to approve or to make the Web page live or published on the site.

Web Author—An MCMS client application that runs under a Web browser (formally known as WBC: Web-Browser Client.)

Site programmer/developer—Person responsible for coding required functionality for temples and the framework used by the MCMS site.

Appendix A

(Sample golobal.asax file)

using System;
using System.Web;
using System.Web.SessionState;
using System.Reflection;
//Add reference for localization
using System.EnterpriseServices;
using System.Globalization;
using System.Resources;
using System.Threading;
using Microsoft.ContentManagement.Publishing.Extensions.Placeholders.Office;
using Microsoft.ContentManagement.Publishing.Events;
using Microsoft.ContentManagement.Publishing;
using Microsoft.ContentManagement.Publishing.Extensions.Placeholders;
using System.Text.RegularExpressions;
using System.Collections;

namespace WebApplication2 
{
   /// <summary>
   /// Summary description for Global.
   /// </summary>
   public class Global : Microsoft.ContentManagement.Web.CmsHttpApplication
   {
      public Global()
      {
         InitializeComponent();
      }
      private void InitializeComponent()
      {
      }


      void Application_OnStart() 
      {

      }

      void Application_BeginRequest(Object sender, EventArgs args) 
      {

      }

      protected void Application_Start(Object sender, EventArgs e)
      {

      }
 
      protected void Session_Start(Object sender, EventArgs e)
      {

      }

      protected void Application_EndRequest(Object sender, EventArgs e)
      {

      }

      protected void Application_AuthenticateRequest(Object sender, EventArgs e)
      {

      }

      protected void Application_Error(Object sender, EventArgs e)
      {
      }

      protected void Session_End(Object sender, EventArgs e)
      {

      }

      protected void Application_End(Object sender, EventArgs e)
      {

      }


      //
      //  Below are event handler stubs for the MCMS Posting events.
      //      Approving, Approved
      //      Changing, Changed
      //      Creating, Created
      //      CustomPropertyChanging, CustomPropertyChanged
      //      Declining, Declined
      //      Deleting, Deleted
      //      Moving, Moved
      //      PlaceholderPropertyChanging, PlaceholderPropertyChanged
      //      PropertyChanging, PropertyChanged
      //      Submitting, Submitted
      //      
      //  Add custom event handler code between the braces.
      //

      protected void CmsPosting_Approved( Object sender, ChangedEventArgs e )
      {

      }

      protected void CmsPosting_Approving( Object sender, ChangingEventArgs e )
      {

      }

      protected void CmsPosting_Changed( Object sender, ChangedEventArgs e )
      {

      }

      protected void CmsPosting_Changing( Object sender, ChangingEventArgs e )
      {

      }

      protected void CmsPosting_Created( Object sender, CreatedEventArgs e )
      {

      }

      protected void CmsPosting_Creating( Object sender, CreatingEventArgs e )
      {

      }

      public void CmsPosting_CustomPropertyChanged( Object sender, 
         Microsoft.ContentManagement.Publishing.Events.PropertyChangedEventArgs e )
      {

      }

      protected void CmsPosting_CustomPropertyChanging( Object sender, 
         PropertyChangingEventArgs e )
      {

      }

      protected void CmsPosting_Declined( Object sender, ChangedEventArgs e )
      {

      }

      protected void CmsPosting_Declining( Object sender, ChangingEventArgs e )
      {

      }

      protected void CmsPosting_Deleted( Object sender,  ChangedEventArgs e )
      {

      }

      protected void CmsPosting_Deleting( Object sender, ChangingEventArgs e )
      {

      }

      protected void CmsPosting_Moved( Object sender, MovedEventArgs e )
      {

      }

      protected void CmsPosting_Moving( Object sender, MovingEventArgs e )
      {

      }

      protected void CmsPosting_PlaceholderPropertyChanged( Object sender, 
         Microsoft.ContentManagement.Publishing.Events.PropertyChangedEventArgs e )
      {

      }

      protected void CmsPosting_PlaceholderPropertyChanging( Object sender, PropertyChangingEventArgs e )
      {

      }

      protected void CmsPosting_PropertyChanged( Object sender, 
         Microsoft.ContentManagement.Publishing.Events.PropertyChangedEventArgs e )
      {

      }

      protected void CmsPosting_PropertyChanging( Object sender, PropertyChangingEventArgs e )
      {

      }

      protected void CmsPosting_Submitting( Object sender, ChangingEventArgs e )
      {
      }
      protected void CmsPosting_Submitted( Object sender, ChangedEventArgs e )
      {
      }

      #region Web Form Designer generated code
      /// <summary>
      /// Required method for Designer support - do not modify
      /// the contents of this method with the code editor.
      /// </summary>

      #endregion
   }
}

Publishing Task Editor

Download the Publishing Task Editor.

Overview

The Publishing Task Editor (Task Editor) enables easier creation and manipulation of Publishing Task files, which are used with the MCMS 2002 Authoring Connector. Using the Task Editor ensures that any files which are created or modified conform to the requirements of the Authoring Connector.

Installation Requirements

  • Two files are required for the Task Editor to function correctly: TaskEditorApp.exe and tasklist.xsd. These two files must reside in the same directory.
  • MCMS 2002 must be installed on the computer where the Task Editor is running.

Features

The Task Editor helps task authors create valid task files on a task-by-task basis, by enforcing the following standards:

  • Only valid channel and template paths/GUIDs can be selected through the Task Editor interface.
  • Duplicate task names are not allowed.
  • Length restrictions for field lengths are observed.
  • A task file cannot be saved in the Task Editor unless each of the tasks is valid, and the generated file will be valid.

Path vs. GUID Notation for Channels and Templates

Channel and Template references may be stored in either Path format or GUID (Globally Unique Identifier) format. Storing this information as a GUID has performance benefits, but the Path format is more easily read and maintained between multiple task file authors.

When either the Channel or Template browse buttons are clicked, the browse window appears with either the Path or the GUID selected. Either can be chosen by the user at that time, and the default for these windows is set by selecting the appropriate menu item under the "Options" menu in the Task Editor.

Shortcut Keys

Shortcut keys for all of the commonly-used fields and features in the Task Editor are listed in the following table.

CTRL+N Create New Task File
CTRL+O Open Task File
CTRL+S Save Task File
CTRL+T Create New Task (in current file)
CTRL+P Copy Current Task
CTRL+Delete Delete Current Task
CTRL+Z Undo
CTRL+L Login As A User
CTRL+SHIFT+S Switch to Task List
CTRL+SHIFT+N Switch to Task Name field
CTRL+SHIFT+D Switch to Task Description field
CTRL+SHIFT+C Select a Channel
CTRL+SHIFT+T Select a Template

Items of Interest

  • The tasklist.xsd file, which is in the same directory as the Task Editor, is not exactly the same as the file of the same name that comes with the Authoring Connector, but they both adhere to the same standards for specified tasks. At this time, a task file that does not conform to these standards cannot be loaded into the Task Editor.
  • The browse window for saving files does not automatically add ".xml" to the end of the file name. It is suggested that users add this suffix when creating files.
Show:
© 2015 Microsoft