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
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
- Iterate.
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
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.
…violating DRY
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.
Seek Nuance 
If your complaint about XML-based configuration files is about ZCML, you have heard of the Grok project, right?
Using Python for configuration files is fine. In the past we’ve noticed however that sometimes this leads to unholy mixtures of code and configuration, especially if confined with not-very-well-designed configuration UIs.
The reaction to that was ZCML: a designed configuration system where we had a domain specific language to do configuration. The main drawbacks: violates DRY, scares off Python developers.
The reaction to that is Grok. We deduce configuration from the Python code that you need to write anyway. No separate configuration files, just your code, with a few extra hints to the configuration system where necessary.
All this is coming to a Zope 2 near you.
@Martijn: If I needed only a web framework for my project, I would have stayed with Django. I’m learning Plone because I need a CMS, and Grok‘s not that. So, Grok isn’t a candidate. (Unless I’ve greatly misunderstood Grok.)
Before I finish reading your post I felt I had to comment.
The lunches were AWESOME. Absolutely awesome. I remarked to a few people that the quality would actually put me off hosting a plone conference out of fear of not being able to compete.
@Matt: Eh…really? They were the same bag lunches every day, with the same choices. The sandwiches were OK, but nothing to write home about.
Oh well. TEHO.
John, I’m not telling you that you should start using Grok. I’m telling you what Grok is about, and that Grok technology is coming to a Zope 2 near you. Sorry I wasn’t clear; I mean that people are bringing it to Zope 2 so they can use it with Zope 2-based software, like Silva and Plone.
@Matt: Did we go to the same conference? The lunch was, excuse my honesty here, approaching insult. I felt like on a school trip in junior high. I’m really happy John did comment on this particular issue.
One of the most important aspects of a conference is to be able to socialize, enjoying a good coffee, having a nice lunch etc, ––– in a comfortable space! I think most will agree that Reagan was unfortunately none of that.
But it’s a challenge to have a conference in Washington DC; it’s a rather uptight city, with a lot of security paranoia; ultimately, given the challenges, Alex and friends did a great job. However, future bids should perhaps go to destination that are more accomodating, not only central.
@Martijn: Sorry for my confusion. I guess my response now would be, that’s great! 🙂
But, wouldn’t you agree that rather than layer another tool/framework on top of Zope, it would be better to remove the XML crap from Zope? Like maybe in Zope 4? 😉
@Malthe: +1 re: your venue comments. They did a decent job of camouflaging the external barricades, but after a couple of days the security got to be a drag. I understand its need, but I’d rather not deal with it every day…
I wonder how it affects your personality to live and work there.
@Malthe The sandwiches were good, plenty of meat in them, nice crisps, two types of salad, fruit and a sweet.
What’s not to like? Granted, the venue wasn’t very condusive to a sociable lunch, but the lunch itself was good!
I fully agree about the complaints about the logistics. The building was to big and the rooms spreaded of the half building. And food…sorry guys but the amount we have paid for the conference I have seen conferences with a much better food service). The WIFI…well..basically not existing…this should be a lesson for the organizers of the next conference. Having WIFI is possibly more important than having good food 🙂 Comparing the Plone conferences over the last years…the latest one at Vienna and Seattle where possibly the best ones I attended so far. Also the reachability of the location from the hotels is an important point. Looking back at the Naples conference last year, the conference location was pretty much outside of Neaples, a bit hard to reach and the surrounding area was more than “attractive”.
John, I’m not sure what you’re asking for. You want to get rid of XML-based configuration, right? You can’t just expect to simply remove the “XML crap” and have everything work – you want a Python based configuration system, and this needs to be thought about and developed.
We’ve done that in the course of the last two years. Grok has an alternative configuration system for Zope 3, and it’s mostly just about writing the code you’d need to write anyway; you can just leave out the ZCML. It reuses most of Zope 3’s configuration infrastructure (and is compatible with it), just gets rid of the ZCML.
It’s a layer. It doesn’t layer on top of ZCML; it replaces the XML bits of the ZCML layer. Software is made out of layers, or at least components that use other components. You just want good layers, and not too many of them you need to know about at the same time, as that is confusing and frustrating.
Unfortunately you can’t just rewrite a large code base like Plone to be simpler, as there’s a lot of value in it. Plone wants to move forward. This will lead to the introduction of new ways of doing things and the old ways typically can’t just be removed right away.
My hope is that Plone can move forward in a measured way, step by step, to a system that’s less complicated for people to learn. That’s up to the Plone developers to develop – I’m just saying Grok technology is here today and can help.
P.S. I understand that the context switch between code and ZCML is frustrating and not conductive to rapid development (that’s why I helped kick off the Grok project). But I’d also at least try to study the history of why the “XML crap” is there. Thought went into it, and while I don’t believe it was entirely the right direction, it isn’t entirely the *wrong* direction either. Don’t throw away the good ideas along with the ones that didn’t turn out so well.
@Martijn: I don’t feel a burning need to study the history of the XML decision, although I wouldn’t turn away a history lesson if someone cares to give it. XML is the wrong language for a configuration file, period, full stop, end of story. It’s using the blunt end of a screwdriver to hammer a nail into the wall.
Regarding your other points, my previous response about removing XML from Zope was insufficiently detailed. I agree with you re: layers and such, and sure you can’t just snap your fingers and immediately swap out a system component. and replacing ZCML is different than laying on top of ZCML. OTOH, if ZCML were replaced by a Grok component, it should be seamlessly integrated into Zope. One shouldn’t have to switch into Grok-mode; it ought to feel natural and without a context-switch. I presume you’d agree with that goal?
I see you’ve elaborated on this matter at length, on your blog.
I’m right on there with you for NO XML CONFIGURATION. For any project – it’s not even just relevant to Zope. Shoot – look at CruiseControl. Everyone agree’s it’s a fine product and that setting up the configuration is a monstrous pain in the ass.
The *only* reason for an XML based configuration is if you’ve got an external tool that needs to communicate with your application – and that tool is dedicated to creating configurations. I haven’t seen that much… and in the meantime we’re all stuck fucking around with XML.