Extending Sitecore Helix Template Guidelines

June 8, 2017

Blog | Strategy | Extending Sitecore Helix Template Guidelines

Sitecore is known as a very flexible content management platform.  This can be a good thing and a bad thing. To help add some structure to Sitecore implementations, Sitecore created the Sitecore Helix Principles in 2016.

At GeekHive, we feel the Sitecore Helix principles are a much needed addition to the Sitecore community.  Not only do they improve quality for novice developers, they also reaffirm many held beliefs from experienced Sitecore partners like GeekHive. Their intention is to bring uniformity across partners and implementations. While they are a great starting place, we feel we can push their principles even further.  Prior to the Helix creation, we were hard at work trying to improve consistency across projects.  Our goal was to reduce ramp-up time for new developers on projects and provide a tried and true structure for seeding a website.  We reviewed the Helix Principles regarding Template Structure and Template Types and combined them with our years of experience to create the approach outlined in this article.

Our Approach

Pages

As the name implies, this is where page templates are located.  These items will have presentation details assigned and be navigable within the site.

Pages are further broken down into Interface templates and Implementation templates.  The logical breakdown of Interfaces and Implementations flows into code generation as well.  Whether we are using GlassMapper or another ORM, the resulting item classes follow the same framework as our content tree.

Interfaces
  • Interface templates never appear in the content tree.  
  • Interface templates are base templates with fields pertaining to their function.
  • They can also inherit from each other.  In the example above, _Page inherits _MetaData, which implies all templates that inherit _Page will have _MetaData on them.
  • These templates may have presentation details.  In the case of the _Page template, it would make sense to include the main layout for the site as well as shared header and footer type elements that all pages that inherit from this template will rely on.
Implementations
  • Implementation templates do appear in the content tree.
  • Inherit Interface templates. In the above example, both HomePage and ContactUs would inherit the _Page interface.
  • Do not inherit other Implementations.
  • They can have fields pertaining to their specific page type, but mainly inherit from Interface templates.
  • Presentation details are defined on these templates standard values.
  • Insert options are defined in the standard values.

Datasources

Datasource templates only include item types that are defined in a rendering to be a selectable datasource.  Much like Page templates, Datasource templates are further broken down by Interface and Implementation.

Interfaces
  • Interface templates never appear in the content tree.  
  • Interface templates are base templates with fields pertaining to their function.
  • They can also inherit from each other.
Implementations
  • Implementation templates do appear in the content tree.
  • Are directly linked to via a rendering.
  • They can have fields pertaining to their specific type, but mainly inherit from Interface templates.  In the above example, ImageCTA inherits both interfaces _CTAImage and _CTATitleBody.  Whereas SimpleCTA inherits only _CTATitleBody.  Carousel does not inherit any base templates, but may have fields specific to it’s function.
  • Insert options may be defined in the standard values.  In the above example, Carousel would have an insert option of CarouselSlide (see below) defined on it’s standard values .

Repositories

Repository templates are item types that will be among other items of the same template within the content tree as siblings.

  • May have siblings of the same or similar type.  In the above example, a folder template (see below) may have an insert option of State, and therefore State items would have siblings of other States.  CarouselSlide would be an insert option of Carousel (see above) and therefore several CarouselSlides could be added as children to a Carousel.
  • Are not directly linked to via a rendering.

Folders

Folder templates define an item type that has insert options defined to include an expected item type.

  • Have insert options defined on standard values.
  • Can insert itself to introduce nesting to the folder structure.
  • Never used as a datasource for a rendering.
  • Has no fields defined on it.

Settings

Settings templates pertain to any item that will live in an expected location within the content tree and universal settings needed for the application.

  • One instance of setting per site, or globally.
  • Contain settings not unique to current request.
  • May have insert options for other settings types.

Rendering Parameters

This is the most simplistic logical group of templates.  It contains any rendering parameter templates in use.

Is this the Gold Standard?

We are constantly evolving our best practices at GeekHive.  The philosophy in this article is the result of countless hours pouring over new and existing projects.  It comes with years of experience finding what works and what doesn’t.  We look at the Helix principles as a great tool to suggest possible ways to approach a Sitecore implementation.  We have found that making a few small tweaks to the approach outlined by Helix, we are able to develop more efficiently, reduce knowledge transfer sessions and refactor less often.  This approach allows us to meet the high demands of our clients and spend our energy on other tasks, knowing that our foundation is solid.

John Rappel

.NET Practice Lead
Tags
  • Best Practices
  • Sitecore
subscribe to GeekHive's newsletter

Never miss out on a Sitecore update again!

Our newsletter features a blog roundup of our top posts so you can stay up to date with industry trends, tutorials, and best practices.

Recent Work

Check out what else we've been working on