GEF源码分析（六） GEF 的EditPart的职能分离 __ 跨国时尚媒体集团广告部门 的故事 二

GraphicalEditPart先生当天安排了部门及会议计划。经过EditPart部门紧张有奏的准备会议讨论的资料，第三天、按时8:30开会。

GraphicalEditPart先生还如往常，准时提前5分钟坐在会议室前边角上。他喜欢部门的小伙子们，虽然这些小伙子们做事情时常有些不周，但是他更欣赏他们的活力和富有创造激情。所以、每每开会时，他更愿坐在旁边听这些小伙子们的意见，“相比较当个威武的军队长官，我更意是一个严格又和蔼的优秀教练”GraphicalEditPart先生常常如此提醒自己不要越俎代庖。

部门干将小李主持会议，简短阐明会议主题和要求后，（为了提高会议效率会议每人最多5分钟发言，最后20分钟讨论时间，5分钟GraphicalEditPart先生做总结）。

小王首先站起发言：“目前我们EditPart部门，虽然，主要任务有明确定义，但是内部的工作流程不明确，没有可依章程。...”。

“是呀，公司目前还没有我们部门的标准操作手册，很多问题都有很大随机性，工作的好坏过于依赖人员本身的工作能力，这十分不利于人员的内部流动以及新人员的补充”我们的GraphicalEditPart"教练"满意的点点头。

小魏起来补充一下：“由于我们内部每个人的做事方法，都是各有一套绝活，流程不一致，经常导致在工作对上下层通知协作出现问题。在水平部门沟通时，也常常不流畅”。这是个大学刚毕业十分活泼的小姑娘。

“为什么大家总是觉得女的职员不好，看多有灵气的一个小姑娘呀，又是个好苗子。”GraphicalEditPart"教练"此时内心中的自我形象简直就是华佗再世，那感觉真有点飘飘然乎，GraphicalEditPart先生不由自主地晃了晃脑袋。

接下来其它人纷纷发言：

“工作经验很难相互交流，积累与提高。很难在部门级对工作流程等进行优化，缺乏专业化。”

“我们经常要和Figure部门一起工作，跟踪操作执行。这很是浪费工作时间，尤其是当某个工作需要很长时间，或者中间经常需要和客户交流反馈一段时间，这样非常影响工作效率。”

“对于客户的问题很难快速根据现有的经验模式形成解决方案，虽然我们公司服务态度和广告质量高于其它公司，但是经常由于反应速度太慢，活被其它公司从中抢了去，销售部门常常抱怨我们部门速度太慢。”

“公司在相应客户需要操作过程中，很难针对客户某个需求重新调整。客户常常抱怨在制作过程中很难做些小的改动。”

……

由于GraphicalEditPart先生管理小师的带领，EditPart部门的会议总是简短有效。1个小时多几分钟大家都把问题简明扼要的表达出来。

小李环顾下四周“最后，由GraphicalEditPart部长总结一下今天的会议”。

一直沉默的GraphicalEditPart先生站了起来，十分精神，也环顾了一下四周，清了清嗓子。

“首先、我要自我检讨一下，这一年多总是忙乱于紧急的小事情当中，很久没有收集大家的建议和反馈了，这十分不利于我们部门的发展。今天大家举出很多目前部门的问题，这些充分反映了大家对部门的业务熟悉程度，我相信，这是因为大家十分关注公司的未来，希望公司越办越好，而不是怨天尤人的牢骚，可能有些领导会觉的这是找毛病对领导不满，在我这里，我今天在一次明确表明，我十方鼓励大家，欢迎大家将一些意见反馈给我，希望大家不仅仅是简单反馈在工作中的直接困难，而且经过自己的思考提炼写成简洁的文书给我，最好发挥自我主动和创造性提出一些变革建议。这些东西将是我们部门及公司潜在的珍贵的财富，同时也是我们部门未来发展方向的一个重要部分。”

“今天的会议大家主要是针对我们部门的问题，希望会后大家再从公司整体考虑这些问题，以及未来扩充EditPart部门会带来什么问题，比如大家可以参考我们当初成立时遇到那些问题，这些问题将来如何避免或减少。”

“按计划，会后，小李，小孙，小丁，小黄还有我，将总结今天会议，同时、制定出未来部门组织变革的策略。在此期间，希望大家踊跃的将自己的想法创意于我们交流。”

