Archive for August, 2008

Content Management Systems – a bad idea?

August 11, 2008

CMS – Content Management Systems are meant to…manage content. So if we need a generally static content, which should be editable by non-technical persons, it is probably a good idea to use them. Probably.

I’ve had some experience with a number of CMS (Joomla, DotNetNuke for example), and read/tried some more. What do all of them claim to offer – faster development, easier reusing of repeated tasks (registration, news feeds, etc). But let’s review some of the claims, and compare the use of CMS to making a site from scratch:

  • editing by non-technical persons made easy: Without a step-by-step guide a non-technical person would never make it through the complicated menus, buttons. And what most CMSs offer is some ugly javascript editor-enabled textarea, which generates bulky and incorrect (X)HTML. On the other hand, with a similar step-by-step guide, a non-technical person can easily use Dreamweaver to make his pages and link them to menu items.
    • easily reusing repeated tasks: let’s call the pieces of reusable code “modules” (they are often called that way). They should integrate well with both the CMS, and with existing modules. In practicse this is never the case. If at all any integration between modules is to be achieved, a bunch of inconvenient configurations are to be done.  And when at some point you find out that the existing module is not actually working as you want, it becomes a fight with the constraints of the cms. On the other hand, if you have already developed a number of sites, and have developed them well enough, you can reuse your own code (or even someone else’s independent code) knowing perfectly well what the outcomes will be.
    • creating new functionality: as mentioned in the previous point, lot’s of constraint and cms-specific rules are to be observed. They cannot be forced programatically, so you will be lucky if you have a whole list of these constraints and dependencies. Otherwise you should guess each time something doesn’t work. And these constraints and dependencies are not few at all in big CMSs. On the other hand, writing a custom functionality as just plain code, with no configurations, implicit and explicit dependencies seems easier. Of course, it should integrate with the existing system, but this integration is done transparently.

    In all the above point “learning curve” should’ve been included. It takes too much time to master a concrete CMS. And why, when, if you structure you work well, you can achieve even better speed and quality?

    So let’s introduce the term “prepared scratch” – that is, all general stuff like db connections, main configurations, etc, is already prepared, and you start writing your custom dynamic/static pages from that point. Believe me it will turn out to be a lot easier, and will save neurons.