Nickoli previously wrote a post introducing Context Variables, with nice Custom Functions to get and set them from your Dreamweaver Templates.  This post discusses the scope of Context Variables, and how that leads to other useful applications like caching.

For those who have not used them, the SDL Tridion Templating API makes available a dictionary that can be used to temporarily store variables when publishing items – Context Variables.

So the first question is: Where do I find this Dictionary? The answer is to look in the engine object that is passed as one of the parameters to the Transform method.

 Dictionary variables =
    engine.PublishingContext.RenderContext.ContextVariables;

The next question is, What is the scope of these variables – if I put a variable in, when can I take it out?

It turns out that the scope is that of the whole publishing transaction. This means that if I publish a Page, the Page Template and Component Templates share the same set of Context Variables. If I publish a Structure Group, then all Pages rendered share the same Context Variables. If I publish a Component or Page template, all CPs or Pages rendered share the same Context Variables.

This means we have a cache that is valid for the duration of a publishing transaction. For example, supposing I have some configuration which is required for all of my templates (perhaps a set of static text labels, a date format, the current language or locale). In my template code I can add a context variable with the configuration data, and then read this out in any further processing that is done as part of the same publishing transaction without having to load the configuration component, or access the publication metadata or wherever the configuration was stored.

So is this really worth doing? If we are publishing a single Component Presentation there is little benefit, but if we publish a page containing 10 CPs, we save ourself 10 times doing the same processing. If we publish a Structure Group containing 100 such pages, we save 1000 times (and so on). Tridion has its own internal caching of objects during the scope of a Publish Transaction and the rendering of template itself is likely to be more intensive than any configuration reading, but given that it is simple to implement such caching (especially with my helper functions below), it is probably worth doing – especially if you are doing some time-consuming calculation (for example recursively checking parent Structure Group metadata to write out default HTML metadata values for a page – when publishing a given SG, this calculation can be done a single time from that given point in the SG hierarchy)

I find that usually I want to push the context variables I am working with into the package so they can be easily accessed in both Dreamweaver Layout TBBs and .NET TBBs. To help work with Context Variables as package items I created a couple of helper functions that you can use in your template initialization logic as follows:

//Push global package items (from cache if available)
if (!PushFromContextVariable("MyUsefulData"))
{
    Dictionary<string, Item> items = new Dictionary<string, Item>();
    //add code to read your configuration or other data here and add
    //separate package items to the items Dictionary
    PushAndAddToContextVariables(items, "MyUsefulData");
 }

The source for the 2 helper functions is given below (these functions assume that you have _package and _engine member variables in your ITemplate class, which are initialized with the engine and package parameters passed to the Transform method)

protected bool PushFromContextVariable(string variableName)
{
    if (_engine.PublishingContext.RenderContext != null && _engine.PublishingContext.RenderContext.ContextVariables.Contains(variableName))
    {
        Dictionary<string, Item> items = _engine.PublishingContext.RenderContext.ContextVariables[variableName] as Dictionary<string, Item>;
        if (items != null)
        {
            foreach (string key in items.Keys)
            {
                _package.PushItem(key, items[key]);
            }
        }
        return true;
    }
    return false;
}

protected void PushAndAddToContextVariables(Dictionary<string, Item> items, string variableName)
{
    if (items != null)
    {
        foreach (string key in items.Keys)
        {
            _package.PushItem(key, items[key]);
        }
    }
    if (_engine.PublishingContext.RenderContext != null && !_engine.PublishingContext.RenderContext.ContextVariables.Contains(variableName))
    {
        _engine.PublishingContext.RenderContext.ContextVariables.Add(variableName, items);
    }
}

While caching can be pretty useful, I have also used Context Variables in practice in the following different applications. 

1. Passing information between Page and Component Template – while it kind of breaks content modularity, it is sometimes it is unavoidable (and indeed forced by poor HTML design) to pass information between page and component templates. For example, I may want my CT to render slightly different HTML if it is rendering the first or the last Component Presentation on the page. By creating a Custom Function I can set the CP index as a context variable (from within the loop rendering the CPs in my Page Template), and then read that in my CT.
2. Managing state within execution of a Dreamweaver Template. Conditionals and loops are possible using the Dreamweaver templating language, however sometimes it is useful to manage state within loops (especially nested loops). Nickoli’s original post has Custom Functions to set and get Context variables.

If you have found other uses for Context Variables it would be great to hear about them…