I'm writing this PLIP: http://plone.org/products/plone/roadmap/142.
For those of you familiar with Plone, it relates to the global contentmenu
- the green bar you see when you can edit an object in Plone, under the
content views tabs. This contains a number of drop-down menus, including
'state' (the workflow state), 'actions' (cut/copy/paste/rename) and 'add
item'. At the moment, this menu is a very large, complex, monolithic page
template with a lot of logic.
What I want to do is to use a view to construct the menu. However, I also
want to make it easier to register new top-level menus, and to override
the existing menus. Say, for example, that I install a versioning tool and
this wants to register a 'versions' menu, or a staging tool with a 'stage'
menu. Say also that in a particular folder, I wanted to override the
'actions' menu to provide some very different actions.
If possible, I'd like to re-use the IBrowserMenu machinery in
zope.app.publisher.browser. However, there are a few concerns with how
this may work. I'm hoping someone with a bit more experience can point me
at a design that will work.
1. It must be possible to add new top-level drop-downs (i.e. a menu next
to 'state' drop-down called 'versions', which has its own items).
2. It must be possible to specify how these are ordered ('versions'
always comes after 'state', but 'stages' comes before 'add item', for
3. It must be possible for the existing menus to be constructed as they
are now: the 'add item' menu uses the addable types as dictated by
portal_types, the 'actions' menu queries portal_actions for actions, etc.
4. It must be possible to override existing menus (e.g. I want to replace
the 'add item' menu with my own)
5. It must be possible to provide a given menu only for a given context
(e.g. only when the context is marked with a given interface), or for all
objects. Ideally this would be configurable, so that I could store a list
of types that get the 'versions' menu (the versionable types) and the menu
would be hidden for those types that are not on this list.
6. If a given product provides a menu or overrides a menu, that menu
shouldn't come into effect until the product is installed in the site - it
must be possible to for one Plone instance in the Zope instance to get the
menu and another to avoid it.
I took a look at the menus in zope.app.publisher.browser.menu and
menumeta, including the doctest. I'm still a bit unclear how it all works,
so I'd appreciate some specifics on whether this is possible, and if so
how to design it.
I'm guessing we could register a new IMenuType 'contentmenu', that was a
top-level menu, and then have each of the drop-downs be sub-menu-item.
Some of those would have to construct their children by looking up actions
etc, others may allow a more traditional registration. However, I'm still
unclear on issues such as ordering (I think we need to allow menus to
specfy a relative ordering, e.g. to say "I don't care where I am so long
as I'm before the 'state' menu") since they may come from different
I think we may need to use adapters to achieve the lookup only in some
contexts, but it's possible this could be a condition on the sub-menu
We may have to use local adapters/utilities to solve the installed-only
issue. In fact, this is a problem we're going to have a lot CMF/Plone
going forward, so some general patterns here would be useful.
Most of all, I hope we can solve this without re-inventing infrastructure.
Zope3-users mailing list