Designing Data Templates for Content Extraction with Ektron (JSon, XML) (Ektron Designing Content Delivery: Part 2)

In my first post Designing an Ektron Content Delivery and Provider Mechanism (Part 1) I outlined the basic steps for designing Ektron for management of the content, with the idea of pushing (or pulling) content from this system to be consumed by a host of other sites (and potentially applications).

This post will focus on designing template for the extraction of information from Ektron so that it may be pushed or pulled for consumption by other systems.

This started with basic research around how to retrieve information from Ektron.

• 1. API - The application itself supports a fairly extensive API which could certainly be used to interact with information. You can certainly get at your content and manipulate it. However investigation here was pretty easy. The API itself is around retrieval and content management and not around manipulation. The proof of concept certainly worked, but was a lot of work and manual code.
• 2. Database - Ektron maintains a SQL database, and you can see your content. You could write your own access logic, and get the information you need. However, aside from violating the best practices for Ektron (and making your new infrastructure completely Ektron version dependent), this is a tremendous amount of manual work for little or no benefit. This is possible, but so far beyond practical or reliable.
• 3. Templates [Selected Solution] - Out of the box Ektron supports templates. For the most part these templates are designed to render content out to the end-user... but... the design is also flexible. At the end of the day this is what Ektron is designed to do, just with a slightly different end-result or consumption. The proof of concept worked, and was easily integrated into the Ektron web-site. In other words: simplicity.
• 4. Ektron Web-services - Ektron supports a host of web-services for interacting with the application. Designed in a very similar fashion to their API, it works, and is practical. Built on SOAP this is a very viable option. In similar to the API it's design around retrieval and content management and not around manipulation. The proof of concept certainly worked, but was a work to create the transitions from the content type to the rendered types.

In the end the solution that worked best was to design a series of templates. Why? It was easy to do, worked well with Ektron's design and provided a tremendous amount of flexibility. This created some quick benefits to the project:

• Content could be managed via a url so access via the wrapper API could be directly tied back to the content it represented. In the end, we selected manual alias names for content (as an example: [Group]/[Section]/[Content]/).
• The type of content to be generated when pulled could be set/managed inside of Ektron, simple by selecting a template (JSon/Xml/Html, etc.) reducing the amount of IT management and overhead.
• The templates at the end of the day are relatively simple ASPX pages, which require a small amount of development and can be managed as part of the Ektron website for lifecycle and delivery.
• The paring with Ektron SmartForms makes an extremely flexible offering with control over structure, content, security and delivery.

In the end, I decided on a basic delivery set of Html, Text, Xml, JSon. In order to make the most compelling offering, these were arranged into a simple folder structure:

• Content
  
  • SmartForm Translation with MetaData
  • AsJson
  • AsXml
• Taxonomy
  
  • SmartForm Translation with MetaData (planned)
  • AsJson
  • AsXml (planned)
  Note: I could do a whole post on what I am doing with Taxonomy separate from rendering content. If anyone is interested let me know.
  
• AsJson
• AsXml
• AsRaw
• AsRawCollection

The content templates are exactly what you think: rendering out the actual content. The other base templates render out the entire Ektron content items. However, I built those because it was easy to do, the vast majority of the items built on top of this are around the content and taxonomy templates.

Here's an example of the JSon template for content:
ASPX:

       
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="AsJSon.aspx.cs" Inherits="Shared_Template_Content_AsJSon" %>
<%@ Register Assembly="Ektron.Cms.Controls" Namespace="Ektron.Cms.Controls" TagPrefix="CMS" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <CMS:ContentBlock ID="ContentBlock1" runat="server" />
    </div>
    </form>
</body>
</html>
       
 

Code-Behind:

       
public partial class Template_Content_AsJSon : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        this.ContentBlock1.SetDynamicParameterToIdAndFill();

        var document = new XmlDocument();
        document.LoadXml(this.ContentBlock1.EkItem.Html);

        Response.Clear();
        
        Response.ContentType = Web.ContentTypeDefinition.JSon;
        Response.Write(JsonConvert.SerializeXmlNode(document).Replace("@", string.Empty).Replace("#text", "text")); 

        Response.End();
    }
}
       
 

As you can see basic and effective. Content is available to be pulled (or pushed) via a url. Content (as data, html or any other delivery) is easily track able back as a url, rather than by an id or some other abstract storage identifier. Ektron manages the content, security, data storage definitions, and management of the content/delivery mechanism.

In my next posts:
1. Designing a Generic Meta-Data Driven Transformation Template with Ektron
2. Designing a wrapper-API for consumption, caching and rendering of Ektron data
3. Now look what we can do: Render Ektron client-side with data templates and JsRender (for smoking fast response times).

Resources:
Ektron API
Ektron Best Practices
Design without Borders, yet with Structure
JsRender