Eclipse RCP:操作 VS 命令

Eclipse RCP 上下文中的操作和命令有什么区别?我知道它们都对菜单条目做出了贡献，但哪个更好?为什么?

在我阅读的所有在线资源中，我无法准确理解两者之间的差异.我实际上并没有尝试使用它们，只是想从更高层次的角度了解它们.

谢谢

解决方案

你读过 eclipse wiki 详细说明差异

操作:

• UI 和处理始终是相关联的.没有办法彼此分开
• 虽然动作可以贡献给工作台的不同部分(弹出菜单/工具栏)，但它们都是不同的扩展点，因此您最终会在多个位置复制 XML.最糟糕的是，并非所有扩展点都需要相同的配置.
• 在多个地方指定操作是维护的噩梦.如果你必须改变一个动作的图标，你需要改变所有的地方.
• 在 plugin.xml 中复制 Actions 的另一个问题是将在内存中创建相同 Actions 的多个实例.

命令涉及更多的扩展点，但是:

• 处理程序可以与命令分开声明.这样可以为同一命令声明多个处理程序.
• 对所有处理程序的 activeWhen 进行评估，并选择对最具体的条件返回 true 的处理程序.所有这些事情都 完成，甚至无需将处理程序加载到内存中.即使没有加载您的插件！
• 定义参数就是返回一个显示名称的映射 &身份证.名称将显示在键绑定页面中，并且 id 将用于在按下键序列时调用命令.
• 定义一个 IExecutionListener，它只是命令执行的观察者，因此它既不能否决它也不能对事件进行任何更改

What are differences between Actions and Commands in the context of Eclipse RCP? I know that they both contribute to the menu entries, but which one is better? And why?

Of all the online resources I read, I could not get a firm understanding of the differences between both. I have not actually tried to use them, but just wanted to understand them to start with from higher level point of view.

Thanks

解决方案

Did you read the eclipse wiki FAQ What is the difference between a command and an action?

You probably already understand that Actions and Commands basically do the same thing: They cause a certain piece of code to be executed. They are triggered, mainly, from artificats within the user interface

The main concern with Actions is that the manifestation and the code is all stored in the Action.
Although there is some separation in Action Delegates, they are still connected to the underlying action. Selection events are passed to Actions so that they can change their enabled state (programmatically) based on the current selection. This is not very elegant. Also to place an action on a certain workbench part you have to use several extension points.

Commands pretty much solve all these issues. The basic idea is that the Command is just the abstract idea of some code to be executed. The actual handling of the code is done by, well, handlers. Handlers are activated by a certain state of the workbench. This state is queried by the platform core expressions. This means that we only need one global Save command which behaves differently based on which handler is currently active.

This article details the differences

Actions:

• The UI and handling are always tied. There is no way you can separate each other
• While Actions can be contributed to different parts of the workbench (popup menu/tool bar), all of them were different extension points and so you end up duplicating the XML in multiple places. The worst of it is that not all the extension points expect the same configuration.
• Specifying Actions in multiple places is a maintenance nightmare. If you have to change the icon of an action, you need to change in all the places.
• Another issue with duplicating Actions in plugin.xml is that multiple instance of the same Actions will be created in the memory.

Commands involve more extension points, but:

• Handler can be declared separately from a Command. This enables for multiple handler declarations for the same command.
• The activeWhen for all the handlers are evaluated and the one that returns true for the most specific condition is selected. All these things are done without even loading your handler in the memory. Even without loading your plugin!
• Defining the parameters is all about returning a map of display names & the ids. The name would be displayed in the key bindings page and the id would be used to invoke the command when the key sequence is pressed.
• Define an IExecutionListener, which is merely an observer of the command execution so it can neither veto on it nor make any changes to the event