Moving from Django to Plone

This is the first of what might be a series of posts about learning Plone.

I’ve worked in Django since January 2006, when Joe Heck, Karen Williams, and I built the now-defunct TrenchMice site. I haven’t done any Django work since March, when I joined Fisher Communications, but I’ve followed the mailing lists and blogs. And I bought and read the recently published Django books, just for grins.

At work, I’ve been getting ready to launch a Django-based CMS project. It was going to use Ella, PyLucid, Ellington, or maybe be built from scratch. But at the end of July, unexpected requirements changes made me shift it from Django to a Plone base. (I won’t go into the reasons why now; that’s an interesting post for a later time.) So without any warning, this Djangonaut needed to become a Plonista.

I thought that writing about my process of learning Plone might be useful to future Plone neophytes. Or at least entertaining.

Caveats

I’ve been learning Plone for all of one month — and a significant part of that month was actually spent working on other small projects. Many of my impressions and thoughts may be naive or flat-out wrong. If you argued that trying to learn anything from my posts would be like the blind leading the blind, you’d have a strong case.

I’m learning from books and on-line documentation, and my best other framework is Django. If you have a colleague’s assistance, or you’re coming from another web framework, your experiences may be different.

Why write about Django -> Plone?

Plone is a CMS, and Django is a web framework. Isn’t it silly to write about going from one to the other?

As far as I know, all Django-based CMS today are libraries of Django applications and templates. I.e., when you’re developing in a Django-based CMS, you’re actually developing in Django itself.

Plone is layered on top of Zope CMF, which is a CMS framework product for Zope. Zope is a web application framework. So Zope, Zope CMF, and Django would be at roughly equivalent levels in a software stack. For the record, then, any comparison should be between Django and Zope.

It so happens that a lot of Plone work is in fact done in Zope. You’re either using the Zope Management Interface (ZMI), or fiddling with your development box’s Zope server, or editing Zope files. Some work is done in Plone’s site configuration tools, or in Plone product files. But if you’re doing any non-trivial Plone work, you’ll be working in Zope.

Since Plone is a CMS and Django per se is not, we shouldn’t be surprised that Plone is more powerful. This isn’t a criticism of Django; they’re different tools aimed at different jobs. But they have similar concepts: Schemas, configuration files, templates, Python code behind templates, forms, content types, etc. In any case, I’m not writing to compare Plone and Django; I’m writing about how it is to learn one after working in the other.

First impressions

The first thing that bowled me over was how much more stuff Plone has. My head was swimming for two weeks with new acronyms, concepts, and code pool organizations.

Let’s start with this: Plone comes with a built-in object-oriented database, Zope Object DataBase (ZODB), and an optional distributed object architecture layer called Zope Enterprise Objects (ZEO). (But ZODB isn’t tied to Zope; any Python application can use it.) ZODB’s lowest layer writes to FileStorage by default, which stores pickles in a single file, with the right things magically done for transactions and updates.

Adapters allow you to replace FileStorage with other stores, like PostgreSQL, but most CMS applications would want to use ZODB. It’s designed to store Python objects, and is tuned for lots of reads and occasional writes. That’s exactly what a CMS would want. If I were building a CMS with Django, I’d be using an SQL database, which wouldn’t be optimal. (The Django mailing lists have occasional posts about using an OODB with Django. It’s not the framework’s design center, and I don’t know if any of them are viable. I personally tended to avoid anything not documented in the Django site.)

When you install Django, you also install, say, PostgreSQL and psycopg. You don’t think of the latter two as being part of Django, and so their complexity is not Django’s. But you’ve got to install them, administer PostgreSQL, and maybe do some tuning. Plone out of the box effectively includes the equivalent of Django + PostgreSQL + psycopg. (Yes, Django comes with a built-in development server, but it’s not for production use.) (Yeah, an OODB is not an RDB, but they’re both database servers.)

Plone comes with so much stuff that it’s actually a working CMS out of the box, including content types and permission-based workflows:

…while Django just provides a “Welcome to Django” page. That’s OK, Django is not a CMS!

Plone and Zope have been around for longer than Django, and so they have more legacy cruft. There’s Zope 2 and Zope 3 (one is not a newer version of the other — they’re incompatible — great naming choice, guys), Plone 2 and Plone 3 (Plone 3 runs on Zope 2 – clear?), an older and newer way of packaging (and therefore, installing) products, and a compatibility package that provides Zope 2 access to some (most?) Zope 3 objects. I don’t know the exact origination dates, but Zope has existed since at least 1996, and Plone 1 was released in 2003, which was also the year of the first Plone conference.

Django’s got a much cleaner code universe. But it, too, will have legacy cruft when it’s 12 years old. In a way, this is a good problem to have, because it indicates technology with a long and vibrant run. But, it increases the concepts you’ve got to learn, or, the number of mental notes needed to ignore documentation about the alternative techniques.

Books, presentations

Don’t waste your money on The Definitive Guide to Plone or Building Websites with Plone. The former is available free on-line, and both were written in 2004. That’s a millennia in Plone time. Unless you’re maintaining a system that hasn’t been updated in four years, they’re useless.

The Plone book to buy is Professional Plone Development. And the Zope book to download is The Zope Book.

At the Seattle Plone Gathering‘s April meeting, Justin James and Brian Gershon gave a talk comparing Plone and Django. Check out their slides.

On-line documentation

This is an area where Django really, really shines. You can learn DJango by starting at the top of Django’s documentation page and working your way down the page. That, and following the Django users mailing list, will get you productive in a very short amount of time. The newly released Django books are great, but you can do great things without them.

In contrast, I find Plone and Zope 2‘s documentation very confusing. With Django, it’s clear where to start reading, and the concepts are introduced in a logical order with very few forward references. With Plone, I can’t tell where to start. The documentation isn’t (IMHO) organized with an obvious “top.” Everything references everything else, and you have to master multiple concepts before you can be productive. For those of you who, like me, sometimes worry about being smart enough to master something, it sets the stage for a lot of stress. (What does xyz mean again? Dang it, I read about it yesterday. What tutorial was that in? Ahhhh, shoot, I thought I bookmarked it. OK, here it is. (refresh memory) Now, where was I? Ahhh, nuts…)

Make contacts and Plonista friends

I can’t emphasize this strongly enough: Join your nearest Plone group and make some new friends. It’ll help you get up to speed. (And after you get up to speed, remember to pass on the good karma by helping others!)

The Seattle Plone Gathering seemed like a moribund site. But, no: They’re alive and well, and have regular meetings. Some of the members have been gracious in welcoming me to the club, and super helpful in giving me pointers. (Thank you, Brian, Jesse, and Andrew!)