Monday 23 March 2015

Creating your own context objects

Context objects


Sitecore provides a number of contexts to allow you to enable and disable certain framework features on a case by case basis. For example if you want to run a piece of code without any security concerns you can use the SecurityDisabler.
using (new SecurityDisabler())
{
    // your code here
}
Any code inside the SecurityDisabler block will ignore all security concerns, so it can create items, edit items, delete items etc without the logged in user having the appropriate permissions. Another common context to use is the BulkUpdateContext. If you are doing a lot of updates to Sitecore items as part of a maintenance routine then putting your code inside a BulkUpdateContext stops Sitecore from recording things in the history engine which will increase the performance of your code.  Similarly the EventDisabler prevents events from being raised.

It's a handy technique that you might want to leverage yourself. In one solution we had caching built at a deep layer, but for certain admin functions we didn't want to use the cache, we always needed the actual data. The solution was to use our own context that could disable caching.

Monday 9 March 2015

Giving content editors control over styles

Introduction

When building a Sitecore solution one of the largest mindset decisions is who the client of your solution is going to be.  Is your site going to be managed by developers?  Or is it going to be managed by the business?  One of the advantages of a CMS is that it gives the business the ability to manage the site themselves, ie your marketing people, your product people and so on, who can run the site without needing help from a developer.  This concept of an end product that can be managed without developer input is of benefit to everyone; the business can instantly do the things they want to do, and developers only need to spend their time developing and not changing META data or page titles.  However many of the Sitecore solutions I get asked to consult on can only realistically be maintained by developers.

There are a few common practices that make for a "developer only" Sitecore solution, but the one I am going to discuss in this blog revolves around configuring styles.  This article assumes you already understand the basics of creating renderings, it's not going to be a complete tutorial on creating Sitecore components.