“还有一件事情，今天要批评一下小丁同事，现在开会不迟到了，但是，不仅没发言、我看你从开会就一直看前天发的材料，为什么不提前准备，这是耽误大家每个人的时间，下不为例。今后、小李你在部门规章里加一条，部门开会前必须提前阅读理解会议材料，凡违反者，包括我在内一律站到会议室角落站着阅读完资料后，在回会议座位。我的话完了。”

小丁满脸通红，不由地低着头，双手捂住了腮帮，不敢喘气了，恨不得有个地缝钻进去。

“今天会议结束。”小李宣布。

会后根据小孙的会议记录，很快的小李几个人总结出以下的一个鱼骨图。

什么是因果图？

因果图的发明者 Kaoru Ishikawa 是一名管理专家，其最初的目的是改进车间的质量控制工作。正如以下示例所示，因果图还能表达其他环境中的因果关系。

 

由于因果图的形状很像鱼的骨架，所以它又称作鱼骨图。鱼的脊骨上几根最大的鱼骨表示主要的原因类别。
例如，在本例中，主要的原因类别有盎格鲁人/朱特人、丹麦人、萨克逊人和诺曼底人，这些种族群体都想控制英格兰，从而导致了该战争的爆发。

主要类别中的较小鱼骨表示主要的原因。例如，在本例中，在萨克逊人这个类别方面，黑斯廷斯战争的主要原因在于公元 1051 年萨克逊王爱德华许诺将王位传给威廉一世。

您还可以在主要原因上添加次要原因。

已存在一个三角图形EditPart，我们想重用它,但是我们还需要增加（或删去）边框可调整的特性，如何保证无需重新建立一个新的EditPart，或者做出丑陋的继承，当功能不断组合后，出现无数子EditPart类?

如何由框架自动完成Undo及Redo功能？

话说在某个跨国时尚媒体集团中国区广告部门（这是一家主营平面广告的广告公司，听说董事长是个年仅办百的老头GraphicalEditor先生，来自赫赫有名的eclipse基金财团），有目前主要有两个子部门EditPart(广告策划部)和Figuer(平面设计部)。

EditPart部长是一位中年充满信心和活力GraphicalEditPart先生。

Figuer部长是一位与部门名同名的广告主设计师美丽青春的Figure小姐。

EditPart部长GraphicalEditPart目前主要肩负着三项任何：

• 处理由其他部门中的Model人员送来各销售部门广告需求；
• 做出具体的平面设计策划交给Figure小姐，由Figure小姐负责画出充满激情的平面广告；
• 读阅客户要求与反馈的Request文书，这些文书是由Tool（情报收集部门）收集客户的反馈及要求，经过专业的整理与分类而成（上篇我们以及探讨过了）

 

由于公司扩大了业务，投入市场的产品种类比以往增加了三倍，EditPart部长工作变得异常繁忙有些快压垮了，感觉自己快成为整日驮着重物年迈的驴子，“是不是自己老了”GraphicalEditPart先生开始常常怀疑自己了。

这天，EditPart部长收到总部一封信：

 

GraphicalEditPart先生：

     首先我代表公司感谢您这些年勤奋出色的工作。我们公司在中国短短三年的营业额增长了四倍，同时EditPart中国部门在此期间获得了公司最有活力部门奖，这些成绩都与您的努力是分不开的。据我们了解，您在EditPart部门这三年中，实施了几项富有创意的制度改革，如成立Tool情报收集部门，推广后大大提高了整个公司EditPart部门业务处理能力。为了进一步扩大业务，公司在未来的两年里将在世界各地尤其是中国增加40%的区域广告部门，正如您所知道目前公司对于EditPart部门的组织规划以及责任制度还有很多不完善之处，这将十分不利于区域部门扩展的计划。故我委托您做出《未来广告部组织的规划》计划书，本月底将邀请您来总部参加组织规划与变革方案的评审会，届时将会对您的计划书进行评审。如通过评审，公司所有广告部将会按照您的计划书进行变革。

                      祝愿世界明天的舞台，因我们而变得更加美好、充满激情与想象

 

                                                                                          CEO GEF

 

