Nov 26

Django as CMS or Django as App Framework?

Working myself into a corner in Django...

Like many of you, I once developed my websites by hand, in static HTML. I was proud of my Notepad skills. I learned CSS. I became enlightned and switched to Linux on the laptop, started using vim for everything, and eventually ended up (back) on a Mac, where I happily sit today. As I become responsible for managing more and more sites, doing everthing in static HTML became impractical. I had put off migrating to a CMS for quite some time, mostly because too many CMS's gave you the kitchen sink (Plone, Drupal) but made it a burden to develop a simple site that had few requirements beyond the ability to apply templates, and manage static blocks of text, news posts, calendars, etc. Not every website needs to have a multiplicity of social features.

After trying a number of systems, and bailing on them, I finally found CMS Made Simple. This was more like it. The core functionality was everything I needed. It had a plugin architecture that was unobtrusive and well integrated. It used a very good template library, Smarty. I began migrating sites to it. It's biggest drawback, however, was that it was a single-site system. You could not run multiple domains in a single application instance, but had to duplicate the code base, and install a separate set of database tables for every site you wanted to serve. This made upgrades a real pain.

Soon I began to need functionality not provided by any specific plugin. Having done a fair amount of PHP work in the past, I set to work developing custom tags. This quickly became tedious work. Since I was very much limited to integrating tags into pages, everything had to be implemented as a tag, including the controller logic. I decided it was time to look elsewhere.

I flirted with Rail, but it was slow, and I disliked the abiguous grammar of Ruby, and hated all the "magic". I dipped into the waters of CakePHP and Symphony. I found Django when I began searching for information on the performance of these various frameworks. Django had the clear lead, much to my surprise, for it was written in Python, an old love of mine which I abandoned some years ago after spending many frustrating hours maintaining Zope applications that performed poorly, and that nobody else could understand. Back then, if you wanted Python on the web, there was Zope, and there were a lot of primitive frameworks not even worth considering. Wow, had things changed.

I built a couple little apps in Django to get the feel of the framework, and then decided to plunge into a CMS system. Django, everybody seemed to concur, had no "killer" CMS system, because it was so easy to make a CMS in Django, that by the time you configured somebody else's to your taste, you could have written your own. This was a nice theory, but was true only in so far as you expected nobody else to maintain your site. If, on the other hand, you wanted an integrated system, where pages, templates, stylesheets, menus, URLs, and the like are all database driven, and maintainable by the end user — well, there was a lot of work to do to get there. Yes, Django makes this easier than any other framework I have seen, but it's still many hours of work.

Well, I am there now. I have a fully working, multi-site CMS framework, with a generic posting system with basic comments and RSS feeds, database-driven templates and stylesheets, WYMEditor for rich text,  and CodeMirror for template and stylesheet editing, custom tags to generate CMS page links, navigation, feed links, and the like. I now have the level of functionality that I used in CMS Made Simple, except it is faster, I understand all the code, and I can extend it to my heart's content. My users can now edit and create their own pages, specify URLs, and reogranize their site's structure, all without touching, or knowing what a view is.

Pardon for the long lead-up, but here's where I'm having issues. My framework is very much page-oriented. A single view handles every page on the site. Other views are utilitarian (fetching stylesheets, for example). This is a requirement if I want the users to be able to manage their own urls, page hierarchy, and navigation. If I were to break this trend, and spin off applications into separate views with their own URL config, suddenly the site tree-based site navigation system would be broken, and whole parts of a site would be pulled out of the user's control.

There is a related problem also. Right now, my framework is generic by design. The framework itself is not designed to be modified for specific applications. Ideally I should be able to install it anywhere, and updated it to a new version at any time, and no site-specific applications would be broken. I can't do that if I am modifying my views for custom apps.

And so, where does that leave me? Right back where I started! I am stuck doing all application integration as custom tags called from templates on the base CMS framework. There is no way to write a view, because that would require pulling a URL out of the page navigation system, and hardcoding it into If I want to add to a page's context, I have to do it using kludges like a custom tag. It's not so bad as it was in CMS Made Simple. My page objects are intelligent enough to allow additional parameters to be passed on the URL as if they were sub-pages (ala Zope), and added to the Page's context. I also have some form integration extensions.

I am not sure yet what the answer is, but it raises interesting questions about the tension between a very good and easy-to-manage CMS framework, and a very good and powerful Application framework. Django is both. But can it be both at the same time? I believe the answer is yes, but I am struggling with how best to make this work.


I'm a Lutheran pastor, a CTO, a father, amateur photographer, programmer, Irish music fan, and all around geek, but I only have one blog. So, you will find here a mix of theology, photography, geek speak, family news, and whatever else strikes my fancy. If you get confused, there are now categories…




Recent Posts