plone

One of the interesting things about the upcoming Plone 3.3 release is it's consistent implementation of INavigationRoot

In short, this means it's easy to create a design where the portal tabs (the "global sections") do not need to be toplevel folders in your site. I need this for a design I'm currently implementing, where the horizontal "main" navigation is actually the second-level navigation.

Now, instead of rewriting the complete global_sections viewlet PLUS the webcouturier.dropdownmenu integration... all I need to do is mark an intended "toplevel section" as such by applying the INavigationRoot marker interface.

There's a content type NavigationRootFolder that does just that. But it's not properly eggified.

It's easy to write your own custom contenttype that subclasses ATContentTypes.content.folder.ATFolder and apply the INavigationRoot marker interface to it. But still, you need to do all the plumbing.

Luckily, we've got p4a.subtyper. That's a nifty little component that's been designed precisely to apply marker interfaces on content objects, run-time. This allows us to be lazy, which is A Good Thing®.

What we're going to do, is set up a marker interface that allows us to turn vanilla "Folders" into "Sections" that behave as-if they're subsites.

Last week, the nice folks at osor.eu invited me over to do a usability review of their website.

OSOR (Open Source Observatory and Repository) is a multi-year project by the European Commission to promote open source software use in public administrations.

We were able to have a very frank and constructive dialog about usability issues with the current website. The site is a Plone CMS frontend coupled with a Gforge software repository.

There's a couple of design inconsistencies in there that are deeply rooted in the project's mission concept, and fixing them runs into policy constraints. Meaning, it can't be fixed right now.

This confirms my experience, about the way that organizational fuzziness tends to show up as design inconsistencies. Which then translate into technology and usability problems further down the line.

Creating a truly open dialog that connects technology design with business strategy, results not only in better designs, but also improves organizational learning.

Once upon a time customization of the Plone navigation portlet was easy. You just dropped a customized portlet_navigation.pt into a skins layer and presto.

In Plone3, customizing the navigation is still very easy. But it requires a bit more understanding of the component architecture.

Mailman is our mailing list software of choice. Even when using PloneGazette to format mailings, we prefer to use Mailman as the actual mail sender: it's faster, it has superior bounce handling, and it runs on our dedicated list server, outside our Plone environment.

Managing subscriptions for simple publication sites can be as easy as creating a MailManSubForm. However, if you have a full-fledged Member site you'll want to integrate mailing list subscription/unsubscription options as part of the member profile personalization experience in Plone.

We need to use the Plone Member database as master for the mailman database, in other words. This turns out to be quite easy.

Following Martin Aspeli's excellent buildout tutorial, in a clean chroot setup, has helped me rediscover the joys of programming. Because, let's face it: if Python is The Beauty, Zope2 surely is The Beast.

Zope3 is a much more gentile creature. It's availability within the bowels of modern Zope2 releases is a godsend, as any developer working with Plone3 will testify. Meanwhile, the Python community at large has rallied around the Python Package index and easy_install eggs as the primary channel for distributing code.

To leverage these new development practices, you need to be able to control your python environment. Read on to find out, why this is a problem, and what you can do about it.