[This continues from my previous post about my Django-to-Plone odyssey. My first post in the series explains why I’m learning Plone, and the caveats that apply.]
For your enlightenment or amusement, here are some things I’m bumping into this week.
Skins vs. browser directories
From the Plone Theme Reference and other sources, I’ve learned about the dual existence of the skins and browser subdirectories.
Ick. Both can hold templates, CSS, and images. The Theme Reference’s explanation of which one to use wasn’t very clear, at least to me. Penn State’s WebLion site had more easily understood advice, but when to use which directory is still fuzzy. The names of the two directories don’t help at all — they provide zero mnemonic assistance.
In contrast, Django has one folder for all site static media (the admin interface also has its own folder), and you can organize it however you wish. (Flat, subdirectories, whatever.) Ditto for templates. I needed about 30 seconds to understand all of that in Django; compared to an hour or so of multiple readings for Plone, and I still don’t think I understand it.
Skin registration complexity
When I create a new skin, I have to make four edits to two XML files just to register it? Gaaaaaaaa!
Through The Web (TTW) adds lots of complexity
Providing TTW access to a site’s design appears to add a lot of complexity to multiple Plone and Zope areas. That, coupled with TTW’s limitations, and how site development works in the real world, makes me suspect that it’s not worth it.
- Doing significant editing in a simple TTW form would be laborious, and you won’t have any of your normal development tools to help you. So it’s suitable for only quick fixes and small changes — on the production server, where you should never be hacking anyway.
- Python scripts are lobotomized constrained by Zope 2’s security policy. I didn’t think it was possible for Python to be unpythonic, but it is in Zope 2.
- Having only one way to do something is much easier to learn. And developer resources can be focused on fixing and improving “the one way to do it.”
Martijn Faassen wrote in his blog about the problems and opportunities faced by Zope 2 developers, including TTW development. I’ll probably attend the session on this topic in the D.C. Plone conference. (I haven’t read about, and therefore don’t understand, Zope 3’s TTW treatment.)
Site developers always have access to the file system, so I don’t see how TTW is advantageous for non-trivial site creation. In every other common web framework I know of, you edit files, test those files, and then propagate them up to production. And this is what you have to do in Plone 3 / Zope 2 anyway, if you’re working on a project in a shared code pool.
For my CMS project at work, we’ll probably use only external methods.
Legal issues with Python
Python scripts are called either “Script (Python) objects” or “External Methods.” The Zope Book, 2.6 Edition, says:
Note that the torturous form of their name (as opposed to “Python Script”) is unfortunate: a legal issue prevents Zope Corporation from naming them “Python Scripts”, but most folks at Zope Corporation and in the Zope community refer to them in conversation as just that.
There must be a good backstory here. I hope to learn what it is at the Plone conference.
Seek Nuance 
Hmm, a legal issue with the “Python Script” name? I’d always thought that the the “Script (Python)” naming in the ZMI was from UI concerns, so that “Script (Python)” and “Script (Perl)” would have closer symmetry and appear next to each other in the ZMI Add menu. Maybe some of these issues stemmed from when CNRI held the copyright on Python?
http://www.python.org/download/releases/1.6/license_faq/
The use of “Method” naming was terribly confusing, esp. “DTML Methods” and “Z SQL Methods”. “Python Methods” was the original name for Python Scripts, but people pointed out that just because older parts had confusing names didn’t mean they had to continue that tradition. So they asked the community for naming suggestions, held a community poll, and “Python Script” was chosen. People weren’t especially enamored with the name, but nobody could come up with anything better … see the mailing lists from fall 2000 for some of this discussion:
http://mail.zope.org/pipermail/zope/2000-October/
http://mail.zope.org/pipermail/zope-dev/2000-October/
There was quite a bit of terminology in Zope 2 that was pretty murky (Folderish!). A lot of this stemmed from the fact that Zope began life as an application and then morphed into a framework. The upshot of all this murkiness was that when they started with a clean slate on Zope 3 they were very careful with terminology usage, and attempted to use as standard as possible programming terminology. The naming within Zope 3 is generally very good.
I like this kind of posting. It’s quite interesting to see the perspective of someone who has used a straightforward modern web framework like Django and now runs into the historically generated complexity of Plone and Zope.
Fixing it all isn’t going to be simple. On the one hand one wants to add more modern technology to Plone (say, Grok), but then one runs the risk of having even more ways to do it. On the other hand one wants to cut things out to seek simplicity, but then how do you safeguard continuity and backwards compatibility? In the end I think both are needed, and I have the sense that the Plone community is indeed moving in this direction.
Keep up this kind of comment!