How to add add-on icons to additional fields that have been added to the toolbar in plone 5

Hello everyone!!

So I was working for collective.easyform add-on and I am not able to know the flow that how we add new items related to add-on in the main toobar through the code in plone5 . I need add image for the items in the tool bar but I was not able to trace the flow that how we add new items in the toolbar through .pt files ? Or there are some other way to add these items in the main toolbar ? As when I see the easy_form.pt in add-on I can't see the code which adds two items that are required for the toolbar name fields and actions ? Are there some other way to add items in toobar too as the items are there in toolbar but I am not able to trace as from where they are coming ?

Cheers,
Prakhar Joshi

Icons in the toolbar came from pure CSS (fonticons).
This discussion can help: http://stackoverflow.com/questions/35471381/how-to-provide-an-icon-for-a-dexterity-type-with-plone-5

Thanks for the link. It really gave me the idea how to create our own new css/js for add-on. I got that. But I am really not able to find out how we can add an extra item in side toolbar of plone (Not under any other item but directly listing the items in sidebar ) ?

Like we have 2 new enteries name fields and actions .

AFAIK if you want to have some new entry upon add-on installation in Actions we just create a action.xml in default profile and it update the listing while installing the add-on.

But I am really confused how we can get items like actions and fields listed upon add-on installation in side toolbar.

Please do correct me I am getting something wrong. Its first time I am working on these things.

Cheers,

See How to create a toolbar menu in Plone 5

IIRC, in PloneFormGen this was done by creating a lot of contained content types that fit the standard Plone mechanism for adding new content to a container.

That was clever, but has some issues; the most irritating is having to see all those content types listed all over the place where they are completely useless.

Seems you're experimenting with a new way of accomplishing this… be careful: you already have the Actions menu item repeated in the toolbar.

So in easyforms I can't see Actions menu repeated in toolbar ? Also I am trying to remove the actions and fields item from toolbar and will put them under Actions of toolbar.

I think what @hvelarde is saying that use of the word "actions" in the toolbar context is confusing since there is a standard actions menu already for rename, copy etc.

Is the menu to give quick access to edit existing fields/form actions etc? Personally I think trying to use dropdowns to give a list of form actions and fields might be a mistake. It would be very easy for a longish form to have that menu go off the page. You would be better off with a single menu item to edit, and then have the list on screen. or render some small link next to each field saying "edit". links to editing actions would be done next to the submit button.

Hi, I went through the link and follow the discussion but in easyform I can't see the use of plone.app.contentmenu.interfaces for creating items in toobar ? Can you help me here how these items are created in toobar in easyform. And yes I agree that we need to improve the way these actions have been placed directly in the toolbar. First I am not able to figure out how these things are places at first in that place.

While going through code I cam to know about how new items are placed in standard actions menu already for rename, copy. I have found that here . But still I am stuck to find how then other actions and fields items are placed there in toolbar ?

Cheers

Without looking at the code: Is it a viewlet? The toolbar is a viewlet manager, so if its not placed in the default menu viewlet, it is probably an own viewlet.
Just a wild guess...

Yeah finally I figured out where these actions and fields are configured in easyforms, they are configured here I think they are listed there as actions only. I have moved them in standard actions menu which already contains import and export for easyforms. I did that because this will make the toolbar consistent across the site and all the additional content will be in the main Actions tab for easyforms.

@djay I guess this will be better way as this will help us in keeping the toobar consistent and clear . So I moved them under the main actions tab of toolbar.

1 Like

@pjoshi_ From a UX perspective its perhaps not that clear. I'm guessing that "fields" and "actions" lead to views to edit the those things. Actions is a menu meant to do things to the object as a whole, which is why import/export do make sense there. in addition Actions > Actions is going to be confusing. I don't think users are going to think to look under actions for shortcuts to configuring subitems.

I can see that its a tough one as plone doesn't provide a menu which is an obviously the right place for such shortcuts. It only provides contents and edit. Edit would be the most obvious place but unfortunately that can't be made to have a submenu.

