Feb 2019 Update - I have moved the Handlebar Code into it’s own project and its available as a stand alone module without needing to worry about Sitecore Foundation. You can find the code and installable Sitecore Packages on github here.

Although I'm a proponent of component based frameworks which make it easy to enable content authors to assemble pages using a library of components, I do find the biggest drawback of such frameworks is the push away from semantic content templates. In a template based architecture, you typically would create custom templates to represent the actual type of content you were presenting. When you use generic components, you are creating instances of generic content templates: An image, a Link, etc have no meaning outside the content that's populated within them.

Sure I can still create semantic templates and build custom components to surface details about products, articles, or whatever other semantic content I want to store, but that's a pain in the butt, and difficult to make reusable in a multi site instance where each brand wants to define things a bit differently.

In most scenarios you'll end up with a set of very specific components that are not reusable outside the site they are built for or you end up having all content assembled with generic components and no real meaning or ability to manage the content as it's all over the place.

I Mustache you a question

Fortunately, I have implemented a pretty neat solution to this problem: Handlebar Renderings. They are actually a set of components that can be added to a component based architecture that can bind to any type of content and surface it in an experience editor friendly way, making fields editable using a handlebar syntax. But although they are components they are essentially another type of rendering. A rendering that you can allow your more advanced content authors to use to take control over how semantic content is presented without needing developers to build new components. I completely get that not ever content author should be empowered with that ability, but your dev teams can use this as an alternative to custom component development in most cases as well.

The approach leverages nested components that can be assembled together to surface content from any type of Sitecore template. 

The container can be configured to determine what item or items should be presented to a visitor. I have implemented three types of containers:

• Item Container - Binds to a single Item in Sitecore.

• Collection Container - Binds to all items in a folder, or can allow content authors to define a custom list.

• Query Container - Specify query parameters and it will use Sitecore's Content Search API to populate a collection

The collection container and query container support automatic paging as well. You can specify items per page and what querystring parameter to use to define the current page in the rendering parameters of the container component.

Within the container exists a placeholder which you can add a "Handlebar Template" component to. This component will bind to the containers item or item collection and allow content authors to define a "Handlebar Template" that will surface the content in any format they desire. But that format isn't the default page editing view of the component. Instead, the template is able to make all the fields surfaced fully "Editable" so that content authors can use the "Handlebar template" to actually manage the content in the items bound in the container. To edit the template itself, I've added a custom experience button to the component that allows the template itself to be edited in a popup.

Here's an example of this feature in action: (click to view larger and hover for descriptions)

The logic to bind the templates is all implemented server side using Handlebars.Net. While the compiled template is cached in the HttpRuntime for performance reasons, I still recommend properly setting the components Cache Settings.

While implemented as Components, when taken as a whole, they are essentially a new type of rendering. The only rendering that can be completely managed in Sitecore without requiring a deployment. In addition there are a number of other advantages of this approach:

• Template Library - You can build up template libraries for common components. Imagine a collection of templates for displaying blog posts, or product information and allowing content authors to choose how they want to present the content. It's Compatible Renderings on Steroids.

• Personalization and AB Testing Ready - Apply Personalization to container components to change what item is rendered very easily. Apply Personalization to the templates to change how they are presented.

• Template Composition - Instead of having one big template for everything, you can break your templates up and compose them within a container. This makes the individual templates more reusable and gives you the ability to reassemble in multiple ways.

• Experience Editor Only Components - I've created a custom button to add a new item to a list based on rendering parameters. This makes it easy to add a new item to collection and query containers.

I plan on doing deeper technical dives on exactly how these components are implemented and will try to package something up to share in the final post.