EMF介绍系列（七、.Edit初步）

EMF除了生成模型部分的接口和实现类（不妨称作“核心模型”）以外，还生成一个名称以.Edit结尾的项目，包含一些与核心模型和编辑器关系都十 分紧密的代码。这部分代码经过了精心设计，可重用的程度是相当的高。它们不仅在EMF生成的编辑器项目里大量被用到，我们自己在扩展编辑器的时候也应该充 分利用。

在线商店的例子里，com.my.shop.edit项目里包含一个ItemProviderAdapterFactory类和一组 ItemProviderAdapter的子类，后者是和核心模型的接口一一对应的，例如核心模型的Shop、Category和Product分别对应 ShopItemProvider、CategoryItemProvider和ProductItemProvider。这篇帖子主要介绍一下这些 ItemProvider，而关于ItemProviderAdapterFactory的内容将在以后的帖子里专门介绍，其实顾名思义， ItemProviderAdapterFactory的作用主要就是生成ItemProvider。事实上在构造EMF应用程序时，我们经常要修改 ItemProvider里的代码，而ItemProviderAdapterFactory则很少改动。

图1 EMF生成的.Edit项目

注意：.Edit项目里ItemProviderAdapter的子类名称里省略了Adapter这个单词，例如 CategoryItemProvider而非CategoryItemProviderAdapter，你心里应该清楚它是一个Adapter，因为它 确实实现了Adapter接口。EMF里另外专门有一个ItemProvider类是为非Adapter类型准备的，在这篇里说的 ItemProvider不是指它，而是指XXXItemProvider，也就是ItemProviderAdapter的子类。

注意：EMF里的Adapter接口和Eclipse Runtime的IAdaptable接口虽然名称相似，但并不是同一个概念（关于IAdaptable请参见前面的翻译帖子）， EMF里的Adapter等同于监听器（Listener、Observer）的作用，它监听的对象是EMF的Notifier，在一个Notifier 上可以注册多个Adapter。另一方面，ItemProviderAdapterFactory则很像IAdaptable，它们都能够起到动态转换类 型的作用，只不过前者一般只用于Notifier到Adapter的转换，后者则没有什么限制，此外转换方法的名称也不同，前者是adapt()，后者为 getAdapter()。

从图1中不难看出，ItemProvider构成了.Edit项目的主要部分，这些ItemProvider具有以下几个作用。

一、实现了JFace中ContentProvider和LabelProvider的功能

以TreeViewer的ContentProvider为例，在JFace里应该实现ITreeContentProvider接口，这个接口定 义了getParent()、hasChildren()和getChildren()这三个方法；在EMF里有 ITreeItemContentProvider接口与之对应，这个接口同样具有这三个方法，.Edit部分的每个ItemProvider都实现了这 个接口，因为EMF已经完全知道我们的模型结构，所以这三个方法在ItemProviderAdapter类里已经实现好了。不过 ITreeItemContentProvider毕竟不能直接交给JFace的TreeViewer来使用，所以EMF提供了一个 AdapterFactoryContentProvider来做适配工作，你可以在编辑器的代码里看到如何使用它。

LabelProvider也是类似的，它主要控制显示的文字和图标。EMF生成的ItemProvider缺省没有实现 ITableItemLabelProvider，所以如果要使用TableViewer，要修改代码以实现 ITableItemLabelProvider接口和额外的方法，具体请参考在线商店例子中的ProductItemProvider。从 JFace的角度来说，ItemProvider相当于集成了各种查看器的ContentProvider和LabelProvider的代码，是一个通 用的“ContentLabelProvider”。因此利用它，开发人员在改变查看器的时候只需要修改很少的代码，而不像传统方式那样每换一个查看器还 要写新的ContentProvider和LabelProvider。

二、提供了关联对象的属性表

每个ItemProvider的getPropertyDescriptors()方法返回在属性视图里显示的属性列表，列表里的每个元素是一个 ItemPropertyDescriptor对象，它决定了每个属性的标签、描述、图标以及是否可编辑。EMF为生成的代码会帮我们把模型定义里的每个 属性都显示在属性列表里，如果希望隐藏某些属性，可以通过修改这个方法移除之。

以Product为例，ProductItemProvider的getPropertyDescriptors()方法里包含这样六条语句，分别代表产品名称、价格、描述、是否有货、评价以及颜色这六个属性，如果你想让颜色属性在属性列表里消失，只要删除最后一句即可。

三、生成编辑模型的各种命令

在ItemProviderAdapter基类里有很多createXXXCommand()方法，如果你用过GEF应该对这些名称不陌生，因为在 EditPolicy里也有类似的方法。我们知道，为了实现Undo/Redo功能，对模型的每个改变都应该使用Command实现，然后把 Command保存在Command栈里，每个Command对象保存Undo/Redo自己的信息。ItemProviderAdapter相当于一个 生产这些Command的工厂，用户对模型编辑的请求都将通过它转换为对应的Command，例如用户在属性视图里修改了一个属性的值，当按下回车后，会 调用该对象关联的ItemProvider类的createSetCommand()方法生成一个SetCommand对象。

注意：在createCommand()方法里会调用getChildrenFeatures()方法，而在实现ContentProvider的getChildren()时也需要这个方法，因此这个方法的返回结果同时影响ItemProvider的这两项功能。

四、将模型的改变通知到负责显示模型的视图

在一个Eclipse应用程序里经常会有很多个查看器显示模型，无论用户怎样修改模型，要让这些查看器里显示的内容总是当前的模型，最好的办法是让查看器能够响应模型的变化。ItemProvider作为监听器可以很好的完成这个任务。

模型发生改变时，与被修改的对象相关联的ItemProvider的notifyChanged()方法被调用，事件立即被通知给 ItemProviderAdapterFactory，后者是整个模型的事件处理机构，所有的ItemProvider都是通过 ItemProviderAdapterFactory创建并注册为监听器的，因此ItemProviderAdapterFactory可以把事件通过 fireNotifyChanged()通知给所有这些监听器的notifyChanged()方法去消化。图2展示了这个通知过程，此图来自 《Eclipse Modeling Framework: A Developer's Guide》第3.2.4节中的图3.10。

图2 ItemProvider的通知流程

最后，ItemProvider还有一个collectNewChildDescriptors()方法，这个方法决定了在编辑器里，模型里对应的 那个对象可以创建哪些子元素。例如在线商店模型里，Category对象的子元素是Category和Product，那么用户在编辑器里右键点击一个 Category对象选择“New Child”时，就会出现“Category”和“Product”这两个选项。有些场合我们想隐藏其中一些选项时，就可以修改这里的代码。

本文转自博客园八进制的博客，原文链接：EMF介绍系列（七、.Edit初步），如需转载请自行联系原博主。