Sitecore Components — The Basics

Rainfall Software
Rainfall Software
Published in
3 min readOct 18, 2022

The of the most common tasks a Sitecore developer is asked to do is to create a re-usable component that content editors can place on a page. The process to do this varies a great deal depending on whether you’re using frameworks like SXA or JSS, but a lot of the fundamental steps are the same. In this article, I’m going to walk through the process of creating a basic using plain .NET MVC.

Photo by Xavi Cabrera on Unsplash

Template(s)

The first step in creating a component is to create the Sitecore template(s) that will store the components data source and/or rendering parameters.

Not all component require a data source or rendering parameters, but for our example, we’ll assume our component needs both. The next question is how to separate data between the two templates. There’s no hard-and-fast rule for which fields should go where, but as a general principal, anything that is going to be displayed to and read by a web site user should be in the data source, and anything that controls the appearance of that content should live in the rendering parameters.

A few things to consider when creating the template:

  • Are there any default values or configuration that needs to be set on the Standard Values item?
  • Has the template’s icon been set to something appropriate?
  • Where is this template going to be created? Does another template type need to have this component added to its Insert Options?

Rendering

Once the template(s) are created, we’ll need a rendering for the new component to add to a page. There are a number of possible types of types of rendering, but by far the common one I use is the Controller rendering. I’ll do another blog post where I go into more detail on why I prefer Controller renderings over View renderings, but for now let’s assume we’re using a Controller rendering.

When creating the rendering, it’s important to set the data source and/or rendering parameter templates. This restricts the content editor to only allow these templates to be assigned to the rendering.

Some things to think about when creating the rendering:

  • Has the rendering’s icon been set to something appropriate?
  • Has the data source location been set to a location where these items will be stored?

Controller

Controllers can obviously range from extremely simple to very complex depending on the component in question. For the component in this example, we’re assuming the simplest possible code required to get things working. Many Sitecore application use the Glass framework to map between Sitecore items and strongly-typed objects, but in this component we’ll use only native Sitecore libraries.

A simple component controller looks something like this:

public class MyComponentController : Controller
{
public ActionResult MyComponent()
{
var dataSourceId =
RenderingContext.CurrentOrNull.Rendering.DataSource;
var dataSource =
Sitecore.Context.Database.GetItem(dataSourceId);
var model = new MyComponentModel(dataSource);
return View(model);
}
}

View

Finally, we create the View for our component. This is where we will define the HTML for the component. In our controller, we passed a MyComponentModel object to the view, so that is what will be used in the file’s model declaration.

A few things we should think about when creating the view:

  • Does the code fail gracefully if the Model is null?
  • If any of the Model’s fields are null, will the code handle this?
  • If the application is making use of the Experience Editor, are all appropriate fields editable?

--

--