GEF七天之第一天
首先,demo要求:
一个eclipse plug-in程序，要有一个编辑区（editor），一个大纲（outline）.编辑区有画板，画板里有三角，矩形，圆形，连接线。用户可以通过拖拽的方式把图形拽到编辑区。编辑区图形能够实现删除，同时拥有uodo/redo。
看似简单的要求....
好了那我们首先就开始吧,对了还是先介绍一下GEF这个架构吧
GEF（Graphical Editor Framework）是一个图形化编辑框架，它允许开发人员以图形化的方式展示和编辑模型，从而提升用户体验。这样的应用程序有很多，例如：UML类图编辑器、图形化XML编辑器、界面设计工具以及图形化数据库结构设计工具等等.这是引用八进制老兄的话.对了貌似struts那个编辑器,就是能拖能拽的那个,就是用的这个框架.
他采用MVC框架模式实现，模型对应业务逻辑，实现相应的接口，并添加事件监听器，实现对模型改变事件的监听。控制器由GEF提供的EditPart实现，安装编辑策略，监听模型的变化，处理模型变化请求，执行相应的Command命令完成相应的操作，绘制图形。视图部分由Eclipse提供的Draw2d实现，绘制相应的图形。我们也从这三个方面来说明程序的设计实现.
什么是Draw2d,我们只说GEF,Draw2d的相关知识,还是去找google,百度吧.当然了同时我们还要有Eclipse插件开发的相关知识.就这两样我还是看了将近一天呢.
现在我们在具体说一下GEF的大致工作原理:一下内容引自(八进制老兄的博客)
图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使用EditPartViewer作为视图，它的作用和JFace中的Viewer十分类似，而EditPart就相当于是它的ContentProvider和LabelProvider，通过setContents()方法来指定。我们经常使用的Editor是一个GraphicalEditorWithPalette（GEF提供的Editor，是EditorPart的子类，具有图形化编辑区域和一个工具条），这个Editor使用GraphicalEditViewer和PaletteViewer这两个视图类，PaletteViewer也是GraphicalEditViewer的子类。开发人员要在configureGraphicalViewer()和initializeGraphicalViewer()这两个方法里对EditPartViewer进行定制，包括指定它的contents和EditPartFactory等等。
EditPartViewer同时也是ISelectionProvider，这样当用户在编辑区域做选择操作时，注册的SelectionChangeListener就可以收到选择事件。EditPartViewer会维护各个EditPart的选中状态，如果没有被选中的EditPart，则缺省选中的是作为contents的EditPart。
初步了解了GEF的MVC实现方式，让我们看看典型的GEF应用程序是什么样子的。大部分GEF应用程序都实现为Eclipse的Editor，也就是说整个编辑区域是放置在一个Editor里的。所以典型的GEF应用程序具有一个图形编辑区域包含在一个Editor（例如GraphicalEditorWithPalette）里，可能有一个大纲视图和一个属性页，一个用于创建EditPart实例的EditPartFactory，一些表示业务的模型对象，与模型对象对应的一些EditPart，每个EditPart对应一个IFigure的子类对象显示给用户，一些EditPolicy对象，以及一些Command对象。
GEF应用程序的工作方式如下： EditPartViewer接受用户的操作，例如节点的选择、新增或删除等等，每个节点都对应一个EditPart对象，这个对象有一组按操作Role分开的EditPolicy，每个EditPolicy会对应一些Command对象，Command最终对模型进行直接修改。用户的操作转换为Request分配给适当的EditPolicy，由后者创建适当的Command来修改模型，这些Command会保留在EditDomain（专门用于维护EditPartViewer、Command等信息的对象，一般每个Editor对应唯一一个该对象）的命令堆栈里，用于实现撤消/重做功能。
引用完毕.
了解了其基本原理后我们就可以开始开发了(呵呵,省去n多小示例的开发)....
ps:我会把这一周的收获一一写来.呵呵....
