Sitecore as a Content Delivery Platform
Sitecore does a really good job of separating content from presentation. And a side effect of this is that we can reuse either part in other ways. We can reuse the content section of Sitecore to author and deliver content to different applications and we can reuse the presentation to generate markup for data which lives outside of Sitecore. This post is going to focus on the content side of things.
Sitecore has some great content creation and approval tools. We can define custom entities through data templates. Given enough training, even a technically minded business analyst could create these entities using the template manager. These entities, once created can be placed in workflow, all of which is security enabled, so the proper authorities must approve the content before it is eligible to be published and used by applications and websites. We can also impose restrictions on the data so it will expire at a given date and time.
I’ve heard previously of developers using Sharepoint as the “backend” to their custom written application. And I suppose if you look at it, it makes sense (for a line of business app anyway). Using this kind of platform as the backend means I don’t have to worry about creating a separate administration application to manage the data which the front end application uses. No more CRUD screens to implement. And the security model is already present as well. We can do the exact same thing using Sitecore.
Sitecore allows us complete control over the markup we generate. The markup doesn’t even have to be HTML. It could be XML or CSS or XAML or RSS or anything we like. So after the content has been created in Sitecore, we can have the presentation generate some kind of usable information exchange format. Or, we could expose the content through web services to our application and bypass the presentation components of Sitecore. The content still has to go through the proper reviews such as workflow and publishing, and then our front end application can access the data.
So in our content tree we can create a folder under /sitecore/content/ which holds our applications data. Let’s say it’s tax table data. I can have a “tax entry” template and when the data folder’s URL is hit the presentation I’ve attached to that item will generate the appropriate XML for the client application, which could be written in anything at all.
The most common application I’ve seen this kind of architecture with is Adobe Flash or Microsoft Silverlight. These applications usually make up a part of a web page (if not the entire web page) of a website and they either pull or are fed the data they require from Sitecore. But there is no reason why we couldn’t employ the same techniques to our internal line of business applications as well.
I mentioned above that we can have the presentation generate XAML which could be used to drive our Silverlight applications. XAML is just text, so it’s easy to generate. Normally we don’t want our application UI generated based on content unless we have a very dynamic application. Given the appropriate templates and content structure, and provided the client application was implemented in the correct fashion, we could actually generate completely new “pages” or screens in the application. This item contains an item based on the reports template? OK then, we’ll generate a reports button in the XAML for that screen which opens the report screen with the data from the current item. And the XAML can do all of that for us.