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