Community
Participate
Working Groups
It should be possible to define aliases for commands to make it possible to change command ids without breaking existing code. Proposed extension syntax: <command name="Old Command" id="com.example.oldcommand"> <aliasFor commandId="com.example.newcommand"/> </command>
Created attachment 155047 [details] Command aliases implementation + tests Changelog org.eclipse.ui - appinfo -> appInfo - Added element aliasFor for command elements in org.eclipse.ui.commands org.eclipse.ui.workbench - Cleanup CommandPersistence: commandService implementation accessed via private field - CommandPersistence parses aliases and registers them with the CommandService that registers them with the CommandManager org.eclipse.core.commands - CommandManager manages command aliases via added defineAlias and resolveAlias methods org.eclipse.ui.tests - refactored assertArrayEquals / arrayToString from ThemeTest to TestUtils so it can be reused in other tests - cleanup of MenuTestCase and MenuBaseTests to use assertArrayEquals, test cases for command aliases
I'm not sure of the "what are we trying to do". I don't want to introduce an alias API if I can avoid it, and I'm not sure what behaviour we want in the system. What are we trying to do? is it: We allow the command contributor to "deprecate" a command and replace it with a new command. Everybody should be using the new command, but any incoming handler/menu contributions that reference the old ID should point to the new ID. All action definition ID references should also translate to the new ID? PW
Exactly, making it possible to deprecate an existing command in favor of a new command is what I'm trying to do. I'm not sure if the actions need to explicitly support/know about this. If you have any hints regarding to that, I'll try to add test cases for this, for now, I was only concerned about commands and actions that forward to commands.
I think there's a couple of things to consider. 1) The Command objects. Really, if you ask for the id.old.command that's the command you need to get back. When you execute id.old.command you expect id.new.command to be executed. When you ask id.old.command isEnabled() it should return the id.new.command state. Command State objects ... can they be shared by 2 command objects (these state objects are currently supported for toggle or radio state information, as well as extra text) 2) The handler objects. All handlers have to end up associated with id.new.command. 3) it's probably good to issue a deprecated log warning or tracing message if a handler or keybinding is still associated with id.old.command I'd probably tie all of the handlers and keybindings to the new command id when they are read in, and create a CommandAliasHandler that could be set on the id.old.command so that when executed it would go to the id.new.command. PW
(In reply to comment #4) > Really, if you ask for the id.old.command that's the > command you need to get back. Why is that? Imho this constraint makes this complicated to a point where the whole thing is not feasible anymore. The patch does it the other way round, it says: if you define the aliasFor element in a command element (the old command), that is not a command anymore by itself. Only its ID still works and points to the new command. Which is exactly what an "alias" means. What's wrong with this idea?
(In reply to comment #5) > (In reply to comment #4) > > Really, if you ask for the id.old.command that's the > > command you need to get back. > > Why is that? > > Imho this constraint makes this complicated to a point where the whole thing is > not feasible anymore. Welcome to the wonderful world of API :-) This is invariant: Command cmd = commandService.getCommand("my.id"); assertEquals("my.id", cmd.getId()); We can't return a different ID (in 3.x, anyway). PW
Why is this invariant? Practically, can you think of a single case where changing this in case of aliases might break client code? Formally, is it documented somewhere that you can assume that? Especially because the behaviour doesn't change for existing commands at all. Only if you convert an existing command to an alias, the behaviour changes in a very foreseeable way.
(In reply to comment #7) > Why is this invariant? It's spec'ed in the API and used in the system ... javadoc for org.eclipse.ui.commands.ICommandService.getCommand(String) PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
