扩展Eclipse的Java开发工具(三) 如何扩展 JDT 的特定元素的用户界面（象 Outline 视图中的成员）？扩展视图还是它们的底层模型？ 简单的“Hello, World”示例显示了添加菜单选项只需要在插件清单文件中添加几行 XML（） 以及一个处理实际操作的类（com.ibm.lab.helloworld.SampleAction）。向视图的下拉菜单、公共编辑器的工具栏以及弹出 菜单添加操作基本上很简单。所提供的弹出菜单归结为两类：一类只与视图相关而与所选的对象无关（也就是，对视图的“空白处”单击鼠标右键通常会显示的“缺 省”弹出菜单），另一类则更常见，它们与应用于所选对象的选项相关。在我们的例子中，我们希望目标只是具体选择的对象，所以通过在插件清单文件中定义一个 扩展，我们将提供的操作对象提供给这些对象的弹出菜单（对下面几个标识符进行了缩写，以获得更佳的格式；用‘…’表示），如清单 8 所示。 清单 8. 修饰符操作

objectClass="org.eclipse.jdt.core.IMember" id="...imember"> label="Soln: Modifiers" path="group.reorganize" id="...imember.modifiers"> label="Private" menubarPath="...imember.modifiers/group1" class="...jdt.excerpt.MakeIMemberPrivateAction" id="...imember.makeprivate"> label="Protected" menubarPath="...imember.modifiers/group1" class="...jdt.excerpt.MakeIMemberProtectedAction" id="...imember.makeprotected"> ...all menu choices not shown...

扩 展点命名为 org.eclipse.ui.popupMenus，顾名思义，它定义了向出现在工作台中的弹出菜单提供的对象。这个特殊示例只提供给明确选择的对象， 即实现 IMember 接口的对象（请回忆一下 Java 语言规范中的定义，成员包含方法和字段）。我们的研究没有白费；我们得到了当前问题的答案，我们差不多准备好回答下一个问题了。 在这 样做之前，此时请注意，我们找到的用于简单“Hello, World”操作示例的模式将对所提供的其它菜单操作进行重复。即，将把选择更改告知 class 属性中指定的类（通过其 selectionChanged 方法），并还将告知它用户何时选择菜单选项（通过其 run 方法）。我们“旅行”的用户界面部分快要结束了；更困难的部分，也是影响我们所期望更改的部分还在前面。正如下一个问题所说的那样，在继续之前只要做一两 次观察。 Package Explorer 中显示的元素和其它视图（如 Outline 视图）中显示的相同元素之间有什么关系？我们的扩展是否需要知道它们之间的任何区别？ 您 可能已经注意到，当您在 Outline 视图和 Hierarchy 视图中选择了一个方法时，所选对象的类并非总是相同的。例如，如果您在 Package Explorer 中展开一个库（JAR 文件）的内容，随后选择了一个类（或方法），那么它也不会是 Java 编辑器的 Outline 视图中同一选择的那个类。到底怎么回事？ 这里，我们正在观察 JDT 的 Java 模型中“可编辑的”部分和始终为只读的部分之间的差别。这两部分 Java 模型都实现了公共接口（象 IMember），但是它们拥有用来理解底层限制的实现类是不同的。另一个示例是，有一个表示 Java 编译单元的实现类，它派生自 Package Explorer 所显示的 JAR 文件的 .class 文件，还有另一个类表示直接派生自 .java 文件的编译单元。后一个实现将允许进行一些前者所不允许的修改，而它们 API 的共享部分是由接口 ICompilationUnit 表示的。 您 以前在编辑 Java 源代码时，一定会观察到：在您输入方法特征符时 Outline 视图进行了更新（如果您没有注意到，那就试一下！）。这个示例说明了 JDT 如何在不同的区域暂放其“未提交的更改”，这与处理那些已保存、编译和集成到 Java 模型中的更改不同。有些视图（象 Java 编辑器的 Outline 视图）知道未提交的更改和已提交的更改，而其它象 Navigator 这样的视图只关心已保存到文件系统的已提交更改。 随 后，我们所提供的用来修改 Java 成员的操作必须（至少在某种程度上）知道在什么上下文中调用它。即，它必须识别出某些所选成员是可修改的（那些位于 Java 编辑器的 Outline 视图中的成员），而另一些成员是不可以修改的（存储在 JAR 文件中以及显示在 Package Explorer 中的 .class 文件中的成员）。记住这一点，让我们继续下一个问题。 如何通过编程更改 JDT 模型？ 如果您在前面的“旅行”中稍作了研究，那么可能已经注意到 IMember、IJavaElement 以及我们的操作所看到的由所选的与 Java 相关的项实现的作为大部分接口的那部分都没有 setXXX 方法。那么如何修改这些接口呢？ 您 将发现这出奇地简单，不过可能在直觉上不那么明显。JDT 的 Java 模型在大多数实践情况下都是“只读”的。通过与 Java 编译器的集成协作，给定元素的底层 Java 源代码进行的更改就与 Java 模型的其余部分的更改同步了。实际上，您要做的就是更新 Java 源代码，而对模型所作的其余必要更改就传送给任何依赖它们的元素中。例如，每当 Java 源代码／Java 模型发生更改时，JDT 的索引会自动更新，所以仍旧可以快速执行搜索，重新编译从属类（按照项目特性中指定的 Java 构建路径所指示的），等等。 可以大 松一口气了！以下就是 Java 模型是插件集成之关键的原因所在：Java 模型提供了整个 Java 环境的常见的内存中共享的模型，它的范围从一个项目，一直到其所有被引用的库，所有这些都不要您费心去操作文件系统中的 .java 文件、.class 文件以及 .jar 文件。您可以将精力集中于高级模型，而让 JDT 处理这其中的许多杂乱细节。 还不能确信它很容易？清单 9 包含了这个解决方案的核心代码的一小部分，它是从提供操作的 run 方法上抽取出的，并出于可读性考虑，稍作了简化： 清单 9. selectionChanged 方法，小型解决方案

public void selectionChanged(IAction action, ISelection selection) { IMember member = (IMember) ((IStructuredSelection) selection).getFirstElement(); ICompilationUnit cu = member.getCompilationUnit(); if (cu.isWorkingCopy()) { IBuffer buffer = cu.getBuffer(); buffer.replace(...); cu.reconcile(); } }

似 乎有点虎头蛇尾，不是吗？对您提供的操作提供了选中的成员，向它请求其父容器（Java .class 或 .java 文件的模型，用 JDT 的说法，全都称为编译单元），因为其父容器管理底层源代码，验证该成员是否属于“未提交的” Java 模型（换句话说，它目前在编辑器中是打开的），然后修改作为缓冲器返回的源代码。IBuffer 接口类似于 StringBuffer，其原理不同之处在于，更改与编译单元相关的缓冲区更新了 Java 模型的对应元素。对 reconcile 的最终调用告知 JDT 去通知其它相关各方（象 Package Explorer 视图）：您的模型更新已准备好作为公共消费品。 您一定注意到上述代码中的省略号。在那里，您必须分析源代码本身以进行修改。同样，JDT 会提供帮助，正如我们将在下一个问题中看到的。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/374079/viewspace-131457/，如需转载，请注明出处，否则将追究法律责任。