Wrestling with Plone

I’m currently wrestling with some Plone based coding for seafelt, the network management software Unicity is developing. It’s proving to be more of a challenge than I thought it would be.Plone is a great system for developing websites, like this one. It’s extremely useful out of the box and has a lot of great add on software to enable you to do common web stuff with. However, it suffers from some common open source maladies that are being fixed, albeit slowly. The two biggies are the documentation and the code itself.

The documentation for Zope/Plone is ok. There is a fair bit out there, and some, such as The Definitive Guide to Plone is excellent, but it’s lacking once you get past being a complete novice and are digging around with more complex tasks in the heart of the system itself. This is probably a fair position to take, since most people want to use the software, not muck about with its internals. Those who are playing with the guts have no doubt been doing so for a while, so they’ve already learned what they need to know.

That leaves someone like me a bit on the outer as far as documentation goes, but that’s ok, since I can read the source, right? Yeah, sure. Zope code, and by extension Plone code, is a mess. Parts of it are downright awful. Migration code should only ever run once, folks, not be required every time you create a new Portal object. More comments would be handy, too. On the odd occasion that someone has bothered to add a docstring, it often says something like “addPloneWidget(): adds a new Plone Widget to the portal”. Well, duh.

And so I end up having to wade around reverse engineering the silly thing to figure out what’s going on. Some of the code is quite cool, dynamically adding sections present on the filesystem into your Product, dynamically updating when you change it if you configure it that way. Very nice. Of course, finding the bit of code that does the dynamic adding is non-trivial, since the variable names are close to what you’d think they should be, but actually mean something else. portal_layer, when it really means skin_path, for example.

Maybe I’m being overly harsh in that I haven’t spent a huge amount of time looking for doco on the web. That will be my next task, it would appear, but I won’t hold my breath. Past experiences have shown that what documentation there is is usually out of date, hence my going straight to the ultimate reference: source code. Perhaps I’ll be pleasantly surprised this time.

Bookmark the permalink.

Comments are closed.