Experience Sitecore! | November 2013

Experience Sitecore!

Martin Miles on Sitecore

API - Useful IDisposable context switchers

Sitecore API provide several IDisposable context switchers, so I thought it's worth to review them in one place. Here they are:
  1. EditContext
  2. EventDisabler
  3. SecurityDisabler
  4. UserSwitcher
  5. LanguageSwitcher
  6. DatabaseSwitcher
  7. SiteContextSwitcher
  8. DatabaseCacheDisabler
  9. LockingDisabler
  10. LinkDisabler
1. EditContext
This is a very elegant way of editing an item in sitecore. What it does is automatically does item.Editing.BeginEdit(), item.Editing.EndEdit() as well as wraps that into try / catch block with item.Editing.CancelEdit() on Exception. You may map additional parameters into constructor to skip updating statistics (ie. last modified item's system field), suppress raising events (like item:save event) and also you may SecurityDisabler as a constructor parameter. 
// default usage
using (new EditContext(item))
{
    item.Fields["fieldname"] = "Some value to set";
}
// example of using with supressing events and avoiding statistics update
bool updateStatistics = false;  
bool silent = true;  
using (new EditContext(item, updateStatistics, silent))  
{  
    item.Fields["fieldname"] = "Some value to set";
}
// using EditContext and disable SecurityCheck together
using (new EditContext(iem, SecurityCheck.Disable))  
{  
    item.Fields["fieldname"] = "Some value to set";
}

2. EventDisabler
It gives exactly the same effect as if you were using Item.Editing.EndEdit(bool silent), passing true within silent. No events will be raised.
using (new EventDisabler())
{
    item.Editing.BeginEdit();
    // do edits
    item.Editing.EndEdit();
}

3. SecurityDisabler
Turns of permission check for operations performed within using block, regardless of if the user from the context can or cannot create / modify / move / rename /delete items. Beware as it may be insecure especially on CD instances. There is an alternative for this method - UserSwitcher (see below at 4). Here is an example of  SecurityDisabler usage:
using (new SecurityDisabler())
{
    subNode = homeItem.Add("SubNode", templateId);
    using (new EditContext(subNode))
    {
        subNode[fieldIdA] = "test";
        subNode[fieldIdB] = "testBBB";
    }
}

4. UserSwitcher
That is recommended practice (by Sitecore) to be used instead of SecurityDisabler. Everything you do is done in the context of a specific user. The user can be an Administrator and can do everything. Maybe you want to create a "service user" with only specific permissions or whatever, you can use this user to do what you want.
If you use the SecurityDisabler - Sitecore will not do any permission checks at all. In fact, the result will be the same as if you use the UserSwitcher() with an administrator, but you have no control over the context.
//User which is already created in Sitecore User Manager
 string testUser = @"sitecore\testuser"; 
if (Sitecore.Security.Accounts.User.Exists(testUser))
{
    //Getting Sitecore User Object with UserName
    Sitecore.Security.Accounts.User scUser = Sitecore.Security.Accounts.User.FromName(testUser, false); 
    //Switching Context User
     using (new Sitecore.Security.Accounts.UserSwitcher(scUser))
    {
        //Using EditContext to edit an Item
        using (new Sitecore.Data.Items.EditContext(home))
        {
            home["Text"] = "Modified Text from Code";
        }
    }
}

5. LanguageSwitcher
When working on multi-lingual website, you may have a need in retrieving the values in the language different than one you're having currently in the Context. Please consider the following code to achieve that:
var item = Sitecore.Context.Item;
using (new Sitecore.Globalization.LanguageSwitcher("fr"))
{
    item = myItem.Database.GetItem(item.ID);
}


6. DatabaseSwitcher
Sometimes you may need to do some database operations from the database
another than you currently have in Context, for instance you may have a specific task to look-up master database, or read some setting from core. Of course, such type of activities is fairly an exclusion from normal practice, so think well ahead. In any case, the following using switcher will be handy for that type of situations:
var master = Sitecore.Configuration.Factory.GetDatabase("master"))
using (new DatabaseSwitcher(master))
{
// now within this scope Sitecore.Context.Database is returning master database
}

7. SiteContextSwitcher
That one is use to substitute current site context. Usage is pretty easy:
var item = Sitecore.Context.Item;
using (new SiteContextSwitcher(SiteContextFactory.GetSiteContext("site_name_as_in_config")))
{
    // all the code here would run in the context of "site_name_as_in_config" site
}

8. DatabaseCacheDisabler
This one has become one of my favorites. When working with many items in background tasks etc., it will use the regular Items cache for fetching items, but on cache misses, it won’t put items loaded from the database into the items cache. This avoids the items cache from being polluted by for example a background task traversing multiple items. As the number of items grows in a solution, it’s important that the items being accessed by users are in the cache and aren’t outcompeted by one-time operations etc.
var item = Sitecore.Context.Item;
using(new DatabaseCacheDisabler())
{
  // your code here...
}
9. LockingDisabler
The __lock field isn’t updated also the locking events aren’t fired, so that switch effectively d
isables the item locking mechanism.

10. LinkDisabler
This is one is handy but use it with care as it disables updates of the Links Database. This may speed up item saves when doing changes to items from code that you know won’t change any links.

Hope you find this article helpful.