[This continues from my first post about my Django-to-Plone odyssey.]
I now understand more of Plone‘s underlying concepts. I can’t yet create a non-trivial Plone site from scratch in a reasonable amount of time, but I’m getting closer. I’ve read some of, and have temporarily put aside, Professional Plone Development. I’ve read a few of the on-line tutorials and quite a bit of the documentation, and I’m now reading The Zope Book, which has been the high point of the past week.
For your erudition or amusement, here are more notes from my shift from Django to Plone/Zope.
Light Bulbs
These little epiphanies enabled parts of the Plone/Zope universe to click into place. I hope writing about them will help someone else…
I should have first read The Zope Book!
When I learn a new technology, I usually first try to understand the general design before I delve into the details. And then, I need to understand a good number of details before all of it starts to make sense. I need to more or less understand all of something, at least conceptually, before I can grok any one aspect.
I know individuals who can just focus on one item, and ignore everything else in a technology. Boy, that must be nice! Boy, am I jealous! The learn-the-big-picture-including-details takes time, and I’ve long wanted to make my brain not need it. With enough willpower, any change is possible, right? So…I have tried learning just Plone, and treating Zope as something to be understood only when necessary.
Not learning Zope first was a bad move. Suffice to say that it’s been a frustrating time, and information wasn’t being absorbed as easily or quickly as I wanted. But now that I’m reading The Zope Book, many light bulbs are turning on, and the concepts are coming much easier. (I guess I can’t change my brain’s wiring after all.)
I should have first learned Zope, and then Plone.
Everything in the ZMI is an object in ZODB
The Zope Book made it clear: Everything I see in the ZMI is an object in the database. Even the Control Panel! Early on, I tried searching for some items in my Zope instance folder, and came away frustrated. Now I understand why. Duh!
Acquisition vs. Inheritance
Now that I’m reading The Zope Book, I finally understand acquisition, and how it differs from inheritance. It’s like inheritance, but based on an instantiation’s container ownership instead of class definition. To wit, if object A contains object B, and inheritance cannot resolve a reference, acquisition is used to traverse up the containment hierarchy, starting with A, to search for a resolution. Django has nothing comparable to this.
It’s an interesting tool. Although I don’t yet understand how often it’s useful in real world applications, I’m taking it on faith that it is. 🙂
Different concepts
I’m mulling over some conceptual differences between Django and Plone/Zope, and how they might affect application design and my productivity. Including these:
Zope is OO, Django isn’t
Zope’s very much OO. Everything’s an object, folder objects are everywhere, objects contain other objects, etc.
There’s at least one person out there who considers Django to be object-oriented. I sure don’t. On one hand, models are classes with methods providing row-level functionality, forms are objects, and views can be considered objects if you drink three beers. OTOH, aside from forms and models, everything is a function, including views. Look, OOP is far more than using the right nouns and verbs. It’s how and where the nouns and verbs are used, their relationships, and the language’s or application’s control flow. You’re either passing a ball to the toss() function, or you’re calling ball.toss().
I’m not advocating OOP here. Sometimes it’s inferior to simple procedural programming; and besides, I’m really a fan of fully- or quasi-functional programming languages, like Lisp. What’s clear is, you should get into an OO groove before you pick up Zope, because it’s saturated with OO paradigms.
The “admin” interface
Django’s administrative interface is distinct, in both UI and UX, from the site being administered. (Unless, that is, your site looks and acts like Django’s admin interface…)
Plone/Zope has two administrative-interface levels, and it took me a little while to appreciate this. It’s fundamental to things, since Zope is the framework and Plone is the CMS:
- The Plone interface(s), with which priv’d users add/modify/review content, is embedded into the site. After you login, you’ll see a menu that lets you modify content, and it’s part of the site’s page layout.
- The Zope administrative interface, aka ZMI, is comparable to Django’s admin interface. It’s visually distinct from anything else, except perhaps a GUI-based file browser with tabs and forms. A lot of Plone cusomization via the web is done through the ZMI. In fact, Plone’s setup page links to the ZMI.
ZPT, TAL, TALES, METAL
I may get flamed for writing this, but I greatly prefer the Django template language over ZPT, TAL, TALES, and METAL. (I’m not learning DTML.)
The benefits of a template language that WYSIWYG HTML editors can parse, and therefore display in a reasonable form, is significant. I appreciate why ZPT/TAL/METAL are designed the way they are, and also appreciate that the problem space isn’t trivial. I can even personally recall more than a few times when editing Django templates in Dreamweaver was a PITA. Yes, I do get it.
But I think where ZPT ends up is “a cure that’s worse than the disease.” The Django template language is extremely Pythonic and easy to understand, and ZPT is neither. The syntax is in fact very ugly. I am sure my colleague in the next office has been distracted by all the outcries of, “Oh come on, you’ve got to be kidding me!” as I read about ZPT.
Am I overreacting? Or will I be fine once I get used to it and get in the swing of things? I dunno…
ZPT has a few explicitly un-Pythonic warts. Exhibit A is python:test().
Irks
These are just things that bug me this week.
Folderish
The word “folderish” is asinineish. The documentation should just call them containers everywhere, and assumish that the readers aren’t moronish. Inventing a word that’s vague, and confined to just your knowledge domain, is never betterish than using a realish word.
Configuration file formats: Some XML, zc.buildout idiosyncratic
Grrrr. Why do Plone and Zope use XML in their configuration files, instead of Python?
If you want to learn Plone or Zope, you’d better love XML. It’s everywhere. Far be it from me to critique the inappropriate use of XML — many blog posts and magazine articles have been written about that already. I don’t like it anywhere except for bona fide data markup.
Using zc.buildout seems to be a Plone best practice. Why does zc.buildout use an idiosyncratic format for buildout.cfg, instead of Python? I can’t finger Plone or Zope for this, but buildout.cfg being so prevalent just adds more irritation to the pile.
The problem with these other formats, aside from inherent syntactic problems, is the required mental context-switch when you move from one to the other. One moment your brain is in Python mode, and the next moment it must switch to XML mode. And some moments later, it has to switch to [insert idiosyncratic format here] mode. But if all the files were Python, you’d expend less mental energy. Django can be configured without a drop of XML or idiosyncratic file formats, and there’s no reason why Plone and Zope couldn’t do the same.
Documentation links, directory maps, and some filenames: FAIL
The Plone Documentation Team and its contributors have published a wealth of documentation. As a newbie, it’s sometimes hard to know where to start or where to go next, but it’s undeniable that (a) there’s a lot of it, and (b) the individual documents and tutorials are very well written.
But I’m noticing two kinds of warts in the Plone’s documentation: Broken links, and out-of-date diagrams or file paths. It’s a little weird, given all the obvious energy and devotion that’s gone into the documentation.
I cannot remember seeing so many 404 links in other on-line documentation. I’m also surprised by the frequency of incorrect directory layout figures or filepaths. For example, “Figure 5 shows the layout of the instance directory,” or, “The yadda/yadda/yadda directory…”
I guess that recent code pool development changed where (quite a) few things live. What that happens, also changing the files’ documentation links has to be de rigueur. Sure, some personal blog page out there might have a broken link, but that’s to be expected. (You can leave a stub in place if you want to be nice.) Maybe the documentation’s grown beyond the abilities of the number of people involved to keep it tidy? In one case, a year-old tutorial had a directory map that was wrong. Gaaaa!
I read posts in the documentation team’s mail archives that asked for submissions for broken links. Yeah, that would be more useful than writing about them in a blog, right? I’ll try doing that this week. If you’re not part of the solution, you’re part of the problem, et cetera…
Seek Nuance 
I have a lot of experience in developing Plone sites (six years) and of course Django sites (three years). I’m not sure about your reasons for migrating to Plone, but in my opinion Plone is extremelly and innecesary complex, and is not well design because Zope. It’s better develop in python unless this both things happends:
* Your site is like a “plone” out-of-the-box, with little changes.
* You have a lot of previous experience in Plone and you won’t learn in Django after all.
Some notes:
* Plone learning curve is maybe a hundred times more than Django. Although you thing you know Plone, it’s not true. Always you will suffer an strange error that you don’t understand. You have to know Zope 2 and Zope 3 very well to handle this kind of errors.
* Plone performance is very bad (~5rps), and you must have too much experience in optimizating plone sites to avoid it. In a only read site is not problem, if you use CacheFu.
* ZODB writing performance is very poor, especially because plone catalog. The conflict error posibility in sites with high writings rate.
* ZPT template in theory can be open with DreamWeaver, but in practice not. Try to open main_template.pt with any WYSIWYG HTML editor. I thing web templates shouldn’t be XML based, because it less clear and is difficult to write non HTML content with that template.
*
Isn’t Django an application framework, while Plone is a CMS? How are you fairly compare the two?
I have to agree with Manuel. Plone is a huge pain in my side and I’ve been working toward migrating everything to Django.
I think one of it’s greatest failures is the complete lack of documentation when it comes to the latest release.
And the insanely abstracted complexity of the simplest tasks.
Manuel almost read my thoughts! I tried to learn Plone/Zope few times and always stopped at: why so complex?
I’ve followed Plone for a long time (since the 1.x stage), bought the books, watched conference videos, and it’s still confusing to me, and I could never recommend it to a client.
The plone programmers are outstanding. But it’s all built on sand: Zope. That was their tragic mistake, i think, using Zope instead of a real database, like Postgresql. Zope and CMF were a quick way to start the project, but now it’s an albatross.
If they had taken the route of a CMS like Drupal, with their skills they would be an immensely popular project. As is, the learning curve is far too steep for most developers.
They should step back and re-evaluate their whole system. When huge Plone supporter Nuxeo dropped Zope and Plone and moved to Seam and Hibernate, that should have been an alarming wake up call. But they littered the ground with excuses and kept on their same path.
@Arthur: Yes and no. If I were doing a direct comparison, I’d compare Zope to Django. But I’m not comparing them, or at least I’m not trying to. I’m writing about what it’s like to shift from Django to Plone, in creating a CMS.
My first post on this explains my thinking. Briefly: When you’re building a CMS using a Django-based CMS application, you’re really working in Django. And if you’re working in Plone, you’re really doing a lot of work in Zope. So in both cases, the frameworks aren’t as camouflaged as you would first think.
@Peter, docs are important, but after many time fighting with Plone and Zope, I don’t really need docs, I go to source code. But source code is not clean and readable, like Django one (any experimented python programmer can read Django code as a english book). Furthermore, right now, Plone code is migrating from Zope 2 (a great error for human being), to Zope 3 (much better, but still too complex (adapters, ZCML instead of python, etc.), and all code is mixed. Now you have to sum the complexity of learning Zope 2 and Zope 3.
And one important thing… all is coupled: Plone with Archetypes (a.k.a. “model”), Archetypes fields with forms fields (model with forms), model fields with widgets, and all with ZODB. Zope 3 is promise of decoupling things, but I think this will happend in Plone in a not near future.
These are the most important stops for Plone development right now:
* Zope Complexity.
* Need really good docs. Not too much docs… only good docs.
* Learning curve, related to docs and complexity.
* ZODB dependence, yet inavoidable even with Zope 3 “godness”. You cannot avoid write conflict errors in environments with a lot of writings.
* Out-of-the box performance.
@Arthur, of course, Plone is a CMS and Django doesn’t (maybe django admin interface).
But if you have to have to build a web app with content management, you can do it in Django, maybe with more work to integrate or build search app, make design, implements your forms, etc., or using Plone, with maybe more optimization and customization work, and less design work (maybe only changes to CSSs), etc.
If you can decide in one tech, ¿why can’t you compare both development techs?
Hi John,
Thanks for continuing this series of great posts. It’s very educational for me to see how people from other systems approach Plone, and we’re currently focusing a lot of effort on making sure it’s easier to get started with Plone — whether as an end-user or as a developer (what we sometimes refer to as “integrators”).
Keep the posts coming, and I’ll make sure we try to address the obvious things that can be improved.
— Alexander Limi, Plone co-founder
I tend to think of these as different tools for different jobs.
I do like the OO of Zope and Plone and I think this works well for CMS’s. Zope3 also has a much nicer developer story than Zope2.
Some of the Plone complexity resulted from the transition from Zope2 to Zope3 (which is essentially a new platform). Zope3 developer practices are now the norm.
For end-users I think Plone’s content-centric design makes it easy to learn and use, regardless of how much you extend it with new content-types or functionality. Many of the other CMS’s have separate content admin/editing interfaces — in Plone, you go the content you want to edit, then edit it.
I think Django is nice when you’re developing a (non-CMS) website from scratch, and is a joy when working with structured relational data.
Caching improves the performance of both Plone and Django.
Yes, Acquisition is used exactly all the time. Which is a problem. It’s powerful, but the implicit acquisition has it’s problem. In Zope3 it’s almost non-existent. So learn it and beware, it does open up some big holes to trip on. 🙂
@john “When huge Plone supporter Nuxeo dropped Zope and Plone”
Nuxeo didn’t do anything at all with Plone, they developed a completely different and competing product called CPS.
“using Zope instead of a real database”
I guess what you are saying here is use a RDB not an OODB? Well they could have, but why use the wrong tool for the job? Zope is object oriented, and content management is inherently OO… why go through the pain of a RDB?