My reflections on my first Plone conference…
Things that were great
The conference, in whole. The organizers did a great job, and we should all contribute to pay off their mortgages.
I’m sometimes a bit jaundiced about the overused word, “community,” but the Plone/Zope community is aces.
Things that weren’t great
The Ronald Reagan Building and International Trade Center sucked. It’s cold, bland, and too big.
The Reagan building’s Wi-Fi sucked, sucked, sucked. It’s beyond me how the largest building in Washington, D.C, with 3.1MM square feet, could be overwhelmed by the network activity of a 310 person conference.
I would have paid $40 more in registration fees for slightly more interesting lunches.
Yeah, no kidding
I now see how I‘ve been a horses ass haven’t fully appreciated interfaces, and the Zope 3 Component Architecture. Previous comments tried to set me straight, and they partially succeeded, but the Bootcamp and conference really drove it home. I am now less ignorant.
TTW’s benefits are clearer to me. However, I still believe its complexity costs outweigh its benefits.
ZPT, TAL, TALES, and METAL ain’t so bad. They’re more complicated than Django’s template language, and aren’t Pythonic, but I’ve dealt with worse.
I now better appreciate portlets.
Eh, I thought that seemed odd
I’ve been irked by the existence of Zope 2 and Zope 3 based theming, and the semantic overlap between “skinning,” “theming,” and “customization.” I was gratified to hear other more experienced individuals also critique these areas. (“Ah, so I wasn’t crazy.”)
I’ve also been quite skeptical about Plone’s general complexity. Hearing others debate this topic was, again, instructive and reassuring.
The notion that portlets and viewlets should be unified into a new kind of “widget” or “tile” object: Ditto.
I’m still chewing my cud on…
TTW simplifies some processes but complicates others, and I still don’t see it as a net plus. For example, the recommended product creation cycle is:
- Make TTW changes
- Export them
- Update the disk files
- Reload the product to verify the results
Holy crap, where do I begin? This is rather involved. For one thing, editing XML files to identify necessary tags, and remove unnecessary tags, is wretched. And it’s terrifying for non-developers. Eyes bulged from their sockets in the Theming bootcamp.
Simplicity is powerful and approachable. Complexity is neither. Complexity originates from multiple choices; decisions and tradeoffs ensue, and then decision time and stress increases.
Since products can be distributed only via disk files (duh), dealing with files has an inherent advantage over TTW. But graphical menus can be easier to deal with, of course. I think Plone should completely jettison TTW, and make the file-editing development model easier. E.g.:
- A better “Zope automatically updates itself when files are modified” development mode. Like, you shouldn’t have to hunt for multiple checkboxes to turn on this behavior. Maybe use a daemon to detect when the configuration files have changed?
- Python files used for configuration, instead of XML. More on this below.
- Better tutorials and guidelines for newbies. I know the doc team is already thinking about this.
XML is the wrong language for configuration files. It sucks. Don’t pretend this isn’t True. It’s ugly, intimidating for non-techies, and error-prone.
“Tags” are not obvious to non-techies. Neither is finding matching tags. Neither is understanding that empty tags can be deleted. Neither is scrolling down the page to find the matching end tab. And then there’s the intimidation factor of all those characters blasted onto the screen.
A Python configuration file would be better in every characteristic that matters. It would be easier to learn, less intimidating, more appropriate, easier to edit, less error prone, etc. Good grief, “
Variable = value” is drummed into everyone’s head in elementary school! It’s the most common mathematical statement in the world!
Using XML for configuration files is a Fail, and an embarrassment.
…Don’t hide Python, dammit
Continuing this train of thought, I disagree with the hiding of Python from the casual user.
I heard many times, “…and a great thing about xxx is that you won’t have to learn Python!” But, Python’s ease of learning is often cited as a Plone/Zope advantage! For example:
- “Zope itself is written in Python, an easy-to-learn, widely-used and supported Open Source programming language.”
- From Web Component Development with Zope 3, pages 11 – 12: “Python is easy to learn…Python is easy to read…Python is easy to write…Python is easy to develop with.”
It’s insane for Plone/Zope advocates to say that learning Python is easy, and that learning Python is hard. Python is easy, especially if you’re using it to just set configuration constants.
The Plone community dwells on the dichotomy between administrators and developers, and I think this drives a lot of squirrelly decisions. Administrators aren’t morons. It’s a mistake to coddle them by “protecting” them from Python.
Python’s core approach is DRY. Plone violates this multiple times. Multiple ways of doing multiple things equals a lot of choices, which equals complexity.
I’ll stop now.
I get it now. I think.
Plone’s customization paradigms differ from other frameworks I’ve used. I’ve been thinking about it at a conceptually lower level than where it is. Django is essentially raw Python, whereas Plone (for better and worse) has more moving parts. I need to move to a higher level of thinking in order to appreciate some of Plone’s aspects.
Kapil Thangavelu gave a good talk about ContentMirror. He told the story of how a colleague asked whether Plone is a framework, or a product. That’s a great way to think about Plone. But there’s another aspect, which is Plone as a design tool. It’s using Plone as a rapid prototyping and design tool, relying on its defaults to render pages in a reasonable way, and relying on the styling hooks provided by its default
<div> tags. Hmm.