“噢！太棒了，这封信来的真是及时，如果再继续如此的话，我要压垮了，只好另谋它职了。嗯，这回我要好好地写这个计划书。这样，身上担子总算有减轻的希望。有上司的赏识，我要一展宏图一番。”GraphicalEditPart不由自主拍了下桌子自言自语后，张开双臂，砰地一下仰靠在椅背上，深深地出了口气，双目轻合工作的压力似乎片刻间消失，顺手戴上了他那十分酷毙的太阳镜，小声打开旁边CD，噢，夏威夷之夜，感觉自己此时就在夏威夷带着墨镜躺在金黄、松软、温暖的沙滩，吹着口哨，热情似火的太阳穿过太阳镜，越过眼皮，将几缕模糊的光芒带入眼中（其实是他那高瓦的吊灯），海风习习（旁边的电风扇），在享受着这片刻宁静天堂感觉，激情创意不断涌出，啊，久违了的感觉。

 

开干！迅速的打开他喜爱的脑图软件 -- Mindjet Manager，记录下脑中的构思，画下如下计划要点：

 

看来GraphicalEditPart先生要大干一场，欲知详情，请听下回分解

般若菩提 2005-12-05 14:01 发表评论

]]>

GEF源码分析（四） GEF 消息转义 ___ Tool的作用

接着上一节：

我们先解决如下问题：

在界面操作过程中，我们希望面对的是边框调整事件，图形移动事件，或者是编辑文本事件，而不是原始的鼠标和键盘事件？

术语定义：

系统UI事件：        一般由某些计算机人机交互硬件发出信号，并且经操作系统理解后产生的事件，例如：原始的鼠标的移动、点击和键盘的敲击事件等。

UI业务语义事件： 由系统UI事件和其它UI业务语义事件触发，由UI业务代码理解后产生的事件（操作系统不可理解，同时无任何领域的业务语义），如2D图形的尺寸调整，2D图形的点击，2D图形的移动。

（其实不仅限于事件的转义，包括UI的改变，也需要由系统UI语义转换到UI业务语义来使用）

UI业务语义事件在Controller控制中的优点是易于理解、维护和扩充，具体的主要有以下方面：

a.减少系统UI事件判断逻辑部分代码的重复。比如在Controller部分代码无需分步着大量逻辑重复的代码，当鼠标移动时去判断究竟是一个2D图形的尺寸改变，还是一个2D图形的移动，还是一组2D图形的移动，还是2D图形DragAndDrop的动作。

b.Controller部分的代码语义明确。在Controller内部处理代码和接口中直接面对的是UI业务语义，如图形的移动，图形的尺寸改变，这样、代码易于理解、调试等。

b.Controller部分代码无需为系统UI事件保存状态。如2D图形的移动中，如果这些事件直接在Controller中处理，从开始MouseDown,到MouseMove，到MouseUp过程中，在Controller中要集中保留这样众多状态，极易造成Controller代码具体多头职责的症状，从而患上严重的精神分裂:)。

于是乎GEF的FrameWork有给出以下的解决方案：

图A

如上图A：

GEF通过Tools(根interface是Tool)，当然在视图上的Menu和Toolbar是通过Action发出，这个是eclipse的Workbench机制，在此就不讨论了。以下是Tool的类继承树：

图B

从上图B可以看出

从Tool继承的这些类均处理一个或者一类UI业务语义事件，其中需要保留中间状态的子类均以XXXTracker形式出现。

首先这些Tool的实现类通过Tool的接口（上图右边），接收界面来的事件，然后调用内部handleXXX，这样通过内部函数getTargetRequest()[createTargetRequest()]和getSourceRequest()[createSourceRequest()]，把系统UI事件转换为UI业务语义事件叫Request（如图C）。至此Tool会通过调用相关联的EditPart的接口将UI业务语义事件通知到EditPart中。于是在Controller(EditPart)中仅仅需要理解处理Request对象。

图C

下面以ResizeTracker代码为例：

class ResizeTracker

protected Request createSourceRequest() {

ChangeBoundsRequest request;

request = new ChangeBoundsRequest(REQ_RESIZE);

request.setResizeDirection(getResizeDirection());

return request;

}

protected Command getCommand() {

List editparts = getOperationSet();

EditPart part;

CompoundCommand command = new CompoundCommand();

command.setDebugLabel("Resize Handle Tracker");//$NON-NLS-1$

for (int i = 0; i < editparts.size(); i++) {

part = (EditPart)editparts.get(i);

command.add(part.getCommand(getSourceRequest()));

}

return command.unwrap();

}

