Insights hero banner (short)


Bringing our best ideas and thinking to you.

  • Blog Post
  • WCMS

Blog Post

September 7, 2016

Share this page:

Templating Strategy in Sitecore

By Dan Wallace

Templates are fundamental to content management in Sitecore, and a good templating strategy can save hours, days, or even weeks of work, but settling on one can be a little bewildering. Developers have searched for similarities to help them relate the function of a template to something familiar like a class or an interface, but the trouble in making these analogies is that it can be similar to any of these depending on how the template is to be used.

A template is a type of Sitecore item that is used as a basis when creating and editing of other items. Templates generally have standard values associated with them which are then referenced as a back-up wherever a field is left blank by a content author.

Often, developers simply put all the fields required to render a page on the page template itself. While this may be tempting to do, it creates several problems. For instance, consider a content page with a 'Title' field, a 'Content' field, and two widgets. Each widget also renders from a 'Title' field and an 'Image' field. If all the fields are put on the item, fields will need to be created for each instance of the widget: 'Widget title 1', 'Widget title 2', 'Widget image 1', and 'Widget image 2'. If a third widget is added later on, more will have to be added, and those fields will exist on every other instance of this template, even if they are never used. To make matters worse, the developer is now faced with the alarming prospect of having to assign dynamic keys to components rendered on the page. This is, simply put, an abominable state of affairs to find oneself in.

Instead, templates should be divided between three categories: Content, Data and Meta.

Data templates describe non-navigable items to be used as data sources for components on content items. This makes it easier for users to add and remove components from a page, and allows them to define data sources that can be used across many items without need for duplication. Consider a banner component as a sample use case: Users define one common banner item to be used across the site. A user wants a new banner for a particular page, so they create one and edit the banner component data source to use the new banner. If they want to change banners across the site, they have a single data source item to edit, rather than requiring authorization to change the standard values for the page template. If users want to add additional sub-banners later on, or if they wish to remove the site banners entirely, no additional fields need to be created or removed. In this manner, the amount of duplicate data is kept to a minimum.

Meta templates are abstract: they define fields that are used between several different item types, and are only meant to be inherited from in order to define other templates. There is never any reason to create an item from a Meta template, nor any reason to put a meta template into any insert options. Consider Meta data as a sample use case: Users want to associate meta data with pages. A developer creates a component to render it, and a Meta Data template to define the fields. This Meta Data template is then inherited to each content template, where meta data is desired. Because a single template is used, the fields associated with it are only defined once, which allows developers to reference them using Sitecore Globally Unique Identifiers (GUIDs) independently of field names. This increases code maintainability and template design flexibility.

Content templates represent navigable pages on the site. They define fields that are specific to that page and that page only, like article content, meta data, or an article title.

Overall, this keeps component data separate from page data, which allows users to reuse peripheral content easily.