GEF入门系列(二、GEF概述).doc

GEF入门系列（二、GEF概述） 图1 基于GEF的界面设计工具（Visual Editor，VE）的工作界面 GEF最早是Eclipse的一个内部项目，后来逐渐转变为Eclipse的一个开源工具项目， Eclipse的不少其他子项目都需要它的支持。Eclipse 3.0版本花了很大功夫在从Platform中 剥离各种功能部件上，包括GEF和IDE在内的很多曾经只能在Eclipse内部使用的工具成为可以 独立使用的软件/插件包了。理论上我们是可以脱离Eclipse用GEF包构造自己的应用程序的， 但由于它们之间天然的联系，而且Eclipse确实是一个很值得支持的开发平台，所以我还是推 荐你在Eclipse中使用它。 GEF的优势是提供了标准的MVC（Model-View-Control）结构，开发人员可以利用GEF来完 成以上这些功能，而不需要自己重新设计。与其他一些MVC编辑框架相比，GEF的一个主要设 计目标是尽量减少模型和视图之间的依赖，好处是可以根据需要选择任意模型和视图的组合 ，而不必受开发框架的局限（不过实际上还是很少有脱离Draw2D的实现）。 现在来看看GEF是如何实现MVC框架的吧，在这个帖子里我们先概括介绍一下它的各个组成 部分，以后将结合例子进行更详细的说明。 图2 GEF结构图 模型：GEF的模型只与控制器打交道，而不知道任何与视图有关的东西。为了能让控制器 知道模型的变化，应该把控制器作为事件监听者注册在模型中，当模型发生变化时，就触发 相应的事件给控制器，后者负责通知各个视图进行更新。 典型的模型对象会包含PropertyChangeSupport类型的成员变量，用来维护监听器成员即 控制器；对于与其他对象具有连接关系的模型，要维护连入/连出的连接列表；如果模型对应 的节点具有大小和位置信息，还要维护它们。这些变量并不是模型本身必须的信息，维护它 们使模型变得不够清晰，但你可以通过构造一些抽象模型类（例如让所有具有连接的模型对 象继承Node类）来维持它们的可读性。 相对来讲GEF中模型是MVC中最简单的一部分。 控制器：我们知道，在MVC结构里控制器是模型与视图之间的桥梁，也是整个GEF的核心。 它不仅要监听模型的变化，当用户编辑视图时，还要把编辑结果反映到模型上。举个例子来 说，用户在数据库结构图上删除一个表时，控制器应该从模型中删除这个表对象、表中的字 段对象、以及与这些对象有关的所有连接。当然在GEF中这些操作不是由直接控制器完成的， 这个稍后就会说到。 GEF中的控制器是所谓的EditPart对象，更确切的说应该是一组EditPart对象共同组成了 GEF的控制器这部分，每一个模型对象都对应一个EditPart对象。你的应用程序中需要有一个 EditPartFactory对象负责根据给定模型对象创建对应的EditPart对象，这个工厂类将被视图 利用。 RootEditPart是一种特殊的EditPart，它和你的模型没有任何关系，它的作用是把 EditPartViewer和contents（应用程序的最上层EditPart，一般代表一块画布）联系起来， 可以把它想成是contents的容器。EditPartViewer有一个方法setRootEditPart()专门用来指 定视图对应的RooEditPart。 图3 EditPart对象 用户的编辑操作被转换为一系列请求（Request），有很多种类的请求，这些种类在GEF里 被称为角色（Role），GEF里有图形化和非图形化这两大类角色，前者比如Layout Role对应 和布局有关的的操作，后者比如Connection Role对应和连接有关的操作等等。角色这个概念 是通过编辑策略（EditPolicy）来实现的，EditPolicy的主要功能是根据请求创建相应的命 令（Command），而后者会直接操作模型对象。对每一个EditPart，你都可以安装一些 EditPolicy，用户对这个EditPart的特定操作会被交给已安装的对应EditPolicy处理。这样 做的直接好处是可以在不同EditPart之间共享一些重复操作。 在GEF SDK提供的帮助文档（GEF开发指南）里有一份详细的EditPolicy、Role和Request 类型列表，这里就不赘述了。 视图：前面说过，GEF的视图可以有很多种，GEF目前提供了图形（GraphicalViewer）和 树状（TreeViewer）这两种，前者利用Draw2D图形（IFigure）作为表现方式，多用于编辑区 域，后者则多用于实现大纲展示。视图的任务同样繁重，除了模型的显示功能以外，还要提 供编辑功能、回显（Feedback）、工具提示（ToolTip）等等。 GEF使用Edit