如何扩展 JDT 的特定元素的用户界面（象 Outline 视图中的成员）？扩展视图还是它们的底层模型？
简单的Hello World示例显示了添加菜单选项只需要在插件清单文件中添加几行 XML（）以及一个处理实际操作的类（comibmlabhelloworldSampleAction）向视图的下拉菜单公共编辑器的工具栏以及弹出菜单添加操作基本上很简单所提供的弹出菜单归结为两类一类只与视图相关而与所选的对象无关（也就是对视图的空白处单击鼠标右键通常会显示的缺省弹出菜单）另一类则更常见它们与应用于所选对象的选项相关在我们的例子中我们希望目标只是具体选择的对象所以通过在插件清单文件中定义一个扩展我们将提供的操作对象提供给这些对象的弹出菜单（对下面几个标识符进行了缩写以获得更佳的格式用…表示）如清单 所示
清单 修饰符操作
<extension point=orgeclipseuipopupMenus>
<objectContribution
objectClass=reIMember
id=imember>
<menu
label=Soln: Modifiers
path=groupreorganize
id=imembermodifiers>
<separator name=group/>
<separator name=group/>
</menu>
<action
label=Private
menubarPath=imembermodifiers/group
class=jdtexcerptMakeIMemberPrivateAction
id=imembermakeprivate>
</action>
<action
label=Protected
menubarPath=imembermodifiers/group
class=jdtexcerptMakeIMemberProtectedAction
id=imembermakeprotected>
</action>
all menu choices not shown
</objectContribution>
</extension>
扩展点命名为 orgeclipseuipopupMenus顾名思义它定义了向出现在工作台中的弹出菜单提供的对象这个特殊示例只提供给明确选择的对象即实现 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 模型？
如果您在前面的旅行中稍作了研究那么可能已经注意到 IMemberIJavaElement 以及我们的操作所看到的由所选的与 Java 相关的项实现的作为大部分接口的那部分都没有 setXXX 方法那么如何修改这些接口呢？
您将发现这出奇地简单不过可能在直觉上不那么明显JDT 的 Java 模型在大多数实践情况下都是只读的通过与 Java 编译器的集成协作给定元素的底层 Java 源代码进行的更改就与 Java 模型的其余部分的更改同步了实际上您要做的就是更新 Java 源代码而对模型所作的其余必要更改就传送给任何依赖它们的元素中例如每当 Java 源代码／Java 模型发生更改时JDT 的索引会自动更新所以仍旧可以快速执行搜索重新编译从属类（按照项目特性中指定的 Java 构建路径所指示的）等等
可以大松一口气了！以下就是 Java 模型是插件集成之关键的原因所在Java 模型提供了整个 Java 环境的常见的内存中共享的模型它的范围从一个项目一直到其所有被引用的库所有这些都不要您费心去操作文件系统中的 java 文件class 文件以及 jar 文件您可以将精力集中于高级模型而让 JDT 处理这其中的许多杂乱细节
还不能确信它很容易？清单 包含了这个解决方案的核心代码的一小部分它是从提供操作的 run 方法上抽取出的并出于可读性考虑稍作了简化
清单 selectionChanged 方法小型解决方案
public void selectionChanged(IAction action ISelection selection) {
IMember member = (IMember)
((IStructuredSelection) selection)getFirstElement();
ICompilationUnit cu = membergetCompilationUnit();
if (cuisWorkingCopy()) {
IBuffer buffer = cugetBuffer();
bufferreplace();
cureconcile();
}
}
似乎有点虎头蛇尾不是吗？对您提供的操作提供了选中的成员向它请求其父容器（Java class 或 java 文件的模型用 JDT 的说法全都称为编译单元）因为其父容器管理底层源代码验证该成员是否属于未提交的 Java 模型（换句话说它目前在编辑器中是打开的）然后修改作为缓沖器返回的源代码IBuffer 接口类似于 StringBuffer其原理不同之处在于更改与编译单元相关的缓沖区更新了 Java 模型的对应元素对 reconcile 的最终调用告知 JDT 去通知其它相关各方（象 Package Explorer 视图）您的模型更新已准备好作为公共消费品
您一定注意到上述代码中的省略号在那里您必须分析源代码本身以进行修改同样JDT 会提供帮助正如我们将在下一个问题中看到的
