make the setEntry API more intuitive

[tponthieux]

The setEntry command should take parameter that looks more like the menu option literal. Right now the command requires a parameter to identify the menu option, and then an object that somewhat resembles the menu option.

$(...).contextmenu('setEntry', 'paste', {title: 'Paste link'});

Why not put the identifier in the menu option supplement? That way it would look more like the menu option literal provided in the menu array.

$(...).contextmenu('setEntry', {cmd: 'paste', title: 'Paste link'});

If the value for cmd doesn't match anything in the menu array, it could add a new menu option.

While we're at it, why call the menu option identifier cmd? The value of cmd isn't a command, it's a string ('paste'). It should be called something that reflects its purpose as a unique identifier. How about name or id?

[mar10]

The setEntry command should take parameter that looks more like the menu option literal

Currently it takes exactly a menu option object (special case: passing a string instead, which simply replaces the title).
This means that you have to pass all properties for the new node (see #35 ).
The current syntax allows to replace an existing entry, and even change the command id.

Maybe replaceEntry would be a better name (I would then remove the special case of passing a simple string).

A function updateEntry could accept a sparse object and simply replace fields that are specified.

If the value for cmd doesn't match anything in the menu array, it could add a new menu option.

I don't think that a function called 'set...' should append new nodes under certain conditions. If this is really needed I would add an 'appendEntry' method instead. But is appending (instead of inserting) so common?

While we're at it, why call the menu option identifier cmd?

I don't think it's worth a breaking change at the moment ('menu command' or 'command id' is not an uncommon term, so 'cmd' is not too bad I guess.)
But I will re-consider it in a possible major refactoring.

[tponthieux]

I like the ideas for replaceEntry, updateEntry, and appendEntry. I don't know how common a need for appendEntry would be probably not that common. I had a use case where I needed to switch between mutually exclusive menu options, and tried to solve it by replacing the menu which is somewhat like appendEntry, but ended up using showEntry to get the behavior I wanted.

[mar10]

Not currently on my list until I
a) see some up votes by the community, or
b) get really bored

[jnbarchan]

$(...).contextmenu('setEntry', 'paste', {title: 'Paste link'});
versus
$(...).contextmenu('setEntry', {cmd: 'paste', title: 'Paste link'});

No! Existing way is right. cmd is needed to find the menu entry, it's not just some arbitrary property, and needs to be dedicated parameter. (Whether you want that syntax to rename a menu entry is a different matter.) If you allowed cmd: <same-name> in argument, I suppose that would allow design-time line to be acceptable to setEntry, maybe.

If the value for cmd doesn't match anything in the menu array, it could add a new menu option

Nope! Next?

While we're at it, why call the menu option identifier cmd?

cmd is perfect.

The only thing which does (would be nice) need doing is:

This means that you have to pass all properties for the new node (see #35 ).

:)

[mar10]

Started a branch here
https://github.com/mar10/jquery-ui-contextmenu/tree/refactor-setEntry