在GEF中管理Command的类.doc

GEF学习小结 1．何为GEF 首先, The Graphical Editing Framework(GEF)让我们很方便得对现有的模型进行图形界面的开发。 所有的图形的实现都是通过一个基于SWT的标准的2D的绘图框架Draw2D 来实现的。 使用GEF让你可以几乎对所有的图形模型进行编辑。有了这些编辑器，我们可以很方便得对模型进行修改（比如说修改模型的属性，一些比较复杂的操作：比如说同时通过不同的方式来修改你的模型的结构）。 所有的修改都会通过图形的拖，拽，复制，粘帖的方式来实现。也可以在工具栏和菜单项中定义动作。 通过调用GEF的API可以非常方便的完成可视化的，拖拽方式的编程工作。 Draw2D Draw2D是一个轻量级的图形系统，GEF就是靠它来显示的。它在Eclipse中是一个独立的插件在org.eclipse.draw2d包中。 Draw2D是居于SWT的轻量级的控制并管理着图形绘制和各种的鼠标事件。Draw2D是一个标准的图形库，可以用来它来完成在Eclipse中完成创建图形的工作。 Figures 在Draw2D窗口中，所有的可见的部件都是拖拽到图形上的。图形类包含了很多方法，他们提供了一下的功能： 1. 在图形中注册和取消监听器。图形会通知监听器在图形中发生的鼠标事件。 2. 改变模型视图的时间，改变图形的视觉感官，拖拽图形的位置和改变图形的大小。 3. 当鼠标移动的时候可以设定特定的指针外观。 4. 管理图层的图形位置的操作，包括添加和删除子节点或者得到它们父类的图形。 5. 设置得到FOCUS的迁移。 6. 得到图形的尺寸大小和位置。 7. 可以设置工具栏提供的功能。 2．GEF基本概念 GEF的基本创建过程：GEF是基于MVC模式的体现。 1. 模型层为自己定义的，在图形上表现出的图形。 2. 每种模型都要有自己对应的控制器类，负责对模型进行管理，在GEF中就是EditPart。 3. 创建链接模型的控制器和模型的累：在GEF中称为**EditPartFactory。 4. 最后是创建在Editor中的视图VIEW。 以上就是关于GEF的基本的MVC模式的体现。 当在模型改变时，我们需要让model对应的那个EditPart知道所作出的改变，并且要让试图做出相应的显示。这里就要需要使用Policy、Command了。 当在模型改变的时候，模型会自动产生一个请求Request (org.eclipse.gef.Request)(在这个请求中，我们能够得到模型改变的相关信息：比如说模型的位置，大小等。)然后这个请求就发送给每个模型对应的EditPart，在每个EditPart中都安装了多个Editing policy。这里的policy就是为了管理一系列的commond。这些命令就是对于相应的请求Request作出的相应的处理。 所以从模型改变到视图做出相应的请求处理应该是以下的过程： 因为模型的改变，产生了一个请求Request。 然后发送给这个模型对应的控制器（EditPart），然后由装配在这个控制器（EditPart）中的Editing policy来统一处理这些请求Request。 Editing policy中统一管理了很多的Command，Editing policy根据发送来的请求Request来具体决定由哪个Command来响应具体的一个请求Request。 然后就能够在视图上对模型做出的改变做出相应的处理了。 GEF的大概的模型—控制器—视图的关系，和其实现以及他们之间的事件触发和对应的处理机制，大体上就么上面所说的这么一个流程。 但是以上只能够通过视图上面的拖动时间改变GEF模型的属性，却不能在视图上将变化反映出来，这就好像是“所得非所见”。为了解决这个问题，加入JAVA中的属性变更的监听器：PorpertyChangeListener。在模型中的SETTER方法中将属性更改的这个变化报告给已经注册的监听器，在监听器（一般就让模型对应的EditPart成为监听器）中的propertyChange()方法中加入对事件Event的处理（一般为刷新模型，在视图上将模型重新显示一下）。 3. 在GEF中管理Command的类 另外，在GEF中有个Command Stack的概念，因为在图形操作的时候一个拖拽动作产生多个请求(Request)，也对应了多个Command去处理这些请求，处理的顺序问题也产生了，所以在GEF中用Command Stack去统一管理Command执行的先后顺序。 要管理Command的话，就需要有一个EditDomain这个类，所以一般在**Editor这个类的构造方法中就加入setEditD