An Independent Sitecore Learning Resource

Menu

Page Architecture: Template vs Component

Introduction

Sitecore's wide-open architecture and numerous APIs means that implementing a website in Sitecore can deviate in many directions. One particularly important aspect of architecture involves page construction - how should web pages in Sitecore be built?

Pages in Sitecore are constructed through a combination of content and presentation. How you bring those two together is a major architectural decision with two options and one obvious answer.

Because Sitecore content is organized in tree-based structure that resemble other CMS platforms, new developers tend to choose an architecture that is based on what they may already be familiar with: template-based pages. Sitecore's strength, however, is in its component-based page architecture. Let's take a look at both and see why component-based architecture is almost always the superior option.

Template-based Pages

With the template-based page approach, each page of a website is based on a static template. The template has all the fields a page would need to display content, whether it was headers, sub-headers, images, etc:

  • Fields on a template

    This template has all the fields a page needs...

  • Template fields displayed on a page

    ... and the content is displayed on the page as expected.

The design and implementation of this architecture is very straightforward. Each template has a corresponding presentation component (Sublayout or Rendering in Sitecore terms) that simply renders each template field in the appropriate place on the page. Due to this simple implementation, a template-based website could be built fairly quickly.

There are many downsides with this approach, however. Content cannot be re-used or shared across pages. Because each page contains only the content it needs, that content cannot be accessed by other pages (not without writing some potentially confusing code to load data across pages). Perhaps the single biggest knock against this architecture: content cannot be personalized, which ignores one of Sitecore's biggest strengths.

Component-based Pages

With a component-based page architecture, each piece of content on a page is tied to an individual presentation component. Each presentation component usually references a content item via a datasource.

This separation of content from presentation is one of the core concepts that makes Sitecore stand out as a CMS. By creating a many-to-many relationship between the two, content is not tied to just one presentation layout.

Template fields displayed on a page

One piece of content can be displayed multiple ways.

In the above example, the "Person" is content. That content can be displayed one of four different ways. This enables content reuse.

Template fields displayed on a page

A presentation component can display different content by swapping datasources.

Above, a single presentation component is able to swap which content item it utilizes, which enables core concepts like personalization and A/B testing in Sitecore.

The biggest downside to component-based pages lies in the development time: it takes quite a bit longer to create dozens of presentation components than simple template-based pages.

Summary

Even though this was a simplified overview of page architecture, it should be apparent that Sitecore's strength lies in its component-based architecture. Content re-use, presentation flexibility, and personalization are features that should easily justify the time spent developing components in Sitecore.