How to create a toolbar menu in Plone 5

Plone Support Add-on Development
1

I want to bundle several actions for an addon in an extra toolbar menu.
What is the best practice to do this?
addon specific group in portal_actions?

2

You mean a new toolbar entry, or a totally new toolbar?

3

new toolbar entry, for example "Newsltetter" to summarize all newsletter type specific actions

4

something like; https://github.com/quintagroup/collective.easyform/blob/master/collective/easyform/profiles/default/actions.xml ?

2 Likes
5

Take a look at plone.app.contentmenu for examples::

Here is a simple example:

from plone.app.contentmenu.interfaces import IActionsMenu
from plone.app.contentmenu.interfaces import IActionsSubMenuItem
from plone.app.contentmenu.menu import BrowserMenu
from plone.app.contentmenu.menu import BrowserSubMenuItem

@implementer(IActionsSubMenuItem)
class MyGroupSubMenuItem(BrowserSubMenuItem):

    title = 'Title of menu'
    submenuId = 'my_id'

    extra = {
        'id': 'plone-mymenuid',
        'li_class': 'plonetoolbar-myclass'
    }

    order = 70

    @property
    def action(self):
        return 'url-for-action'

    def available(self):
        if checkPermission('cmf.ModifyPortalContent', self.context):
            return True
        return False

    def selected(self):
        return False


@implementer(IActionsMenu)
class MyGroupMenu(BrowserMenu):

    def getMenuItems(self, context, request):
        return [{
            'title': 'Sub menu item',
            'description': '',
            'action': 'url-to-do-something',
            'selected': False,
            'icons': None,
            'extra': {
                'id': 'some-id',
                'separator': None,
                'class': ''
            },
            'submenu': None
        }]

ZCML:

<browser:menu
    id="my_id"
    title=""
    class=".menu.MyGroupMenu"
    />
  <adapter for="* *"
           name="my_name"
           factory=".menu.MyGroupSubMenuItem"
           provides="plone.app.contentmenu.interfaces.IContentMenuItem" />
3 Likes
6

Maybe as part of this PLIP for bringing portal actions into the control panel we can think about bringing in submenus too?

@vangheem Has anyone done a plip yet to simplify the toolbar menu system? I know there was a lot of talk of wanting to rearrange it which couldn't be done due to the hack to combine the green bar tabs and dropdowns from pre 5 plone. It would be nice if we had a story which allows both plugin authors to add to the menus + site admins to modify the menus (like portal actions allowed). Anyone thought much about this yet?

7

Actually then again, do we want addon authors having full access to the toolbar?
I found it really annoying in plone 4 that addons thought it was a good idea to add a new tab for their addon specific pages. With several addons installed you ended up with no room left. Some menu items made more sense hidden under actions etc. I think we need to think carefully about what guidelines we give to add on authors and how easy we make it to add a top level toolbar item vs other options for where they can add UI elements.

8

I don't see why keep this feature hidden, the new toolbar can scroll automatically if there are too items, so I think this will not be a problem (and few add-ons add new menu or items there)

1 Like
9

cool, works!

@vangheem can you update the example?
submenuId within the class should be 'my_id' to work

10

@djay yes, we really need to re-think our menu system and unify it.

1 Like
11

Any lack of such would have led to unintended consequences: folks would invent own idioms, menus, etc (and put them in viewlets) that would make UX seem much more disjointed.

I once inherited a Plone 3/4 application in which we gradually moved away from application-specific drop-down menus in a custom viewlet toward object actions because the application's not-invented-here mentality was for the birds.

There are lots of applications where having tabs (4) / toolbar buttons (5) or action menus (in top bar or in toolbar) on a specific content context make a lot of sense (much more than grafted, homegrown non-idiomatic solutions).

As to the crowding problem, I think that is a task for an integrator or site-policy, should multiple add-ons the integrator or fit-and-finish developer selects crowd any area of the UI. And as such, I would hope that definition of actions and menus can be thought of more often in terms of configuration (e.g. actions.xml setup step solution) vs. code/plugin.

Sean

12

Sorry I should have made myself clear. Plugins seemed to prefer to make top.level green bar tabs instead of in the action menu. This led to running out of space on the green bar very quickly and an ugly cluttered ui.
To blame is likely that adding a tab was easier for plugin developers than adding to dropdowns. Or that actions didn't see appropriate and we had no common "tools" drop down that could have contained many third party plugins in a tidy way.
I agree with @seanupton that we should opt for configuration so that intgrators have control where to put plugin menu items after install.
I disagree that its OK to encourage plugin authors to create.their own top level toolbar items, or rather we should have some guidelines that discourage it. Relying on the toolbar scrolling is not nice for users. I think a "tools" menu similar to Google docs is perhaps a.good idea. I might do an audit of all the plugins I regularly use to see what menu structure would work best when all are installed.

1 Like