Page Processing in Presentation Mode

When a page is requested by a user in presentation mode, the placeholder content is rendered as part of the resulting page HTML. The user is not aware that some parts of the page are static and others are generated dynamically; the HTML for the page is assembled on the server using a combination of data from the CMS database and the server file system. This process involves several steps. Figure 11-1 shows the logical architecture of the processing and the steps involved. Let's look into these steps.

Figure 11-1. Logical architecture of CMS page processing

Step 1

The user types a URL, or clicks a link, pointing to a CMS page in a browser for example, http://www.botsconsulting.com/offices/uk. It is a user-friendly hierarchical URL. The page request arrives at the IIS site for example:

 :GET /offices/uk HTTP/1.1 Host: www.botsconsulting.com 

Step 2

IIS has the CMS server installed, and the virtual Web site has been enabled as a CMS Web entry point. Therefore, the request is passed to the CMS ISAPI filter. The filter is called the Resolution filter and can be found at <installation drive>\Program Files\Microsoft Content Management Server\Server\bin\ReAuthFilt.dll. The Resolution filter analyzes the URL to identify whether the request is for a CMS page or resource. If not, the request is returned to the IIS for processing.

If the filter has identified the request as a CMS page request, it searches the database for the information that corresponds to the requested posting. It obtains the posting GUID and follows the posting to the metadata for the template associated with it. The template metadata includes a reference to the name and location of the template ASPX file. The filter gets the template ASPX file name and then constructs a new URL that points to the ASPX file and contains the posting GUID as one of the query string parameters. It looks similar to the following example:

[View full width]
 /botsconsulting/templates/office.aspx?NRMODE=Published&NRNODEGUID= %7b7DE6CC74-73ED-4EBC-BBC0-04714D6EA80A%7d&<other query string parameters> 

In this example, the NRMODE parameter specifies that the published version of the page is requested, and the NRNODEGUID parameter identifies the posting GUID.

The filter then passes the transformed URL back to IIS.

NOTE: The hierarchical URL in the original request identifies the page location in the channels hierarchy; it is purely a logical path as set up in the CMS server. What the Resolution filter does is convert this logical path to a real URL of a template ASPX file. The query string parameters identify the page-specific content and the processing mode. It is this ASPX file and the query string parameters that CMS server uses to compile the posting for IIS to serve.

Step 3

IIS analyzes the request and passes it to the appropriate worker process for processing. This step is performed differently in IIS 5 and IIS 6 because their architectures are different. In IIS 5, because the request is for an ASPX file, it is passed to the ASP.NET ISAPI filter aspnet_isapi.dll, which in turn passes it to the ASP.NET runtime worker process, aspnet_wp.exe. In IIS 6, depending on the IIS isolation mode, the request is either passed to the Web worker process w3wp.exe in IIS 6 isolation mode (which in turn has an ASP.NET ISAPI filter installed), or the request is run by a worker process within inetinfo.exe in IIS 5 isolation mode.

NOTE: For information about IIS 6 isolation modes, refer to the IIS 6.0 Architecture section in the IIS 6 product documentation.

Step 4

The worker process deals with the request as with any other ASPX request. First of all, the request goes through the HTTP module pipeline.

An example of an HTTP module pipeline as defined in a machine. config file is shown in the sidebar, together with an explanation of how HTTP modules work. The modules perform various tasks, including cache and state management, and security authentication and authorization.

HTTP Pipeline

An HTTP pipeline is a sequence of HTTP modules. An HTTP module is a class that implements the System.Web.IHttpModule interface, as follows:

 :public interface IHttpModule {              void Init(HttpApplication context);              void Dispose(); } 

For each HttpModule in the pipeline, the worker process calls the module's Init and Dispose methods. Init is called when the module is attached to the HttpApplication object, and Dispose is called when the module is detached from HttpApplication. The Init and Dispose methods allow the module to hook into events exposed by HttpApplication, including the beginning of a request, the end of a request, a request for authentication, and so on.

The HTTP modules in the pipeline are able to modify a request as it goes through.

Here is an example of an HTTP module pipeline contained in the machine. config file.