protected void eraseTargetFeedback() {

if (!getFlag(FLAG_TARGET_FEEDBACK))

return;

if (getTargetEditPart() != null)

getTargetEditPart().eraseTargetFeedback(getSourceRequest());

setFlag(FLAG_TARGET_FEEDBACK, false);

}

protected boolean handleButtonUp(int button) {

if (stateTransition(STATE_DRAG_IN_PROGRESS, STATE_TERMINAL)) {

eraseSourceFeedback();

eraseTargetFeedback();

performDrag();

}

return true;

}

最后还有个问题是

Tool这些事件接口，如何从Viewer传递过来的呢？

我画了一个简要的类图

图D

参照上图，下面罗列重要代码：

大家主要以下两方面

一、创建这些关键事件处理链的过程（注意图上的粗体文字）；

二、消息从SWT中Canvas实例传递到Tool过程（图D中注释标签的顺序）；

class GraphicalEditor

public void createPartControl(Composite parent) {

createGraphicalViewer(parent);

}

protected void createGraphicalViewer(Composite parent) {

GraphicalViewer viewer = new ScrollingGraphicalViewer();

viewer.createControl(parent);

setGraphicalViewer(viewer);

configureGraphicalViewer();

hookGraphicalViewer();

initializeGraphicalViewer();

}

protected void setGraphicalViewer(GraphicalViewer viewer) {

getEditDomain().addViewer(viewer);

this.graphicalViewer = viewer;

}

class EditDomain

public void addViewer(EditPartViewer viewer) {

viewer.setEditDomain(this);

if (!viewers.contains(viewer))

viewers.add(viewer);

}

class GraphicalViewerImpl

public void setEditDomain(EditDomain domain) {

super.setEditDomain(domain);

// Set the new event dispatcher, even if the new domain is null.  This will dispose

// the old event dispatcher.

getLightweightSystem()

.setEventDispatcher(eventDispatcher = new DomainEventDispatcher(domain, this));

}

private final LightweightSystem lws = createLightweightSystem();

class ScrollingGraphicalViewer

public void setEditDomain(EditDomain domain) {

super.setEditDomain(domain);

// Set the new event dispatcher, even if the new domain is null.  This will dispose

// the old event dispatcher.

getLightweightSystem()

.setEventDispatcher(eventDispatcher = new DomainEventDispatcher(domain, this));

}

class LightweightSystem

public void setEventDispatcher(EventDispatcher dispatcher) {

this.dispatcher = dispatcher;  //在此Shapes例子中是DomainEventDispatcher

dispatcher.setRoot(root);

dispatcher.setControl(canvas);

}

protected void addListeners() {

EventHandler handler = createEventHandler();

canvas.getAccessible().addAccessibleListener(handler);

canvas.getAccessible().addAccessibleControlListener(handler);

canvas.addMouseListener(handler);

canvas.addMouseMoveListener(handler);

canvas.addMouseTrackListener(handler);

canvas.addKeyListener(handler);

canvas.addTraverseListener(handler);

canvas.addFocusListener(handler);

canvas.addListener(SWT.MouseWheel, handler);

……

setEventDispatcher(getEventDispatcher());

}

class EventHandler

implements MouseMoveListener, MouseListener, AccessibleControlListener, KeyListener,

TraverseListener, FocusListener, AccessibleListener, MouseTrackListener,

Listener

{

…

public void keyPressed(KeyEvent e) {

 //在此Shapes例子中是DomainEventDispatcher

getEventDispatcher().dispatchKeyPressed(e);

}

…

public void mouseDoubleClick(MouseEvent e) {

getEventDispatcher().dispatchMouseDoubleClicked(e);

}

…

public void mouseMove(MouseEvent e) {

getEventDispatcher().dispatchMouseMoved(e);

}

public void mouseUp(MouseEvent e) {

getEventDispatcher().dispatchMouseReleased(e);

}

…

}

这样、在图A中Request发送到EditPart机制做了简要的探讨。

学习了Tool产生Request的机制，可以帮助我们调试GEF，同时如果在大家自己的程序中需要有新的UI交互类型，也可以试着建立自己的Tool类产生新的Request，这样在自己的EditPart产生对应的Command,这样就可以处理实现新的UI交互类型。

在下一篇我们探讨一下有关图A中的EditPart如何产生Command，以及执行Command问题。

包含GEF的Editor创建时序图

以eclipse网站上例子A Shape Diagram Editor为例

