浅淡EditPolicy和GEF的执行流程

说说策略(EditPolicy)，其实策略和命令是没有必然的对应关系的，至于GEF框架中内置的一些策略，大多不过是继承了AbstractEditPart。
我们自己完全可以实现一个EditPolicy，重要的是你的EditPolicy能够处理什么请求，初学者往往困惑于使用什么策略，如何对应角色。
其实角色那个键，也是GEF虚晃一枪，你取什么值都可以，但不要重复。

那么，重要的是什么，重要的是请求，你能产生什么请求？

请求是由谁产生的，一般而言，请求是由Tool和Action产生的，在Action中我们可以产生任何可能的请求，
Tool也一样。在GEF框架中的Tool能够产生大多数请求，一般应用，足够了。

GEF中，为什么会有EditPolicy，Command等。

其实整个处理过程是这样的。

SWT的重量级控件产生的SWT事件被LightweightSystem的EventHandler所捕获，捕获后将其转发给DomainEventDispatcher，DomainEventDispatcher
将其转发给EditDomain,EditDomain又将事件转发给Active Tool，Tool将这些事件做了一个转换，将SWT事件转化为了请求，Active Tool可能维护有一个targetEditPart，此时，Tool向EditPart(根据指定的Request)要Command，好了，到EditPart了，本来，EditPart在这里就可以搞定一切事情了，产生Command实例，给Tool，让Tool执行就是。但GEF中，又绕了一道弯，它沉重，偷懒，将这些请求转发给EditPolicy，一个EditPart上可能安装了多个EditPolicy，也可能一个也没安装，是否有安装EditPolicy和安装的多寡决定了一个EditPart的编辑能力。到终点了，EditPoliy如果能够处理此请求，就产生相应的Command(当然一切全凭程序员去实现了)，Command改变模型，模型改变触发Property Change，而EditPart又恰好是模型改变的监听者，它会负责根据最新模型刷新
View。