My last post was about the trouble with MVC frameworks, in my view, which briefly is:

Multiple action handling
Component/Template processing (related to the above)
Front controller/Back controller, helpers and the associated bloat or complexity and code duplication.

I noted that CMS frameworks attempt to handle some of this, most especially the component/template paradigm — usually by using the response wrapper paradigm.

I have two main issues with CMS frameworks:

1. Working with them sucks and requires too much relearning and enforces a too rigid development process (see my post about leveraging existing knowledge and techniques.
2. They usually have a very poor implementation philosophy, and don’t allow much reusability.

While I love looking at new MVC frameworks and learning their philosophy and coding styles, even if I don’t particularly like the framework, I usually walk away learning something (maybe that has to do with their code-centricness), I dread and hate the idea of looking at CMS frameworks.

That’s because it usually involves learning a truly awful administration interface, yet another template language, and possibly even a one off scripting language, and puzzling my way through an obscure (and often undocumented) series of conventions including file naming, manifests, api, and hacks for module building and using.  And they don’t make it easy to learn, because hey- they’ve got this cool, counter-intuitive, complex admin tool (website) that is their pride and joy that you should use instead.  Which works fine, if all you want to do is click “approve” on articles, add a menu or a weather widget on the right (or left!) side of the page, and have comments like slashdot (and a custom logo!)

So almost all CMS based sites end up looking almost exactly the same (depending on the CMS) but hey, you’ve got a lot of widgets you can include.  If your content is your main attraction, that’s probably okay.  You can find a whiz at making templates for your CMS to customize it if you really want.

But I truly do hate all the CMS admin interfaces in the world.  You spend as much time learning them as you do learning to code for an MVC framework.  Someone  said Django has a nice admin interface, but I’m skeptical.  Yes I’m going to look at it (someday.)

So you’ve got a lot of widgets, and you can even learn how to write them yourself, but because most of them were developed without OOP in mind, they’ve got weird, arbitrary rules and conventions that you need to learn to code them and load them.  The registering and loading of CMS components reminds me of the work set up EJBs (but hey, you’ve got a nice admin interface!)   But outside of self-contained widgets, there isn’t much flexibility.  Getting components to talk to one another is usually not worth the effort.

The other problem is the horrible implementation ideas.  I’ve already mentioned the non -OOP design.  You do not want to take a look inside most CMSes.  One of my favorites, TYPO3, is pretty scary.  A CMS is not meant to be tweaked (except through their handy admin interface!)

But my main source of frustration is that they almost universally cram all your content into a database.  That’s bad bad bad.  I do not want to author my site via a textarea (even if it’s TinyMCE) and I don’t want to lay it out via the amazing admin interface!

And I don’t want my templates to be one off monstrosities.  (Using one-off markup and scripting, no doubt.) And chances are that cool widget you want to include does:

printf(“<td border=2><font color=”red”><b>widget content</font></b></td>”);

instead of actually working with your theme.  Which you probably don’t want to touch to customize anyway.

This screams MVC separation.  I want widget content to be the widget.  And I want my controller to specifiy the parameters for the widget.

But how do you do that in the URL when you’ve got multiple widgets?  That harks back to my problem with MVC frameworks.  And you know what?  An admin interface(!) for an MVC framework would be nice.  I shudder to think of it, but the best idea (if not user interface) for that admin interface I saw was ATG Dynamo.

I’d like to leverage the content-centricness (and components) of CMS framworks, but I don’t want to deal with authoring all my content in a textarea and saving it to a database BLOB (and deploying it via their cool admin interface!)   I want to use components, but I want them to be simple STDIN, STDOUT type components.

This is where frameworks like CakePHP fall down I think.  The component development process for Cake is (I admit mostly ignorance) is as convoluted as it is for Drupal.  I think Zend does a better job, but I haven’t really seen a component market for Rails (again, I’m fairly ignorant), apart from things like the AJAX HTML component wrappers.  I think I actually prefer the CMS way of building a template via (bastardized) HTML than the HTML::Template / Struts style that Rails has adopted.

What I really want is a front controller that does a good job of setting up my resources (such as sessions, db handlers, etc.) as plain objects(!) and provides wrappers for things like authentication and action mapping, and then passing it off to my response handler after running my action chain (which uses simple MVC components) which then builds the page accessing the views, selecting the template, theme, passes in pure data to components (which pass back pure data) and uses my content objects — which are versioned files, not database BLOBs, and lays them out according to my specified layout and theme (separate objects) which are probably handled through my nifty admin interface!

It’s okay to generate content via a textarea – like for a wiki or blog  (or even a form) but it should be just as easy to upload manually.  As a matter of fact, that leads me to my next one:

The trouble with Blogs, Wikis, and Forums.