Dusty Eves

dusty.eves@techno-babble.net

Sitecore Architect with Paragon Consulting

Referenced-based Presentation Definition

Intro

If you’re like me it’s always bothered you that in a typical site the header of the site is 5 or 6 components that we essentially have copy-pasted on every page in the site.  We don’t want to sacrifice flexibility by not breaking it down, but it would be nice if we could scale horizontally better, and now we have that option: Sitecore Marketplace: Referenced Rendering Module

The Challenge

When designing the presentation architecture in any Sitecore site one is always balancing between the number of moving parts and maximum re-usability. Here we have an representation of a complex, but not atypical presentation architecture.

TypicalPresentation

While the placeholder architecture is likely to be more complicated than this example, this setup very effectively breaks the presentation pieces down into their requisite components. The downside to approaching the problem this way is that for almost all pages the header and footer components are going to be exactly the same. Managing the presentation in this fashion is effectively doing a copy-paste of the presentation for all the page in our content tree. Not breaking down presentation components creates different problems, but none the less this adds management overhead to all of our pages but only provides value to our edge cases. In an ideal world we’d have a way to preserve this separation of components while allowing the commonalities to scale.

Ideal Solution

Referenced-Presentation

Above is our ideal method for setting up presentation. In the above example the header and footer each contain a data source that point to items with their own presentation details. By itself that doesn’t do much but being built on pipelines Sitecore’s architecture is nothing if not extensible. By replacing the AddRendering Sitecore pipeline we can tell Sitecore for certain renderings that it needs to look deeper for the full picture.

How Referenced Renderings are Set Up

The module install a generic Referenced Rendering. Like any other rendering it has a placeholder, data source, caching and parameter’s settings. In addition a referenced rendering has an inner placeholder setting for more granular control of rendering order. Add an inner placeholder will create a placeholder of the name within the referenced rendering and any items down the rendering chain can consume said placeholders.

Using a referenced rendering requires first to setup a rendering source. Create a new instance of the ReferencedRenderingSource template and define your presentation on the new item. The Sitecore UI requires a layout be defined but for a referenced rendering is ignored. In setting up the renderings and placeholders they follow the same rules as when editing the presentation on the rendered item itself. They will render in-line in the order they’re presented in the presentation. As previously mentioned if defined our referenced rendering will create an inner placeholder for us but the rendering need not be assigned to them, and can be mixed and matched. For example if we set presentation up as so:

Header-Multi-Placeholder

Sitecore will render as so:

<!-- <InnerPlaceholder id='inner-header'> -->
<!-- Primary Nav -->
<!-- Secondary Nav -->
<!-- </InnerPlaceholder> -->
<!-- Search Box --> 
<!-- Breadcrumb -->

Targeted Referenced Renderings

While descriptive from a technical perspective, “Referenced Rendering” doesn’t do much to tell the content author what it does or what it is. Setting up a rendering for a specific purpose is relatively straight forward. Start by creating a copy of the Reference Rendering webcontrol rendering item and giving it a contextually appropriate name. As with any other rendering you can assign values for the data source, placeholder, and other rendering parameters and it will function just like any other rendering with the values on the rendering itself used in the absence of any defined in the presentation details.

Conclusion

So the long and short, with referenced renderings we gain the power to break down components as our architecture dictates without creating additional maintenance overhead of seeing that breakdown manifest every minute detail in the Presentation Details.

If you’re interested in how the Gnomes behind the scenes accomplish this, you can read more on how it works here: Referenced Renderings — How They Work

Like what you see? Something I missed? Have an even cooler way to do the same thing?!?! Let me know in the comments below.

Leave a Reply

Your email address will not be published. Required fields are marked *