Componentising the content menu

I have an unstated personal vendetta for Plone 3.0 - make the UI more pluggable. There are a few places where people are forced to do very invasive template overrides because Plone doesn't provide any proper way for them to plug in the UI they want. This in turn makes us dependent upon having certain types of customisations in CMFPlone proper, rather than letting them be managed by add-on components. discouraging certain type of innovation in the wider community.

A big part of that will be viewlets - a way of composing snippets into a full page. Alec Mitchell did a ton of great work on making these work in Five, and I'm sure their impact will be felt in very positive way for Plone 3.0.

The other one is metadata - how many people would like to be able to apply a standard (perhaps required) field to every content type without having to sub-class every single one of them? At least for Archetypes, a solution is within reach, thanks to some great work by David 'whit' Morriss, which I adapted and used here. Daniel Nouri, the new Archetypes release manager, is interested in this as well, so with a bit of luck and work, we'll get that one done in time.

The last bit is a template with which I'm rather too familiar - global_contentmenu. This is the code that controls the green bar with the actions, display, add item and state menus.

Take a look at the code. This is a prime example of the stuff you should not do with ZPTs. There is more logic in there than in pretty much any other page template, it's brittle, it's completely untested, and it's hard to maintain. But more than that, if you want to add a new menu or change one of the existing ones, you have to override the entire template. LinguaPlone does this to get a translate menu. BernArticle does it, apparently, for who-knows-what reason. CompositePack apparently uses JavaScript DOM manipulation to get another item in there. Nice.

Now look at the bundle for PLIP142. This does a number of interesting things:

• The menu is rendered as a content provider (the Zope 3 component that underpins viewlets) by means of a 'provider:' expression at the bottom of global_contentviews.
• This invokes a view component that prepares a ZPT-friendly structure.
• The rendering of this data structure is now sane. Compare this template with the old global_contentmenu.
• All the logic is implemented in Zope 3 components. These can be tested! There are now 50-odd tests covering the logic that used to be in one template (scary...)

The components in this case use the Browser Menu infrastructure. This consists of one menu called plone.contentmenu which represents the horisontal bar. This has a number of menu sub-menu items representing each of the actions, display, add (aka factories) and workflow menus. Each of the sub-menu items in turn points to another menu that fetches the items to display in the drop-down. All of this is registered in ZCML.

Notice how the sub-menu items are implemented as adapters. This is because they need additional logic beyond what the standard Zope 3 subMenuItem ZCML directive can provide (and also because that directive doesn't seem to work in Five, at least it didn't in Zope 2.9). The implementations are found in menu.py.

It is possible to register your own menus or override existing menus simply by registering new components in any package. For example, you could:

• Override the entire menu by providing a more specific adapter or an override for the plone.contentmenu content provider. See the bottom of configure.zcml and the adapts() specification for ContentMenuProvider - anything more specific than Interface could cause a different renderer altogether to be invoked.
• Override a specific sub-menu item. Again, a more specific adapter registration could override the sub-menu items. The default items are simply registered for all content types, but you could choose to have a specific implementation of one of the menus for a specific content type.
• Add a new sub-menu, either for all contexts or just those providing a given interface. Notice how the sub-menu item implementations all have an order attribute, and that they are ordered with gaps - 10, 20, 30, 40. Add a new sub-menu item and register it as providing IContentMenuItem with an order between any of those numbers, and you can control whether it appears before or after all the existing menus, or in-between two of them.

The work is not quite finished, and there will be a lot of testing to be done, but already the bundle functions for the majority of use cases. Specifically, what remains is:

• Make the JavaScript warning on the Delete action work
• Fix line breaks in the Display menu
• Ensure the selected item in the Display menu is properly marked as such
• Test with non-structural folders, folders with a single addable type, and with various combinations of permissions and roles to ensure the new menu behaves like the current one does.
  

We also need to decide whether existing customisations of global_contentmenu should be allowed to override the default or whether we break all of them. Alec nearly has me convinced that breaking existing customisations is the right thing to do, since any customised version would break any other product that used the "new style" customisation techniques outlined above, and since the existing template is just scary.

However, pending framework team review, I hope to see this in Plone 3.0. I'll miss having days like these trying to figure out how to make the Display menu work under various conditions with some serious TAL voodoo, though...