About a blog, part II

In my last post about this CMS, I promised to write about how I ended up with Django. When I originally decided to roll my own blogging software, I was planning to do it with Zope 3. While Python has a plethora of frameworks— probably more than most languages—I have experience building things with Zope and I like it, so that seemed like a good fit. For the time being, Pylons, TurboGears, Web.py, CherryPy, Django, and many lesser-known web frameworks weren't under consideration.

But I have 2 main complaints about Zope. The first is the barrier to entry: building a new app requires you to write tons of boilerplate code specifying interfaces and then to write tons ZCML configuration code to wire those interfaces together. The benefit to this is that the configuration of your application is incredibly flexible and powerful; I'm convinced you could build just about anything in Zope 3. But in the end, all I wanted was a blogging CMS, and Zope felt like using a 747 to get to the grocery store. For this reason, I began to lean towards Grok which aims to solve Zope's complexity problem by sitting on top of Zope and generating much of that boilerplate code for you. As the Grok developers put it:

Zope 3 is already powerful and flexible. Grok aims to make it simpler and more effective, for beginners and experienced developers alike.

But one concern still remained: the ZODB. That's Zope's persistence mechanism: an object-oriented database for storing Python objects. The nice thing about the ZODB is that it saves you from ever having to write a line of SQL. Not that I mind writing SQL, but with the ZODB you can do more with less code. Well, kinda: the problem is that some things like indexing or full text search that are already solved by many RDBMS require a manual approach with the ZODB. Furthermore, I wasn't sure how well the ZODB would perform in a shared hosting environment. And by this point I'd decided I wanted to make my CMS publicly available and I wondered if the lack of a RDMBS might cause people to avoid the thing.

It is possible to use an RDBMS with Zope of course, but then you lose a lot of the benefits of Zope. You're back to writing SQL or using another ORM like SQLAlchemy. And as excellent as SQLAlchemy is, it just doesn't work as well with Zope as it should. I've heard that people have had success with z3c.zalchemy, which provides SQLAlchemy integration into Zope 3, but....well, all this was beginning to seem like a lot of work for blogging software.

So I started to look at some other frameworks that probably weren't as powerful as Zope, but might get me up and running faster. Some, like CherryPy, were a little too low-level. Others didn't seem like they were as well maintained as I was looking for. I quickly began to gravitate towards Django. For one thing, Guido likes it and most importantly, it was originally designed to exactly what I was look to do: build a CMS. Developers at the Lawrence Journal-World created it to run their newspaper's website.

And once I started working with it, I began to think that it was exactly what I was looking for and about a week later, I had a working CMS that I was ready to deploy and that is currently powering this site. Next post, I want to talk about my impressions of Django; what worked and what could be better.