[Zope3-Users] Zope 3 menus for Plone - design choices

[Martin Aspeli]

Hi guys,

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

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

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

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

Thanks!

Martin

-- 
(muted)