Authoring Content

Web Author

Many CMS users will only use the Web Author interface. In fact, many probably think that the Web Author is CMS. Since the CMS 2002 release, all authoring happens through this thin client interface. The Web Author is built using ASP, JavaScript, and the PAPI. A few elements, such as the toolbar and the HTML placeholder control, are ActiveX components. The Web Author consists of a number of user interfaces and code that interacts with the PAPI. Because the Web Author is a thin client interface, it can be used remotely over HTTP. It is also possible to use HTTPS with the Web Author interface.

The Web Author default install location is C:\Program Files\Microsoft Content Management Server\Server\IIS_NR\System\WBC. The directory is called WBC because the Web Author was originally called the Web Browser Client.

Inside the WBC directory are the following folders:

  • Customizable: This folder contains the Web Author files that are still supported after customer modifications. For example, the Hooks directory contains scripts that allow ASP access to some Web Author events.

  • Internals: Most of the Web Author code is under this directory. For example, the user interfaces for the Web Author console are located in the WBCFuncPages directory. The legal statement (InternalsDirectoryLegal.txt) provided in these directories clearly states that these files are not meant to be modified.

  • SiteInterface: This directory contains only one file, Placeholders The file is simply a warning that this former interface has been deprecated.

Web Author .NET

The .NET version of the Web Author has been designed to offer the same functionality as the nonmanaged version. Therefore, the two applications are very similar. Without this similarity, people might have become frustrated by two different user experiences. The Web Author .NET interface and dialogs were developed using JavaScript and .NET server controls.

The default install location for Web Author .NET is C:\Program Files\Microsoft Content Management Server\Server\bin. Unlike the ASP version of the Web Author, the managed version is compiled. This is the way that .NET works, but for CMS customers, there are positive and negative arguments about the compiled version of Web Author. Some people argue that customers and partners are hurt by the fact that they are not able to view all of the code. However, other people feel that the compiled version of the code has advantages. Two common positive arguments are that hackers are not able to comb the code looking for weaknesses and that customers can be sure that their Web Author code has not been inadvertently altered.

On an ASP.NET CMS site, the Web Author .NET handles all the authoring duties. It is not necessary to install the ASP version of the Web Author if the site will not be using it. Web Author .NET also supports HTTPS. The architecture of the Web Author .NET is discussed in detail in Chapter 30.

Authoring Connector

The Authoring Connector is a new interface for CMS. Introduced in CMS 2002, this feature promises to be popular with CMS authors. The Authoring Connector component enables content creation and editing directly through Microsoft Word XP. The Authoring Connector consists of a client-side component and a server-side component.

  • Client side: A Word add-on featuring a user interface wizard. This wizard allows CMS authors to easily specify the location for their content to be published.

  • Server side: ASPX files and ASP.NET server controls that write to CMS via their interaction with the PAPI.

The Authoring Connector client uses the Word API to convert Word documents into HTML. The HTML and any inline images are then submitted to a designated placeholder within a CMS page. After that submission, a link to the newly created Web page is stored in the properties of the Word document. This makes it easier for the author to update or replace the page at a later date. The next time the same Word document is submitted, Authoring Connector recognizes the reference to the page and allows the user to update the corresponding page.

The default location for the Authoring Connector is C:\Program Files\Microsoft Content Management Server\Authoring Connector. There are a number of subfolders installed in this client-side location. Each numbered folder corresponds to a Locate Identifier (LCID) and contains the localized version of the client-side portion of the Authoring Connector application. This allows CMS authors from all over the world to use their localized versions of Microsoft Word XP to create and edit content on CMS servers.

Although this is currently the only localized portion of CMS, other components have been designed to be localizable. For example, the Web Author, the Web Author .NET, and the Visual Studio integration have all been designed to be localizable. Based on this, various people have produced their own localized versions of the Web Author. Also, a white paper on the subject of localizing the Web Author is available from the MSDN Web site (

CMS Placeholders

CMS placeholders have evolved substantially over the last few years. Placeholders are the parts of a CMS Web page that contain editable content. Placeholders come in various types, with special features associated with each type.

Examples of placeholder types are:

  • Image: Can only contain images

  • HTML: Can contain HTML

  • XML: Contains XML

Placeholders consist of three parts:

  • Placeholder object: The underlying object that controls the behavior of the interface to the placeholder content. Custom placeholder objects can be created. For example, if you wanted a placeholder that contained a method such as GetPieceOfContent, you might want to create a custom placeholder.

  • Placeholder definition: The description of the placeholder that is set from within Visual Studio .NET. Placeholder objects must be bound to a placeholder definition before they can be used. The placeholder definition can be thought of as controlling the behavior of a placeholder for example, the XSD that an XML placeholder should validate against.

  • Placeholder server control: The .NET server controls that CMS users actually interact with. Custom placeholder controls can be created to control the rendering of the placeholder object in different modes.

The new model for placeholder controls is to use .NET server controls. Placeholder server controls are designed to allow an ASPX template to be bound to placeholder object data. The controls also render the placeholder data in various modes. The model for custom placeholder controls allows developers to choose the controls used for modes such as presentation and authoring. Most of the logic behind these services is provided by the BasePlaceholderControl object. Custom placeholder server controls built on top of this object only need to specify the logic for data reading, data writing, and rendering.

The rendering implementation of placeholder server controls is not restricted. This leaves the logic for rendering the authoring or presentation display up to the CMS developer. Rendering is generally handled by aggregating other controls designed specifically for this purpose. These controls could be ASP.NET controls (e.g., a TextBox or Literal), or they could be more complex custom controls. The BasePlaceholderControl provides the implementation for loading data into placeholders and saving data from placeholders into the CMS database.

The placeholder server control is not responsible for committing data to the database. It is notified by the BasePlaceholderControl when it should be loading content from the bound placeholder object and when it should be saving content. Therefore, the placeholder is only used as a data storage mechanism. It appears as though the placeholder server control reads and writes the data. But within the implementation of the placeholder server control, it is the PAPI that is responsible for committing data to the CMS database.

Before the .NET layer was added, placeholders were COM objects that rendered contents from the CMS database. This interface was previously hidden by the deprecated Template Designer interface. In other words, CMS developers did not need to write any code to get their placeholders to work; the code was automatically added to the template by the Template Designer. In CMS 2002, the template files have been moved from the CMS database to the server file system. This means that the CMS server no longer manages this placeholder code. To create an ASP site with CMS 2002, CMS developers need to manage this connection in their templates. The ASP version of the placeholder controls might be removed in the next release of CMS.

When you are creating custom placeholder server controls, the logic contained within the controls is only available from within an ASPX file. If you happen to need this logic outside a server control, you may need to duplicate your effort. One example of this would be if you were using the control through a Web service. A better solution in this scenario is to put that logic into a custom placeholder and then create a server control to interact with it. In this way, the placeholder object will be available via the PAPI directly, for use in Web services or more programmatic access like code behind in templates.

Microsoft Content Management Server 2002. A Complete Guide
Microsoft Content Management Server 2002: A Complete Guide
ISBN: 0321194446
EAN: 2147483647
Year: 2003
Pages: 298 © 2008-2017.
If you may any questions please contact us: