Blog - Glass and SXA - Part 1

Glass and SXA - Part 1

I have had many questions about using Glass with Sitecore SXA. In this two part blog post I will explore the limitations and possibility of integrating Glass with Sitecore SXA.

Before we start we need to understand how SXA renders content to the screen. I should say at this point I am not an SXA expert and my understanding is based on the documentation and reviewing decompiled code.

SXA Renderings

SXA components can use two different rendering mechanism.

• SXA Component
• Rendering Variants

SXA Component

Sitecore’s official documentation can be found here:
https://doc.sitecore.com/developers/sxa/17/sitecore-experience-accelerator/en/walkthrough--building-a-simple-rendering.html

The first rendering mechanism uses a model, controller and CSHTML file. This rendering mechanism is very similar to a standard Sitecore controller rendering.

To create an SXA Component rendering you need the following:

• A model that inherits from RenderingModelBase
• A repo to populate the model that inherits from ModelRepository
• A controller
• A CSHTML view

The model you create needs to inherit from RenderingModelBase because this base model contains properties that are required by SXA to function correctly. Your model can include additional properties that you want to pass to view. These might be field properties or other properties that contain business logic.

The repo class is responsible for populating the rendering model. In this class you must call the method FillBaseProperties so that the properties from RenderingModelBase are correctly populated.

The documentation recommends that individual properties are mapped by creating individual mapping properties:

        model.Title = GetTitle();

        private string GetTitle()
        {
            return PageContext.Current[Templates._Title.Fields.Title];
        }

First thing to note about this approach is that the the “Current” item is a Sitecore item. This means that you are reading the raw string value held in the Sitecore field. For complex fields (i.e. anything that isn’t a single line text field) you will need to add logic to this method map it to a .NET type. Additionally making this field editable in the Experience Editor will be more complex and may result in having to pass the entire item to the view (later we will see how Glass can save some time).

If you look at the Sitecore documentation we can see that the controller is a very thin layer. It simply calls the repository and passes back the SXA model.

Finally the CSHTML view renders the properties from your model using the standard MVC syntax:

    @amp;Model.Title

At this point if you wanted to make fields on your model editable you would need to use the standard Sitecore HtmlHelper extensions methods and pass an Sitecore.Data.Item as part of your model.

Rendering Variants

Rendering Variants are the second way that SXA renders content to screen but they can't render content on their own. You first need to create an SXA component and add this piece of magic:

       @amp; foreach (BaseVariantField variantField in Model.VariantFields)
        {
           @amp;Html.RenderingVariants().RenderVariant(variantField, Model.Item, Model.RenderingWebEditingParams)
        }

Note that Rendering Variant models use a different base model type.

This piece of magic renders the variants we have defined in the Sitecore database. This definition allows you to build complex HTML structures that are defined by Sitecore items.

Each component can have multiple different HTML structures which a content editor can choose between, think of it like compatible renderings for standard Sitecore components. For example you are rendering a blog post with just the author’s name and headshot. You get a request to change the rendering so that it also has the published date. This is easy, just add a rendering variant that also includes the date in the Sitecore database.

The configuration for the rendering variants is stored in the Sitecore database which means that you don’t need to deploy any code to move variants between environments. Simply package and move the new items to another environment.

I won’t dive too deep into the structure of rendering variants because there are better blog posts to read on this top. It is also the part which is completely out of scope of Glass. Glass isn't designed to do what rendering variants do.

Before we move on

The methods of rendering SXA components is relatively straight forward.

Before moving on to how Glass can work with SXA there are a few questions you need to ask yourself about how you are designing your components:

• Any properties you add to your component model are (for want of a better word) static properties. These can’t be changed via rendering variants and require a code deployment to be changed. Do you want these properties static?
• Why is the property on the model and not part of the variant?
• Can the properties defined on the model actually be defined as part of the rendering variant instead?
• Which parts of the component do you want to be configurable?

Glass and SXA - Part 2

- Mike