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) _______________________________________________ Zope3-users mailing list Zope3firstname.lastname@example.org http://mail.zope.org/mailman/listinfo/zope3-users