[View full width]
 <httpModules>             <add name="OutputCache" type="System.Web.Caching .OutputCacheModule"/>             <add name="Session" type="System.Web.SessionState .SessionStateModule"/>             <add name="WindowsAuthentication" type="System.Web .Security.WindowsAuthenticationModule"/>             <add name="FormsAuthentication" type="System.Web .Security.FormsAuthenticationModule"/>             <add name="PassportAuthentication" type="System.Web .Security.PassportAuthenticationModule"/>             <add name="UrlAuthorization" type="System.Web .Security.UrlAuthorizationModule"/>             <add name="FileAuthorization" type="System.Web .Security.FileAuthorizationModule"/> </httpModules> 

The CMS site is an ASP.NET Web application, and it has its own web.config file. The HTTP pipeline for the CMS site consists of HTTP modules defined in the machine.config and web.config files; all HTTP modules in machine.config and web.config are initialized when the application starts.

When you create a CMS project in VS.NET, the web.config file is created for you. It includes four CMS-specific HTTP modules, as follows:

[View full width]
 <httpModules>       <add type="Microsoft.ContentManagement.Web.Security. CmsAuthorizationModule,  Microsoft.ContentManagement.Web, Version=5.0.1200.0, Culture=neutral,  PublicKeyToken=31bf3856ad364e35" name="CmsAuthorizationModule" />       <add type="Microsoft.ContentManagement.Web. CmsEndRequestModule, Microsoft .ContentManagement.Web, Version=5.0.1200.0, Culture=neutral,  PublicKeyToken=31bf3856ad364e35" name="CmsEndRequestModule" />       <add type="Microsoft.ContentManagement.Publishing.Events. PostingEventsModule,  Microsoft.ContentManagement.Publishing, Version=5.0.1200.0, Culture=neutral,  PublicKeyToken=31bf3856ad364e35" name="CmsPosting" />       <add type="Microsoft.ContentManagement.Web.Caching. CmsCacheModule, Microsoft .ContentManagement.Web, Version=5.0.1200.0, Culture=neutral,  PublicKeyToken=31bf3856ad364e35" name="CmsCacheModule" /> </httpModules> 

The HTTP modules specified in CMS web.config have the following functionality:

• Microsoft.ContentManagement.Web.Security.CmsAuthorization Module performs the authentication and validates that the requesting user has sufficient rights to requested objects.

• Microsoft.ContentManagement.Web.CmsEndRequestModule makes sure that all resources allocated during the request processing in the CMS Web application are released.

• Microsoft.ContentManagement.Publishing.Events.PostingEvents Module implements CMS publishing events; it is used in conjunction with event handlers in global.asax for extending the publishing workflow.

• Microsoft.ContentManagement.Web.Caching.CmsCacheModule handles CMS cache invalidation and makes sure that only published MCMS content is stored in the output cache.

NOTE: We will look into CMS security in Chapters 17, 19, and 20, and extending the publishing workflow in Chapter 31.

As a result of the request processing by the appropriate CMS-specific HTTP modules, if the request is authorized, the CMS context for ASPX template execution is created. Several CMS PAPI objects are instantiated and initialized:

• CmsHttpContext object

• Posting object

• Template object

Figure 11-2 shows the relationship between the PAPI objects that are used in the CMS Web application for ASPX template processing. We will be discussing these objects and their role in page processing in the next several pages.

Figure 11-2. CMS objects and ASPX template processing

The CmsHttpContext object is created for every request, or, to be precise, for every System.Web.HttpContext ASP.NET object, which in turn is created for every request. The CmsHttpContext object serves as an entry point to the PAPI object model; all other objects are retrieved from this class. The template code uses the PAPI object model; therefore, a CmsHttpContext instance must be available when template execution starts. The code in the ASPX template accesses the instance using the CmsHttpContext.Current property.

The CmsHttpContext.Mode property provides a way to determine whether the request is for the published or unpublished version of a page, and whether database updates are required. When a page is requested in presentation mode for viewing, this property is set to Published. The property takes its value from the NRMODE parameter in the query string of the transformed ASPX URL in the request.

NOTE: We will look into the CmsHttpContext object in detail in Chapter 24.

