Confusion Management Systems
I am a criminal. I have commited the cardinal sin of reinventing the wheel. Of course, reinventing the wheel is what programmers enjoy the most so we all do it constantly, but this is serious. I’ve written a mid-sized complex web application framework. Already I’m in competition with hundreds of other products. I haven’t defined my goals very well, which is practically unforgiveable in such a saturated marketplace!
Anyway, this week I went to visit Blueorange. They are a web software company who have done some excellent things with Zope, Zope is to the open source CMS’s what Microsoft is to software companies. I spent a bit of time reading about Zope again today. I am not unfamiliar with it and I know that it gets a lot of things right. It’s philosophy seems to be to enable non-technical users to build powerful dynamic websites. It is big and complex, but overall this it does hit its targets, especially when you throw Plone into the mix. Plone is to Zope what Firefox is to Mozilla, maybe, the final realisation of a long-held dream. What is it with me and comparisons today?
Anyway. Zope is an extremely powerful content management system. It’s damn ugly though and from what I’ve heard from my main Zope developer friend, it’s a bitch to skin. This is basically where I’ve tried to make InfoCMS useful. It’s really harder to create and manage content, but quick and hassle-free for developers to skin. I like the XSLT approach. Yes XSLT is not very pretty, but it is centralised. You can take an InfoCMS site and quickly build layers of XSLT and CSS on top of the default skin to create highly customised themes. And it’s easy to do this, rather than chasing down the correct skin object for the content you want to change and fighting the hierarchy, you’re just creating toplevel rules and there’s nothing you can’t change with the right XPath expression.
The objects provided in InfoCMS don’t offer any like the power that Zope’s products do really. There are no blogs, wikis, calendars, ecom engines and so on. This isn’t too surprising as Zope is ages old and has millions of developers and InfoCMS isn’t even stable and has one. So I find myself wishing that I could marry Zope’s huge quantity of available features and products and it’s content management power with InfoCMS’s skinnability and manageability from a designer or design implementation point of view. I’ve tried to do some reading on XSLT and/or skinning within Zope and Plone, but it doesn’t look like it’s possible to strap XSLT on to the front of an entire site like it is with InfoCMS.
I’m fed up with speccing and coding complex functionality though. This is why I wrote InfoCMS, because I wanted a reusable code library that could be turned to just about anything. However, I have by no means built up the head of objects that I was hoping for and site-building still involves way too much coding and not enough pointing or clicking. The Zope developer has all the ammo, they can pull products from hundreds of sources to plug functionality gaps and the ZMI provides a consistent way to pull these elements together without code. Or least it looks that way to an outsider :-). You then have to create DTML or TAL and stuff, which is where it gets hairy. With Plone they seem to almost have accidentally addressed this by creating a default skin that everybody just keeps! Not really ideal.
XSLT and CSS provide powerful grammars for expressing design as rules and that gives the designer much needed power to control sites of thousands of pages without spending an entire lifetime doing robotic updates. It means design updates can be performed very very quickly. I’ve yet to find a CMS that capitalises on this flexibility. I’ve tried to write one, but at the moment I’m having a crisis of direction :-). Plus I want to write more Python, not PHP.