Taking Advantage of Sitecore Dictionary and Tokens

The Sitecore Dictionary is one of the newer features that may have gotten under a developer’s radar.  I’m sure there has been chances when a page design element just doesn’t fit any of the data template fields that’s been defined. Designers or content developers always surprise Sitecore developers with “minor” requirements that have been left out in the specs just because it’s so trivial.  In the CMS world, nothing is trivial because of the fact that site owners want as much control on the site as possible (without going back to a developer – this has been the issue forever).

Let me paint a picture.  Say you have a news details template and corresponding rendering.  Plus, page design shows “related articles”.  Sure it’s easy to do this in Sitecore by just creating a multi-list type of field (i.e. treelist, etc.).  Well, the design shows that the title “Related Articles” and the site owner wants to be able to change that title once in a while.  Let’s just say that we created a rendering just for the related articles page section.  So, to allow the site owner to update the title, we can either pass it as a parameter to the rendering.  Or, this one I don’t recommend, just add another field in the news template or a settings page or elsewhere and use that field as the place to update the title.  These are of course valid solutions though they are limiting and requires more knowledge that a typical business user that only wants to update content. 

Let me give you another scenario.  What if you want to allow the content author to add “IFRAME” based content?  Of course you can just add a rendering that wraps a URL with some parameters.  Sure, but that’s also limiting to that particular application.  Plus, you’re adding another Sitecore asset (we have a philosophy that the fewer Sitecore assets to achieve the business needs is better).  Remember also that the rich-text editor (RTE) somehow restricts IFRAME by default.

Sitecore Tokens are basically what you might call term placeholders.  You may have created this already with email templates.  If you’re familiar with NVelocity then you will like tokens since it complements it (for those not familiar with NVelocity…you should).  Part of a Dictionary item is a key field that identifies the term. Tokens can be used in any field particularly in a rich-text editor.  Just so you know, the facilities are there to have tokens, but you have to do some coding to make them work.

Here are a few tips to think about when using Sitecore Dictionary and Tokens:

- read the Reusing and Sharing Data document in SDN under Reference > Sitecore 6 References to get some background and fundamentals

- use it for terms, quick text, IFRAME’s or other markup tags that RTE may not support out of the box (even scripts)…although there’s other ways to create IFRAMES, this doesn’t conflict with the RTE

- create Web controls (i.e. literal) and XSLT controls to show Dictionary items so that you get the benefits of translation

- use RTE snippets to let authors add them as part of their content much easier (or better yet, create an enhancement on the RTE to automatically show available tokens in a drop-down)

- develop a generic renderField pipeline code that replaces tokens without using the web.config to identify available tokens

- figure out a way to identify available tokens through some setting that can be updated through the Sitecore shell and not through a configuration file or just allow all Dictionary items to be “token-able”

I really like the additions of the Dictionary but I think it’s not fully there yet.  Here are some things to think about on a future release:

- fully support the Dictionary and Tokens by providing APIs, Web controls, XSLT enhancements (i.e. sc:Dictionary), etc.

- although the Phrase is a very generic field where you can put basically anything, maybe make the Dictionary template be more flexible and easier to use by adding other field types (i.e. image) in the same template and having the order of fields be its hierarchy if multiple fields have content

- use Tokens to enhance “default” field values (i.e. $name); in a way, allow us to add more “tokens” for branch templates or __standard values by adding more tokens

- enhance tokens to also support presentation rendering such as a dynamic list of items in a RTE; essentially, letting the token be a placeholder for some rendering

As you can see, Dictionary items and Tokens are simple yet very powerful concepts.  They make developers’ and authors’ work easier.  They provide alternatives to design elements without creating fields for every content based on a design.  They give us more alternatives for presentation.  They are definitely great…but make sure to balance it out with great care because you could end up with so much of them that your solution becomes hard to understand.  So use them cautiously.