Content Management & Application development

My current customer did a study of portal / content management systems (CMS) to replace their existing system. I read their reports and felt compelled to do a little googling and study myself. I haven't used a CMS before for any real application development, I have been to presentations about SiteCore and I have experimented with Umbraco and Sharepoint but that is about it. I think CMS systems can be a great tool for building portal / content sites with limited functionality but when the system your are meant to build is leaning more to an application with rich functionality my instinct is that most CMS systems add to much complexity and friction.

The reason for this is that the way you extend or add functionality to CMS / portal  systems is normally through portlets, webparts/UserControls, in short you add functionality to an already existing application. This ties the application you are building heavily to the CMS system and often force you to a certain way of development. It may require a lot of manual configuration and hacks to work around limitations in the CMS. I am afraid that such solutions will be hard to develop and maintain.

I feel that an alternative way to develop applications which require rich content management is to develop a standalone application that is only dependent on a content API, the CMS system is then only responsible for the editorial aspects of the content management. So I began to search for a CMS system that supported this and was quite surprised to find that in almost every CMS system it was very hard to separate and only use the content API in a standalone application.

I finally found N2 CMS, an open source CMS system developed by Cristian Libardo. N2 works like most CMS systems in that you develop your site in the N2 application which contains the functionality for content editing. But you can also easily define and consume content from a standalone application. The way you define your content is through regular .NET classes.

Example:

[Definition("Standard content page", "ContentPage")]
[WithEditableTitle("Title", 10, ContainerName = Tabs.Content)]
[WithEditableName("URL", 11, ContainerName = Tabs.Content)]
[AllowedChildren(typeof(InfoBox))]
public class HelpPage : AbstractContentPage
{
    [EditableFreeTextArea("BodyText", 13, ContainerName = Tabs.Content)]
    public virtual string BodyText
    {
        get { return (string)(GetDetail("BodyText") ?? string.Empty); }
        set { SetDetail("BodyText", value, string.Empty); }
    }

    [EditableTextBox("Meny name", 12, ContainerName = Tabs.Content)]
    public virtual string ShortName
    {
        get { return (string)(GetDetail("ShortName") ?? string.Empty); }
        set { SetDetail("ShortName", value, string.Empty); }
    }
   
    [EditableChildren("Right column", Zones.RightColumn, 110, ContainerName = Tabs.RightColumn)]
    public virtual IList<InfoBox> InfoBoxes
    {
        get { return GetChildren<InfoBox>(Zones.RightColumn); }
    }
}

As you can see you adorn your classes and properties with attributes to inform the content editor how this content item should be edited. You have a lot of control over how to structure you content. After placing the assembly containing your content model in the bin folder of the N2 web application they will be available in the editor interface:

From your application it is then very easy to consume the content:

public ContentItem GetByContentPath(string path)
{
    return Context.Current.UrlParser.Parse(path);
}

The content path is the logical naming of your content structure, for example "/service/help/faq". I just want to point out that I am not using N2 the standard way, if you are using WebForms and follow the example site you get a more integrated experience and I don't think you have to use content parser directly like above. I found N2's use of .NET classes to define content as a really cleaver way to force separation between content and presentation and to allow for rich reuse of content in different scenarios.

I hope that the approach outlined above will prove to be a more natural and frictionless way to develop rich applications that require content management. You get the rich editing of content that you seek and at the same time get complete freedom in how you develop your application, for example you can use new frameworks and tools that would have otherwise been impossible. Your can use MonoRail, ASP.NET MVC, WebForms or WPF and you do not tie your application to a specific product.

I am easily impressed by the huge feature list of big CMS systems, counting all the available portlets and modules of existing functionality, but I think it is important to ask yourself what you really need. Companies behind CMS products are very good at selling them, showcasing all the extra "free" functionality that come with it and never the added complexity that comes with trying to extend and develop complex functionality into an existing application.

I posted a topic on CMS and application development on the altdotnet mailing list which has some interesting replies, but it would be great to get some more comments from anyone with experience doing rich application development using a portal/CMS system.