CMS’s Should Manage Content, Not Display It

By Deane Barker on February 18, 2004

I don’t like content management systems that try to handle the displaying of content. I alluded to this last year, when I wrote:

There are two sides to publishing Web content: First you create the content, store it, edit it, send it through workflow, get it approved, then stage it somewhere until it’s published. Second, you display the content on a Web page. The first is infinitely more complex than the second.

This still holds true. Managing the content is the tricky part, publishing it is easy. Any Web developer worth his or her paycheck can spin a recordset and write out some HTML.

Content management systems that have a display component end up trying to replicate one of the dozens of Web programming languages out there, and they do an inferior job of it. ASP, ColdFusion, PHP — these languages have a big programmer base. I don’t care how much thought you put into it, your proprietary CMS templating language is going to come up short.

I’m working with an open-source content management system now that’s first-rate. However, a big part of it is the display component. It has its own templating langauge, its own URL format, its own object theory, etc.

There are some problems with this. (1) It’s very, very slow; (2) the language is inferior compared to even the most basic Web programming language; (3) I like my URLs a specific way and I need to maintain URL consistency; and finally (4) I don’t want to learn yet another language.

My solution was to write a function library to make raw database calls to get everything out in a nice, big, nested PHP array. I essentially built an API for the CMS to make pulling content easy, but I do all the HTML processing in PHP, abandoning completely the display side of this CMS. I still use it for administration, workflow, etc. (which it excels at), but when PHP is such a fantastic, mature language, why reinvent the wheel?

Some people may claim that templating languages are made for non-programmers to use, but they often end up being just as complex as a real programming language. As the language develops, you find that you need to add this function and that control struture until, in the end, you’ve essentially re-written an existing language.

And if you just give the developers a decent API for getting the data out, most of the heavy-lifting is done. Code to format text, numbers, dates, do some simple if / thens, etc. — this isn’t hard and can be abstracted to easily-digestible function calls.

(Also, the sad fact is that sometimes the displaying of content is, in fact, complicated. Especially when you get into things like personalization. We may just have to live with the fact that the logic to display some content is beyond the scope of a non-programmer.)

CMS vendors: handle all the adminstration of the content, then just publish it to a database and give us a solid API for getting the content into a data construct in the language of our choice. We’ll handle it from there.

Gadgetopia
What Links Here

Comments

  1. You should check out pMachine and Expression Engine, both by the same company.

    http://www.pmachine.com

    i’m running pmachine on my blog and getting ready to launch a site using the Expression Engine. Very slick stuff. i think the EE will best for you :)

  2. Would you mind telling us which open source CMS you are using that you like for administration and workflow ?

  3. Thanks for pointing to ezPublish, I didn’t know about that CMS/CMF. We are in the process of selecting a java-based open source CMS/CMF and I wanted to ask for you opinion of what works best for administration and workflow. We plan to create our own document types and corresponding editors, but we would love to just use the workflow/administration/publishing capabilities of the selected CMS/CMF…. Thanks in advance…

  4. I think you are partially wrong. Obviously, you are right that rendering content is much easier than the whole management of content including publishing cycles at a first glance. But the more educated the observer becomes, he will understand that content is not one-dimensional. There are many types of content you want to manage and apply release cycle, etc. on them. This includes content as ment by business data. Content in form of Articles, news, documents and last but not least a fully fledged content management solution needs to be able to manage publishing display code in the same way.

    Thus an integrated solution, that manages all content dimensions willl always be better than a CMS system that only includes part of it (e.g. only managing the content you refer to). Of course, covering part of the whole domain in a good way is better then mixing things up!

  5. Some people may claim that templating languages are made for non-programmers to use, but they often end up being just as complex as a real programming language. As the language develops, you find that you need to add this function and that control struture until, in the end, you’ve essentially re-written an existing language.

    Yes, so PHP could be used as a template engine [it was originated for that purpose]. But on the other hand, PHP templates are kinda “risky” from the point that users can put “ivul code” into it ;P Is there any way to make “safe” PHP templates?

  6. I agree with you. I think with a good software design where you can keep the presentation separate from the back-end code you can achieve what the templating languages aim to achieve… As you said there are some times that the presentation itself is complex and you end up writing a templating language which is as complex as other programming languages with the additional pain of not being as powerful.

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.