CMS Development

Publishing API

The CMS Publishing API was introduced in NCompass Resolution 3.0. Originally, the PAPI was referred to as the Resolution Object Model (ROM). Before the introduction of the PAPI, Resolution developers used the Template Builder API (TBA). But the TBA only offered a small fraction of the functionality that the PAPI offers today. For example, the properties for pages were read-only.

Originally, the PAPI was written as a COM-compliant application. The COM interface alone offers well over 400 methods and properties. Today the PAPI is widely used by CMS developers. For example, most CMS developers use the PAPI to create their site navigation. This allows them to take advantage of the dynamic nature of a CMS site. Furthermore, the ASP Web Author component was written on top of this COM layer.

In CMS 2002, an ASP.NET managed layer is provided on top of the original PAPI. The application context allows CMS developers to develop ASP.NET WinForm applications on top of the CMS managed layer. Components that use the managed layer of the PAPI include the Authoring Connector, the CMS integration with Commerce Server 2002 (Content Connector), and the new Web Author .NET.

Examples of PAPI applications include:

  • Web Author: An ASP application used for CMS page authoring through a Web browser.

  • Web Author .NET: An ASP.NET application used for authoring through a Web browser.

  • Authoring Connector: An ASP.NET application used for authoring with Microsoft Word XP.

  • Visual Studio .NET client: An ASP.NET application used for developing CMS sites. This application uses the new CMS application context.

  • Content Connector: An ASP.NET (and Visual Basic) application that allows for integration with Microsoft Commerce Server 2002. This component is provided with the Microsoft Solution for Internet Business.

Autosession

The base object within the COM PAPI is called Autosession3. The Authenticate.inc file creates a variable called Autosession and assigns the PAPI Autosession3 object to it. All other objects, such as Posting or Channel, depend on this main object. In other words, it is necessary to create an Autosession object if you wish to use the CMS COM PAPI. You do this by referencing the Resolution.inc file within your ASP page. This file then calls Authenticate.inc, and the Autosession object is instantiated like this:

 AutoSession = Server.CreateObject("ResolutionObjectModel.               AutoSession3") 

Authenticate.inc also handles the security for the CMS COM PAPI. A user cannot use the Autosession object unless they have been authenticated as a valid CMS user. A user could actually instantiate the Autosession object, but they would not be able to call any of its methods or properties until they had been authenticated as a valid CMS user.

Autosession is automatically instantiated within CMS templates, but it can also be used within any ASP pages that are on the CMS server. In previous versions of CMS, this particular point was hidden from view. The Authenticate.inc file was always readable on the file system. However, the fact that CMS automatically inserted an include statement to include Authenticate.inc was hidden from the end user's eyes.

Template files were once stored within the CMS database and edited only using the Site Manager's custom Template Designer. The Template Designer interface did not expose the method used by the templates to automatically instantiate an Autosession object. However, in CMS 2002, the template files have been moved to the file system, and anyone can plainly see how the Autosession object is instantiated.

Managed PAPI

The new ASP.NET interface for the PAPI is a tremendous step forward for CMS developers. Using this interface, developers can program against the CMS PAPI using the Visual Studio .NET environment and numerous ASP.NET languages (including VB.NET and C#). It is this new feature that allowed the Visual Studio .NET integration to be developed. The managed layer of the CMS PAPI offers access to the PAPI through Interop assemblies. This layer was written using the C# language.

There are two interfaces within the ASP.NET layer of the PAPI:

  • CmsHttpContext: The CmsHttpContext interface allows managed code to access the CMS PAPI. This interface can be used to develop .NET Web applications on top of CMS. This interface relies on the HTTP context provided within IIS.

  • CmsApplicationContext: The application context is new to CMS. Although there is currently no remote interface, the application context is a fantastic step forward for CMS developers. Using the application context, CMS developers can create Windows .NET Forms applications. The application context also enables the impressive CMS VS.NET integration. This interface does not require the IIS HTTP context.

Looking forward, you can reasonably assume that future CMS components will only interact with the server though the managed PAPI layer. After all, this interface has been designed to allow developers to build applications on top of the CMS server.

Visual Studio .NET Client

The Visual Studio .NET (VS.NET) interface is a new feature. This client application depends on the Microsoft .NET Framework and the new CMS PAPI application context. The custom Template Designer used in previous versions of CMS has been replaced by this application. Instead of using a custom template authoring environment, CMS developers can use Visual Studio .NET to code their templates. The client was developed using the CmsApplicationContext class within the managed layer of the PAPI.

Because the CMS application context provides a method to authenticate the current Windows user, CMS developers do not need to log in to this client application. They can open their CMS solution in Visual Studio .NET and automatically access CMS features such as the placeholder collections and the template galleries.

The Visual Studio .NET integration is not installed by default. The reason for this is that the component is only necessary on developer boxes. The current version of Visual Studio .NET does not support remote connections for client applications such as the CMS integration. For this reason, the CMS VS.NET integration must be installed on the CMS server. The default install location for the client is C:\Program Files\Microsoft Content Management Server\DevTools.

Once this component is installed, it allows a CMS developer to work in an extremely powerful development environment. For example, developers can use the Visual Studio integration to manage components of CMS templates that are stored within the database. One of these components is the collection of placeholders that is associated with a particular template.

A compelling feature for a CMS developer is the fact that CMS templates can be debugged in VS.NET just like any other ASP.NET pages. Not only can a developer use tools such as breakpoints in their code, they can also debug CMS pages within their specific CMS context. For example, when a CMS developer launches a debugging session, the page can be displayed exactly as a specific CMS user would see it. At any given breakpoint, the local variables will show the values that a specific CMS user would see. This level of contextual debugging has not been offered in the past.

Sample Data

To help CMS developers get off the ground, a sample Web site is provided with CMS 2002. The WoodgroveNet site is an ASP.NET example of how to build a CMS site. The source code for the sample site is also provided on the CMS 2002 CD. Included in this code are a number of ASP.NET user controls, and server controls. Examples include the navigation control and the custom XML placeholder control. This sample code is one of the key resources for a new CMS developer.

It is important to mention that the CMS sample site should not be used directly as the starting point for a production CMS site. As written in the CMS ReadMe.html file, it is not a good idea to build an application on top of the sample objects. The reason for this is that the objects are accessed by the Site Deployment feature by their GUID. If a site is built on top of the sample objects, you could overwrite parts of the site by reinstalling the sample data.

The default install location for the CMS WoodgroveNet sample site is C:\Program Files\Microsoft Content Management Server\Sample Data. Microsoft plans to release new sample sites; you might want to check the CMS Web site for updates (http://www.microsoft.com/cmserver).

Content Connector

The Content Connector component is used to integrate CMS with Commerce Server 2002 features. For example, developers can use the Content Connector to display Commerce Server catalog information within a CMS page. Content Connector is not included in CMS 2002. This component is included with MSIB.

Content Connector is essentially a bridge between the Commerce Server 2002 API and the CMS PAPI. It was originally written using VBScript and Visual Basic. In the new version of Content Connector, the ASP pieces have been rewritten against the managed layers of the Commerce Server 2002 API and the CMS PAPI. The Visual Basic components, such as the Personalized Content Objects pipeline, have remained the same.



Microsoft Content Management Server 2002. A Complete Guide
Microsoft Content Management Server 2002: A Complete Guide
ISBN: 0321194446
EAN: 2147483647
Year: 2003
Pages: 298

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