在做一个Eclipse RCP的项目，遇到个问题。
客户需要在一个Tree上实现popup menu，这其中的menu item根据右键点击的树节点不同而不同。用popup menu的extension很容易实现，只要加一个objectContribution就行了。根据不同的tree node类型，显示不同的action。
另一个需求很麻烦，menu item还需要根据用户所在的perspective不同而不同。objectContribution没有这么细致的声明项，似乎只有编程完成。
Popup menu actions可以实现两个接口，除了普通的声明式Action的IWorkbenchWindowActionDelegate之外，还有 IObjectActionDelegate。Addison Wesley的Eclipse RCP书中说，这个接口的setActivePart()方法在每次打开popup menu的时候都要调用，可以在这时候把不需要的Actions disable掉。试验了一下，不好使，怪？而且普通的IWorkbenchWindowActionDelegate的 selectionChanged()方法似乎也不好使。
经过对Eclipse UI源代码的挖掘，终于搞清楚了，感觉这几乎是Eclispe RCP的一个pitfall。
IActionDelegate（IWorkbenchWindowActionDelegate的父接口）的文档中说，“The workbench will generate a proxy action object on behalf of the plug-in to avoid having to activate the plug-in until the user needs it. If the action is performed the workbench will load the class that implements this interface and create what is called an action delegate object.”这话说得似乎很有道理，然而其中一个side-effect就是写在Delegate的回调方法不能轻易被调用。先要弄清楚什么是 proxy action，什么是delegate object。Proxy action是用户实际在UI中看见的传统JFace Action。比如一个menu item和toolbar上的一个按钮。Delegate Object是我们写的IActionDelegate的，实际给Declarative Action的实现。问题在这里：无论是setActivePart()，还是selectionChanged()，都是我们写在delegate object里的，而action不perform，这个object就不会被创建，当然我们的方法就不会被执行了。
看看源代码：
org.eclipse.ui.internal.PluginAction#runWithEvent()： 
if (delegate == null) {
createDelegate(); // ...
}delegate.run(this);大多数情况下是这个方法调用我们写的action delegate的。很明显，直到不得不用上我们的action delegate，框架才会去生成它。
然后看看IObjectActionDelegate的setActivePart()，当右键菜单将要弹出的时候，触发JFace的 MenuManager的menuAboutToShow事件，事件流到 org.eclipse.ui.internal.ObjectActionContributor#contributeObjectActions()， 这是我们关心的部分。这里先判断目前的选择（右键菜单的上下文）是否适合于objectContribution中声明的Object类型，将不适合的 action隐藏，然后尝试调用setActivePart()：
if (ad.getAction() instanceof ObjectPluginAction) { final ObjectPluginAction action = (ObjectPluginAction) ad.getAction();
ISafeRunnable runnable = new ISafeRunnable() {
ISafeRunnable runnable // ... public void run() throws Exception { action.setActivePart(part); action.selectionChanged(selection);
} }; SafeRunner.run(runnable);}这里头action的实际类型是org.eclipse.ui.internal.ObjectPluginAction。它的setActivePart()方法里有：
if (actionDelegate instanceof IObjectActionDelegate && activePart != null) { final IObjectActionDelegate objectActionDelegate = (IObjectActionDelegate) actionDelegate; final ISafeRunnable runnable = new ISafeRunnable() { public void run() throws Exception { objectActionDelegate.setActivePart(ObjectPluginAction.this, activePart); } // ...}成员actionDelegate就是我们写的代理action类。明显，若它是空，里面的内容，即对我们写的setActivePart()方法的调用就不能进行了，而这就是我们未触发这个action之前它的状态。
最后再看看IActionDelegate的selectionChanged()的情况。这个回调函数可以响应view内的 SelectionProvider提供的选择信息，只有当menu item是viewContributor的时候，回调函数才起作用，正常情况下，对view内的选择事件，回调函数都会被调用。
（在上面关于setActivePart()的讨论中，selectionChanged()也被调用了，但这个不算，只有右键菜单弹出的时候，selectionChanged()才会被调用，而我们要它对每次的选择，无论鼠标左键右键，都会有响应。）
首先要在当前的IWorkbrenchPageSite上注册SelectionProvider，以让我们的Provider的选择事件能影 响到我们的Action。一般常见的SelectionProvider就是JFace中的各种Viewer，在ViewPart的实现中调用：
getSite().setSelectionProvider(treeViewer);
这样我们的View就可以响应treeViewer的selection事件了。
事件从Viewer中发出，会一路走到org.eclipse.ui.internal.PluginAction（刚才的ObjectPluginAction是它的一个子类），在它的方法selectionChanged()中我们看到：
if (delegate == null && isOkToCreateDelegate()) { createDelegate();} else { refreshEnablement();}似乎若我们的代理还没创建，它会帮我们创建出来，可是且慢，方法isOkToCreateDelegate()中写道：
if (getStyle() == IAction.AS_DROP_DOWN_MENU && !WWinPluginPulldown.class.isInstance(this)) { return true;}// test if the plugin has loadedString bundleId = configElement.getNamespace();return BundleUtility.isActive(bundleId);即，若我们的Action是drop down menu item，那么会被创建，或者Action所属的插件已经加载，那么会被创建。
对于缺省的Action，这些判断不会通过。所以我们的Action仍旧没有创建。而在refreshEnablement()中，有：
空的delegate被悲惨的忽略了。
总之，对于RCP中声明的Action，要小心，我们写的回调函数并不是总能被调用的。在Action真正的被激活之前，我们的代理类（大多数情况下）并不会被主动的创建。
这个问题的解决方法实际已经有了，只要让isOkToCreateDelegate()返回true就可以让代理类被主动创建，经试验，只要声 明时将Action的Style设置成pulldown即可。这样，只要右键菜单一弹出，或者selection事件一发送，代理类就会被创建，回调总能 被调用。
Perspective?
出于对声 明式编程的偏爱，我更喜欢declarative actions。但对于客户的需求，显然用declarative actions并不合适，我们需要在每一个action的回调中判断当前的perspective，然后决定是否让它可用，这是很麻烦的编程，遵从DRY 原则，我们应该对actions直接编程。
为什么会这样？对Eclipse的偏袒让我认为这是客户需求上的问题。Eclipse的declarative actions本身是自洽的系统。一个action是否可用应该只针对它当前最小的上下文，在我们的项目里就是被选择的树节点的类型有关，而整个系统的状 态，比如当前处在哪个perspective中，不应该是action主要考虑的内容。
况且，perspective不应该作为划分任务的依据。Eclipse RCP中对于perspective的定义只是一个“屏幕页面的模板”，它记录一组缺省的view和他们的布局情况，作为方便用户的一种选择。它甚至不在 Eclipse RCP的UI组件的继承结构之内，而只是集合UI组件的一个逻辑概念。真正执行功能的基础UI元件应该是View。在Eclipse中，我们随时可以看到 IDE提示我们切换perspective，但从来不会看到某一个action只能在这个perspective中使用而不能在另一个中使用。比如说启动 了Debug功能后IDE会告诉我们切换到Debug Perspective，但“这个Perspective中的”所有View和所有功能，我们一样可以在Java视图中用，在PD视图中用，在 Resources视图中用，等等。只是Debug Perspective为我们打开了一组缺省的View和保持了一组缺省的布局而已。
为了实现对用户功能的多样化，我们应该实现多种不同的View，在不同的View上实现不同的右键菜单，如果两个View功能很重复，也应该考虑使用模块化的UI组件，而不是根据Perspective来决定同一个View的不同表现。
6874
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
