CmsHttpContext Vs CmsApplicationContext
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.
6 Comments:
Hi Chester,
nice summary!
You might want to check the columns agains as you mixed them up for Http and Application context in some rows.
Dispose: you might want to add that for CmsHttpContext this method is called in the CmsEndRequestModule.
Cheers,
Stefan
Hi Chester,
another note: the link to "Creating scalable applications using the CmsApplicationContext" is invalid.
Cheers,
Stefan
Chester- Are the columns correct? Looks like some of your explinations are in the wrong columns. Otherwise, great post!
-AC {MVP MCMS}
www.andrewconnell.com
Oops... Sorry for that mix-up. I had some problems in posting a table here. So I did some modifications and at last came up with a mixed up columns and rows. Thanks for that point (CmsEndRequestModule) Stefan. I'll add that. Also I couldn’t double check this because I posted this from home; from there I have only 16kbps dialup line, which is very slow and I can’t connect to internet for long time. Thanks for the feedbacks :-).
the BeanFactory provides the configuration framework and basic functionality, while the ApplicationContext adds enhanced capabilities to it, some of them perhaps more J2EE and enterprise-centric. In general, an ApplicationContext is a complete superset of a BeanFactory, and any description of BeanFactory capabilities and behavior should be considered to apply to ApplicationContexts as well.
greetings
cialis online
comparisons are very well done, I like your blog much like that of buy viagra
Post a Comment
<< Home