GEF如同其他的一些framework一样，是一个复杂庞大（有点夸张）的，当我们想使用驾驭它时，就必须全面的理解其整体构架及其运作过程。这需要我们的毅力和敏锐。旅途开始了….

GEF主要的任务是针对2D图形编辑操作，如下图。

为了使GEF能够广泛的用于种类繁多2D图形编辑领域，GEF就必须建立一个严格的易扩充/易组合/易重用的MVC框架（当然这种分解细化功能对象的方法思想，我们可以用在其它的地方，其它领域、其他语言如C#上）。

那么如果设计 这个 严格的MVC框架(对于Model是严格的独立，它不依赖与View和Controller) 以及 此框架 如何 达到 易扩充/易组合/易重用 的特性。下面我按照自己拙劣的思路，以麻雀之眼度鸿雁之志啦

对于MVC中

View部分：GEF理所当然要使用自家的东东Draw2D。利用Draw2D的Figuer作为自己的View。

Model部分：往往内部包含了千差万别、不可预知的商业信息。因此、GEF框架应该尽量减少约束（在下面将详细说明约束）。

Controller部分：EditPart/Draw2D的Figure/Model这三个树状对象模型，在EditPart中将建立了与其对应的Draw2D的Figure/Model结点 建立一一关联的关系。

这样产生的构架如下：

思考：

为什么Controller要同View一样采用树状结构呢？

当Controller以树状的形式存在，这样便于功能分解（这个道理有点像 在类设计中 复合优于继承 一般）

这样每一结点的Controller(即EditPart) 仅需要处理

• 自身逻辑功能
• 管理子Controller
• 必要时通知父Controller

尤其当用户需要在图形界面编辑界面中，需要使用多种不同UI行为规则的2D元素（例如不同的形状块，不同行为的连线等）组合来完成工作时（例如类似Visio这样的界面），这种构架的优势就显露无疑。

未完待续….(下面要探讨如何产生上述三个树状模型等。)

GEF学习笔记（一） eclipse的GEF相关项目说明

首先、感谢八进制的辛勤劳动和奉献。这几天开始对GEF发生兴趣，八进制的GEF系列对我学这些的帮助很大入门很快。自己也就顺手把周末学习的东西记录下来。帮助后来学人。我会把这几天所学陆续写出希望大家支持。目前、正在为八进制例子发愁，我对NodePart增加了ResizeEditPolicy，但是不知为何鼠标拖动时有个灰色的区域在随着变化，但鼠标释放时，NodeFigure的尺寸不发生变化，是否是因为在refreshVisuals中固化了Size，代码学习中….

eclipse的GEF相关项目说明。

各项目的简介：

Draw2D：建立了2维的图形库(树状图形部件Figure)，负责显示2维的图形展示。

GEF：     （Graphical Editing Framework）建立标准的MVC构架，代码利用Draw2D作为自己的View部分，主要代码实现复杂的树状(于Model分别对应)      的控制器。实现的框架具有很高的可复用等特性，例如：将图形部件功能分解为多个EditPolicy，这样使用者可以通过installEditPolicy接口来定制，以及扩充自己的某一功能特征。

EMF:      （Eclipse Modeling Framework）首先在一个轻量级项目以及项目初期开发，Model常常采用拥有Property的Java对象来简单明了表示【即 Plain Old Java Objects (POJOs)】。EMF定义了一套Ecore元模型，使得Model具有易于维护、易于扩充、易于数据交换等特性的Model Framwork。因此、在实际中大型的项目中往往会采用Draw2D＋GEF＋EMF的方式来实现整体的MVC模式。例如：ROSE的最新版本 IBM.Rational.Software.Architect就是采用了这种构架。

GMF：    （Graphical Modeling Framework ）使用了GEF和EMF，建立了两个之间的桥梁框架，同时实现了一些领域上的典范应用，如UML图，甘特图，脑图等。（项目正在进行中这些功能还未完备。可以用来参考以实现自己的一个标准的GEF＋EMF的应用）。

各项目依赖关系：

如上图：使用者可以有以下几种用法：

EMF: Model管理层

Draw2D: 二维图形展现

Draw2D ＋ GEF: 二维图形的简单编辑模块

Draw2D ＋ GEF ＋ EMF： 二维图形的编辑模块

Draw2D ＋ GEF ＋ EMF ＋ GMF：基于GMF提供的图形编辑功能之上扩展