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:
Web Author .NET
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.
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.
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 (http://msdn.microsoft.com).
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:
Placeholders consist of three parts:
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.