[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.
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.🙂
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.
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
These are just things that bug me this week.
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…