The Posting object corresponds to the requested page. Information about the posting is read from the CMS database using the GUID provided in the query string of the ASPX URL. This process consists of several steps: The CMS content server reads the data from the database and exposes this data to a COM-based PAPI; this data is then exposed to the ASP.NET environment using the Posting object in the managed PAPI layer.

NOTE: We will look into the Posting object in detail in Chapter 26.

The Template object corresponds to the template on which the requested page is based. The template metadata from the CMS database is read and exposed using the Template object in the same way as described earlier for the Posting object. The Template object has various properties that expose the metadata that is required for ASPX template file execution for example, the placeholder definitions collection (Figure 11-2).

Step 5

After the HTTP pipeline, the request goes to the ASPX template. The template file (and the code behind) includes static HTML and the server controls. It may also include user controls, JavaScript, or anything else you would put in an ASPX page. If it is the first request for the ASPX file, then it is retrieved from the file system, compiled, and put in the ASP.NET cache; for subsequent requests, it is run from the cache. The worker process instantiates the compiled class and any contained classes, such as server controls and HTML elements, and runs the code.

The placeholder content for a page is rendered by the placeholder server controls. Each placeholder server control is bound to the managed PAPI PlaceholderDefinition object that, in turn, determines the Placeholder object (Figure 11-2). When a placeholder server control runs, it instantiates and initializes a Placeholder object. The Placeholder object obtains the placeholder content from the database and then exposes it to the placeholder server control. After the content for all placeholders has been obtained, the resulting page is assembled and is ready to be returned to the requesting user.

During template execution, Web Author server controls run. If the requesting user has authoring rights, the Switch to Edit Site link is displayed in the resulting page.

NOTE: We will look into Web Author rendering in the next main section.

Step 6

If ASP.NET output caching is enabled in the template ASPX file, the page is cached by the worker process for use by subsequent requests.

Step 7

IIS sends the page back to the requesting browser.

NOTE: In CMS 2001, the resulting page was put in the CMS dynamic cache. By default, this cache was located in the /NR/ExeRes virtual directory on the IIS site that pointed to the physical directory <installation drive>\Program Files\Microsoft Content Management Server\Server\exeres. Then a URL that reflected the location of the resulting page in the dynamic cache on the file system was returned to IIS. It looked similar to the following example:

/NR/ExeRes/7DE6CC74-73ED-4EBC-BBC0-04714D6EA80A.htm

In CMS 2002, this virtual directory is also present, but it is not used for dynamic caching, and the resulting pages are not put into it. Instead, the pages are cached in the ASP.NET output cache. However, the same URL format is still being used. It doesn't reflect the actual location of the file; it is just a convention inherited from the previous version of CMS.

The browser gets the page, parses the HTML, and issues additional HTTP requests for the resources that are required to build the page, such as images, cascading style sheets, JavaScript files, or any other files. The processing of these requests differs from what we've discussed so far. Figure 11-3 shows the logical architecture and the steps involved in the processing of CMS resource requests.

Figure 11-3. Logical architecture of CMS resource processing

CMS Resource Processing

1. The browser issues a request.

2. IIS gets the request and passes it to the CMS Resolution ISAPI filter. If it is a request for non-CMS content, the request is returned to IIS. If the request is identified as a CMS resource request, the ISAPI filter passes the request to the CMS content server.

3. The CMS content server verifies the rights, and if the request is authorized, the server checks whether this is the first time the resource has been requested. If this is the case, CMS retrieves the requested resource from the database.

4. The retrieved resource is put in the CMS static cache for use by subsequent requests. By default, the CMS static cache is located in the /NR/RdOnlyRes virtual directory on the IIS site that points to the physical directory <installation drive>\Program Files\Microsoft Content Management Server\Server\rdonlyres.

   A URL that reflects the location of the resulting file in the static cache is returned to IIS. It looks similar to the following example:

    /NR/RdOnlyRes/2206150E-E01C-4473AE7F-D3EDAC2DFE99/0/<resource name> 

5. IIS uses the returned URL to retrieve the resource file from the cache and send it back to the requesting browser.