Django -> Plone: Things that make me go, Hmmmm.

[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.

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.