CmsHttpContext Vs CmsApplicationContext

June 6, 2007

when I surfing on net I found very good article on MCMS API. I found its very useful.

Compared On CmsHttpContext CmsApplicationContext
Instance Only one instance can be created using Current property. When we call CmsHttpContext.Current, the request is send to the server and it will check the HttpContext for an existing CmsHttpContext. If it finds one, then it will returns that. Otherwise it will create a new instance of it with the current identity, save that in the HttpContext and returns the new one. Any number of instances can be created with the constructor. All the instances will be created with an authentication and mode.
Authentication It will take the correct authentication from the current HttpContext. The identity will be created accordingly (Windows Identity or Passport Identity or Forms Identity) and the correct token will be taken for the creation of a new context. There are four kind of Authentication available with four different type of overloads. The appropriate one can be used. For more info on this, check the PAPI help.
Where it can be used This one can be only used in application’s which comes under HttpContext (web applications and web services). This can be used in windows applications, web applications, console applications, web services, etc.
Mode An instance is created by the server with the mode, which depends on the request we send. It can’t be changed. Must switch the request to change the mode (it will create an instance with that mode). An instance can be created with any mode which is required. It can’t be changed, a new instance must be created with a different mode.
Duration Because this is used in web based, duration of the instance is small. It is possible to have long running sessions (duration of time from when an object is modified to when CommitAll() is called) using this. But it is not a good practice to have long sessions. Because long running sessions can block accessing a site.
Dispose() It is not necessary to dispose the instance always, it will automatically handled by the server – CmsEndRequestModule will call this, if there is a valid instance exist in HttpContext after the response is send to client. After the use of CmsApplicationContext instance it must be disposed. Otherwise it may give problems. For more
information check Creating scalable applications using the CmsApplicationContext.
RollBackAll() After calling RollBackAll(), the instance is invalid, but after the call to this method, if we don’t use the instance, no need to call Dispose(), server will handle that. If we use after calling this, then its a must to call Dispose() and get a new instance. After calling RollBackAll(), the instance is invalid and it must be disposed and a new instance must be created for future use.

There are few properties and a method which are only available in CmsHttpContext(driven from CmsAspContext). They are not available in CmsApplicaitonContext. They are Channel, ChannelItem, CmsQueryString, IsUsingTemplate, Posting, UserCacheKey, ChannelItemIsVisible and ResolveUrl (). For more information, check the PAPI documentation.

Reference Taken From :

http://chestermr.blogspot.com/2005/05/cmshttpconte…

as such you will find lot of good articles in chester’s blog.


How Content Management Server works?

June 1, 2007

Introduction

On a traditional Microsoft ASP.NET–based Web site, when a request for a Web page comes in to the Microsoft Internet Information Services (IIS) Web server, the Microsoft ASP.NET Internet Server API (ISAPI) extension catches incoming requests for ASP.NET–based files (based on file extension). The ISAPI extension then forwards these requests to the ASP.NET worker process.

Traditional ASP.NET-based page processing

1. The browser requests a Web page from IIS.
2. The ASP.NET ISAPI extension determines that the request is for an ASP.NET–based file.
3. The extension passes the request to the ASP.NET worker process.
4. The worker process assembles the page, and then returns it to IIS.
5. IIS returns the page to the browser.

For more information about page processing on traditional ASP.NET–based sites, see The ASP.NET HTTP Runtime.

What happens when IIS receives a request for a Web page on an MCMS Web site? MCMS works with IIS, an MCMS ISAPI filter (called ReAuthFilt.dll), and the ASP.NET worker process to handle incoming page requests.

The following diagram shows the nine basic steps.

MCMS ASP.NET–based page processing

1. The browser requests a Web page from IIS.
2. The MCMS ISAPI filter determines that the request is an MCMS page (posting) or resource.
3. The filter rewrites the request with help from the MCMS Content Server.
4. The filter passes the updated request back to IIS.
5. The ASP.NET ISAPI extension determines that the request is for an ASP.NET–based file.
6. The extension passes the request to the ASP.NET worker process.
7. The worker process communicates with the MCMS Content Server to assemble all the information for the page.
8. The ASP.NET worker process returns the assembled page to IIS.
9. IIS returns the page to the browser.

