Dynamic Context Menu

[tdakanalis]

Define the nodes with a context menu and the actions that are permitted for each node by defining the 'context' option in the editor's options.

For example the options below define that only node1, node2, and all the children of node3 and node4 will have a context menu. Moreover, node1 and node2 allow only the 'Remove' action while the children of node3 and node4 allow both the 'Duplicate' and 'Remove' actions:

context: {
    items: { 
        node1: ['Remove'], 
        node2: ['Remove'] 
    }, 
    children: { 
        node3: ['Duplicate', 'Remove'], 
        node4: ['Duplicate', 'Remove'] 
    } 
}

[josdejong]

Thanks Themistoklis. This looks interesting.

Some thoughts:

• It may be a good idea to look a bit broader. There is a long standing feature request to allow for custom entries in the context menu, see Custom items in contextual menu #75. Maybe we can pick this up together with restricting the allowed actions in the context menu.

• There are shortcuts to create/duplicate/remove entries. I guess we should disable these too to truly restrict options.

• The current configuration where you can enter "items" and "children" may be a bit restrictive. Does "children" hold only for direct children or also recursively for nested children (grandchildren)?
  It can be interesting to look into how JSONEditor currently allows to configure editability of fields and values, and use a similar solution to allow/restrict actions on nodes by providing a callback function:

  {function} onEditable
  Set a callback function to determine whether individual nodes are editable or read-only. Only applicable when option mode is tree. The callback is invoked as editable(node), where node is an object {field: string, value: string, path: string[]}. The function must either return a boolean value to set both the nodes field and value editable or read-only, or return an object {field: boolean, value: boolean}.

  Maybe we could reuse the existing onEditable and extend it with options to return "actionable" properties as well as "editable" properties. Or maybe we should make a new option onActionable or something like that.

[tdakanalis]

Yes, definitely a completely dynamic context menu would be much more useful! We can proceed the way you suggest! I prefer we to introduce a new option, instead of using the onEditable, in order to keep it clear.

[josdejong]

Agree

[dhughes-xumak]

#438 adds support for custom context menu items.