I would create a new toolbar dropdown menu either called "Config", "Settings" or "EasyForm".

1 Like

@pjoshi_ Actually better than a new menu item, would be have a better edit view. The problem here is that people tend to be rely on DX to provide a UI which means that there are subobjects and lots of clicking and going to contents to get at things. A menu to shortcut to get at subitems is just a crutch to get around the bigger issue. If someone wants to edit a field they are editing a form. They would expect to click edit and be able to edit all aspects of the form quickly from there. My advise would be to redesign the edit view to be custom so you can let the user edit whatever they want and stop relying on default DX views.

Plomino faces a very similar problem and that is the solution they are now implementing - https://github.com/plomino/Plomino/issues/705

1 Like

@djay: fields and actions are indeed views and they display the same ploneschema.editor UI used in Site Setup > Dexterity > Fields. Besides in EasyForm there are no subobjects, like in PFG or Plomino.

From P4 to 5 we lost visual semantics in the toolbar. We had left floated items for views and right ones for operating actions on current context. Now there's not even a divider for that, it's all the same. Also left items were tabs, which reinforced the concept of views/aspects, and right items were all dropdowns, so we used to have a more cohesive and differentiated vocabulary. We have to improve that, PLIP it, user test it, sprint it etc.

As you mentioned in another thread we shouldn't allow scrolling in the toolbar, neither give the opportunity for integrators/add-on makers to overpopulate it or make things confuse. The "Google Docs Tools menu" solution you suggested seems appropriate in that direction, we could add a Tools button to hold addon specific views. Still it needs testing to see if it stands with a real bunch of addons.

For EasyForm however I think using existing Actions menu works well enough. We do want to operate actions on the forms, so maybe it wouldn't be as confusing if we just rename them to: "Actions > Define fields" and "Actions > Define form actions". Note the term "action" replaces PFG's "adapters", so now we have less jargon and a more intuitive and form related term. I don't think that's needed but we can look for another term (e.g. handlers) if it's still too repetitive. The downside here is those links won't be visible at first sight, as was the case in P4. But if we do agree scrolling is terrible we should probably forget that, be them inside the Actions or new Tools toolbar button.

Finally I didn't try Plomino recently but I'm not sure everything should be inside EDIT button just because "what you're actually doing is editing". Users have different edit stories and it's quite useful to detach more oftenly used, or simply task-specific, "schemas" and give direct access to them. Specifically in EasyForm there are already many custom fields and fieldsets (Default, Overrides, Thanks page beyond native Settings / Categorization / Dates / Ownership) so if we open plone.schemaeditor in another yet tab (actually 2 tabs) things are going to get heavy imo. I'd really prefer not to have the opportunity to unset core form settings like form methods, ssl, csrf protection, fieldsets into tabs, overrides, thanks page etc, everytime I want to make an adjustment to a field or action/adapter/handler.

I think the most preferable (from the user perspective, nothing to with how possible)

  1. Make the edit button a drop down (if a plugin wants it). Change it to have "edit > form", "edit > fields", "edit > actions". I think p5 having this as an option for any plugin would be nice. It's more user friendly than a "tools" menu. Edit I'm guessing is where they would first think to look. The downside is that if 90% of the time the user wants to edit the form, not the fields or actions, then there is an extra click. Keyboard shortcut might mitigate that.
  2. Have links to alternative edit views on your edit form view. It wouldn't be as heavy as having it all load in tabs. It would be more clicks but at least it's where the user expects it.
  3. A new generic dropdown called "config". Not a great option since when does a user want to edit vs config? But at least its more obvious than going to "actions" to edit/add something.
  4. The "actions > define fields" option you mention. At least its out of the way like you said. Not very obvious but some documentation would get around that.

BTW, the other consideration with coming up with a pattern for custom menus is folder contents. There space is also very cramped but we want a way for any plugin to add in menus there too. I think making "edit" a drop down works nicely for folder contents too.

I've created an place holder issue for ideas on how to solve this. https://github.com/plone/Products.CMFPlone/issues/1641