You can see that most of the steps are the same as those for traditional ASP.NET–based pages, but with two big differences:

· The MCMS ISAPI filter catches MCMS requests and rewrites them with help from the MCMS Content Server.
· The page is assembled differently: the ASP.NET worker process communicates with the MCMS Content Server.

The MCMS ISAPI Filter

When a page or resource request arrives through IIS, the MCMS ISAPI filter (ReAuthFilt.dll) traps it. An ISAPI filter always runs on an IIS server, filtering every request until it finds one it needs to process. For more information about ISAPI filters, see ISAPI Filter Overview.

MCMS Pages

For an MCMS page, the filter takes the URL apart to find the relevant Posting. MCMS “friendly” URLs are constructed as follows: http:/servername/channel/channel/posting.

Note   MCMS friendly URLS do not have extensions, for example posting, posting.aspx and posting.abc all work.

After the filter has determined the Posting, it determines the Template and the template file (Template.SourceFile), and then it constructs a new URL using the ASPX template file. The new URL contains several query string parameters, including the GUID of the posting, which is used to find the placeholders for the posting. Then the filter passes the transformed URL back to IIS.

MCMS Resources

The filter categorizes an MCMS resource as one of the following:

· A resource from an MCMS resource gallery.
· A “local resource” that is not stored in a resource gallery.
MCMS handles local resources the way a traditional ASP.NET–based Web site handles them.

To handle a request for a resource from an MCMS resource gallery, MCMS uses a disk cache rather than retrieving a resource from the Content Repository database. MCMS removes the resources from the cache when they are updated or deleted from the Content Repository.

The following steps shows how resources from an MCMS resource gallery are served when they are already in the disk cache.

MCMS processing resources already in the disk cache

1. The browser requests an MCMS resource, such as a graphic, from IIS.
2. The MCMS ISAPI filter determines that the request is an MCMS resource.
3. The filter checks with the MCMS Content Server that the user has rights to the resource.
4. The filter retrieves the URL of the resource in the disk cache.
5. The filter returns the resource URL to IIS.
6. IIS returns the resource to the browser.

If the resource is not in the disk cache, MCMS first places a copy of the resource from the MCMS Content Repository in the cache, and then returns it to the browser.

The following steps shows how resources from an MCMS resource gallery are served when they are not already in the disk cache.

MCMS processing resources not yet in the disk cache

1. The browser requests an MCMS resource, such as a graphic, from IIS.
2. The MCMS ISAPI filter determines that the request is an MCMS resource.
3. The filter checks with the Content Server that the user has rights to the resource.
4. The Content Server makes a copy of the resource from the Content Repository.
5. The filter places the copied resource in the disk cache.
6. The filter retrieves the URL of the resource in the disk cache.
7. The filter returns the resource URL to IIS.
8. IIS returns the resource to the browser.

Assembling MCMS Pages

An MCMS page is built of several pieces, which are all assembled just at the time when a browser makes the request for the page.

Note   You can implement ASP.NET output caching on your Web site; however, that is not discussed in this article. For more information, see Enabling ASP.NET Output Caching.

Because the content in MCMS pages is edited from the browser, MCMS pages are assembled during authoring time as well as presentation time.

MCMS pages are based on template files, which contain placeholder controls and resources. When the ASP.NET worker process executes a template file, placeholder controls on the template file create instances of their placeholders and placeholder definitions. The placeholders retrieve content from the Content Repository or from the page request when a Web Author user previews a page containing new content. The worker process requests resources through a separate process, discussed in MCMS Resources.

The following diagram shows how an MCMS page is assembled.

Conclusion

MCMS works in a way that is similar, but not exactly the same, as a traditional ASP.NET-based Web site. Incoming requests are handled by IIS and the ASP.NET worker process, but MCMS and the MCMS ISAPI filter are also involved.

After an MCMS page is requested, it is assembled from information on the file system and in the Content Repository. This enables newly edited MCMS pages to always display up-to-date content.