WMS: Rethinking our need for CMS

.NET, English posts, RavenDB, Software Design

Comments

5 min read
Traditionally, Content Management Systems are about Content. Whenever Data that is  not simply a content page was going to be persisted in a CMS, you'd somehow fit it in a Content entity, keeping the thought process always at "how would it look to the end user", never treating it as actual data. Sure, there is the page-centric CMSes like DNN, and CMSes which try being data-centric. But when talking CMSes, you can either be too focused at solving your problem, in which case unless it is actual Content Pages that you are working with you will probably move away from CMSes anyway, or abstract too much to be a one-size-fits-all, which will always end up badly. There doesn't seem to be any middle ground.

This seems to be a problem with the roots of CMSes, the way they evolved, and with strong ties of it being always backed by a relational database. CMSes were always about "Content", not about "Data", and the relational model doesn't make your life any easier when you have actual data you want to work with (not just "display").

WMS: Redefining CMS

In today's reality, we might choose to continue bending terms and force all those types of systems under the definition of a CMS, sure, but this will most probably end-up in a multi-purpose data-to-ContentPage converter built on your MVC framework of choice, achieving nothing, really. Been there, done that.

Instead, I like to think of a WMS - Website Management System. I want this thing to help me deploy any website quickly and efficiently, allow me to manage my content AND DATA by providing admin screens, play nicely with my IDE, support multi-site nicely, and as a general rule won't stand in my way. This is mainly because I don't like building websites, I like building software that might be served to the world as websites. I don't like being a server administrator, either.

A perfect WMS would have a gallery of modules I could easily integrate, so I could deploy a website, any website, with no hassle, getting full-blown admin screens for each module that are actually fit for managing the data used by the modules. No stretching or rounding corners. And whenever I'd want to add a new custom functionality to my website, I could just fire up my IDE, implement some interfaces, test, play with the new website locally, deploy, set 2-3 settings, and be done with it. An important thing to note about a WMS is that it does NOT manage data for you, and also the concept of Content is gone forever. A ContentPages module might exist, but it is going to treat all content-pages as data, the module's data. A WMS is not about persistence, and the only data access it does is for persisting configurations. It might manage data-access for the modules, but only to an extent of being a middleman for serving data requests, requests being created by the module itself. This is a design decision we have to make to make sure we do not pose limits to what we can do with modules; data has to be persisted independently of the WMS, but optionally orchestrated by it.

Spec'ing WMS

So how would one go about implementing such a thing? First, dropping SQL and using a schema-less database, with document database being probably the best fit here. Getting rid of a schema is the first real step for creating a real-world dynamic applications with good performance. Then, moving from thinking in "Pages" and starting to think in terms of "Routes". Back in the days when we were displaying only content pages, it made sense to have a URL to a Page. With schema-less model, we have to make our website URLs "schema-less" as well - and this is where routing comes in. Each module will define it's own set of URL templates, and while configuring your website you will tell the WMS which Area, or URL prefix, this module is going to use. Simple modules like a ContentPages one will probably have one rule, and more complex ones like a products catalog or an eCommerce module will have all the flexibility they need. And this brings me to the MVC pattern, which we probably are going to want to use. To use the MVC pattern correctly, each module will contain the Controllers, Models and Views it is going to use. A Controller must provide all the content for the View to consume, hence making all the data-access operations in the Controllers alone.

This is some high-level description of what I consider to be a fairly robust and flexible WMS, what in my opinion should replace what we know today as a CMS. I'll be writing a follow-up post with some discussion on other aspects which I consider important, namely Menus, Navigation and Hierarchies. But these are at some level just implementation details, which once you get the framework right, will need to fit in nicely.

Comments

  • Phil Jones

    A WMS sounds like a great idea.

    I've used Umbraco and felt dirty with its XSLT structure but trying something like BrickPile, I was too confused by all the abstractions. I'd like a nice easy to understand structure too.

    One major problem I have with CMS's is getting the custom stuff into source control. A WMS should also help solve this problem.

    Phil Jones
  • Marcus Lindblom

    @Phil, I'm not sure I understand but did you get confused when trying out BrickPile?

    Marcus Lindblom
  • Sebastien Ros - MS

    In Orchard, the content called a Page is defined as "something" which has a Route, a Title and a Body. Similar idea.

    Sebastien Ros - MS
  • yakoub abaya

    what you describe about wms looks like django for me, except that django does us relational database

    yakoub abaya

Comments are now closed