Ever since the announcement of the merger between EPiServer and Ektron, people have been curious about how the combined platform will utilize the capabilities of each CMS. At Diagram, we’ve been especially interested in the back end capabilities of both platforms, so we’ve been delving into some of the capabilities that developers can utilize, like EPiServer’s Dynamic Data Store or initialization.
As we continue to discuss the ways developers can utilize the capabilities of these CMS platforms, we wanted to look at content rendering. This first blog on the subject will discuss how EPiServer and Ektron handle content rendering, and we’ll be following up with another blog that offers more information on how to use content rendering.
Content Rendering
Separating content from the way it is displayed is a must have feature of any modern CMS. Content is meant to be re-usable, and it shouldn’t be tied to any particular template. EPiServer handles the task of displaying content in a very robust manner, using a template repository that populates available templates by using the custom attribute TemplateDescriptor, or by registering templates when implementing the IViewTemplateModelRegistrator interface for MVC sites. For a great technical explanation of how templates are selected for pages and blocks, we recommend reading this article written by Valdis Iljuconoks, but for our purposes, we will focus on why this is an excellent approach for displaying content.
The EPiServer Approach
EPiServer’s rendering engine provides a great deal of power to developers through the ability to display different content views by simply using tags, rather than having to do any coding logic to determine when different views should be used. A tag in an EPiServer template is nothing more than a string or label to assign to a view.
Tags will vary from project to project, but some common ones we use are ListView, RelatedView, and SecondaryView. These labels can then be passed to the HTML helpers PropertyFor and DisplayFor for MVC, or they can be set on the EPiServer:Property server control for Web Forms. When these tags are set, content items that have templates associated with these tags receive preference over ones that do not, which moves the need for logic on which view gets rendered to the underlying code, making life simpler for developers.
Furthermore, templates can be shared across page types using base classes to create content types. For example, an ArticleBase class with a date, description, and image field can be shared for two page types: BlogPost and NewsRelease. Since these types inherit from the same base class, they can share a listing view template made for the ArticleBase class utilizing those components, instead of needing two different list view templates for blog posts and new releases. Also, the TemplateResolver class responsible for selecting templates can be extended to override the selected template by hooking into either the OnTemplateResolved or OnTemplateResolving events in the rendering engine. For a more in depth look at the template rendering process, a great overview can be found on EPiServer World.
Ektron's Methods
For older Ektron setups, these types of choices tend to be more manual. Smart forms allow for a default XSLT file to be assigned in the work area. This choice then gets used when displaying content via a content block server control, which is a great way to have a single detail template to support different smart form types. However, if an article page was to be used as a callout, then another content block, content list, or list summary control would need to be included in the page template, and a different XSLT would need to be applied. Also, if multiple smart form types are included, additional logic would be needed to call the correct templates for content items in the XML data.
For newer Ektron setups using content type classes for smart forms, this can get more complex. If a single page template is desired, then code will be needed to determine which display to use for the current content. Ideally, the display will exist in a user control or widget (if PageBuilder is utilized) using the strongly typed ASP.NET content type class in an ASP.NET ListView or Repeater control. Additional views and listings will also use those controls and follow the same concept, wrapping those items in user controls or widgets which are then added to templates.
These types of listings do have a limitation, as they are really only meant to display content items from one type of smart form. Displaying a list of blog posts and/or news articles, as in the example discussed in the EPiServer section above, can get a bit tricky when determining how to retrieve the data of each smart form type for a shared display.
Introducing Content Maker
Wouldn’t a rendering engine capable of displaying content in a variety of ways be a nice addition to the Ektron product? EPiServer is extending the Ektron product with new features like EPiServer Find and EPiServer Commerce, and in that spirit of extending Ektron, we at Diagram are happy to announce we are releasing our Content Maker code. The code solves many shortcomings of utilizing content type classes and makes for simpler templates from the older XSLT days.
Stay tuned for the second part of this blog, when we will provide more information on how to use this functionality. If you want to get started now, check out the project's readme, and please share any questions in the comments below, or contact me via Twitter. If you have any other questions, please contact us. We look forward to seeing how people utilize this new functionality!
