In this tutorial, I want to help developers who are new to Sitecore to get a good understanding of some of the foundational concepts of the Sitecore platform. These concepts are the building blocks that make up every Sitecore website.
If you are familiar with CMS development, then you will probably be familiar with a few common buzzwords, like templates and data items. Sitecore uses some definitions you may recognise but relate to something different than you would expect, compared to the usual industry standard definitions, which can make learning Sitecore confusing at times.
The aim of today’s guide is to hopefully give you a clear understanding of these components.
The Building Blocks
A page in Sitecore is built using Layouts, Renderings, and Data Templates.
In web development, a template usually refers to some form of presentation file, a view, partial view, page, or user control. In Sitecore, they have switched this terminology around and a template refers to a structure that defines the data definitions for a piece of content. To recap… in Sitecore, a template has nothing to do with the presentation! The values defined in a data template might be displayed within the presentation components but a Sitecore template has nothing to do with how a page might look. The template is probably the most confusing item in the list, I agree this change in definition can cause confusion in meetings and discussions around development with non-Sitecore techie people, but, it is what it is.
Templates can be viewed/created within the ‘Templates’ node in the tree view. Just as a class has properties that define its properties, every piece of content in Sitecore will have a data template to define the properties it contains.
For example, if you want to add a Call To Action Block to a page, the first step to the process is to create a new Call To Action data template for it. In the last Call To Action block I created, I had properties like Title, Button Text, Button Url, Text, Image Url and Image Alt Text.
Another important aspect Template to note about templates is that they DO NOT store any data themselves. In this sense, templates can be compared to a class in C#. A C# class can contain and instant fields that define the object, but, it’s only when you instantiate a class that data gets added into the mix. A template, like a class, is just a way to create a definition.
I’m hoping everyone reading this understands the concept of content. This is where a content editor uses the properties defined in a template to create pages/content within Sitecore. When you create a new item of content, the first thing you must do is select which data template to use. Each data template will contain specific properties for different needs, for example, a Contact Us Template might have properties like PhoneNumber. A Content Page might have a Main Content Property.
Ok, so if templates do not have anything to do with presentation, content also doesn’t, what does?
What is a Layout?
Layouts are the first part in defining how the content will look on the website. A Layout can be thought of as comparable to master pages/MVC layouts and provide the main structure of the entire page.
When we build CMS solutions, we like to try and create re-usable components. Our website would be pretty crap if we had to create the header from scratch on each layout. For example, in a normal project you may have 10 different layouts, Home, Listing, Blank, Sitemap, Landing Page etc.. having to have the same markup and code duplicated on each layout wouldn’t work. Instead, Sitecore lets us further split up the presentation of the page by using placeholders and components.
What is a Component / Rendering / SubLayout?
In Sitecore, components are as they sound, small bits of reusable functionality that can be added into a layout to make it more interesting. For example, the header would very likely be a component, as would the footer.
Defining a component is a developer level task that involves coding, and consequently, it’s where a lot of the project’s time will be spent. There are two main components in Sitecore, renderings and subLayouts. If your project is built on MVC, then you will be using renderings. If you use web forms (Yuk) then you will be using Sub-Layouts.
With MVC, we have access to ‘View Renderings’, which are just simple MVC views (like a partial) with no logic to them and ‘Controller Renderings’, which are views that have also have a controller.
If you are using WebForm, the components you will be working with are Renderings for XSLT and Sublayouts (Web Controls/.ascx).
Now, the last bit of the puzzle is how can content editors add components onto a layout? In Sitecore, components are added onto a page using placeholders. Placeholders can be thought of as areas on a page that components can be dragged onto. They are very simple, contain no logic and as the name implies, they are just placeholders for components.
In Sitecore, you can define as many placeholders are you want. Placeholders can be configured to only allow certain components onto a page. This is useful to help enforce standard information architecture. For example, if you have a contact us map, you may only want that to be placed on the contact us page, instead of allowing it on the homepage. So instead of creating one global placeholder, you would create a contact us placeholder that only had the Contact-Us Map Component added to it.
As developers, we define the layouts that contain placeholder, we then create the components content editors can add to a page and then sit back and let them get on with it. This approach is so much simpler than the olden days when any changes to the layout required development work.
In today’s guide, we’ve covered a lot of the basic building blocks of Sitecore. To build a web page you need to define what information you want on a page using data templates. Content editors use these templates as the basis to add content into Sitecore. Content editors can then associate a layout with a piece of content to define how it will look. In the layout, components can be added to allow content editors to define how the page will look. This is a big improvement of the very static un-flexible page templates of the past.