第一篇写于
2
个多月前，其间赶上春节，同时去年底突然安排了新任务，忙于另外的研究去了，从而一直没有再继续总结。还有个原因，是因为期间在断断续续的
flex
设计器原型系统研发过程中发现很多原有的一些细节设计之处不足，又作了很多细节性的重构和完善。这几天又接着完成了一个阶段的原型实现，才有空闲再接着写总结。
第一篇地址：
http://blog.csdn.net/james999/archive/2008/11/16/3313861.aspx
首先回顾一下上一篇的内容。其实上一篇是非常“原则性的设计思路”，很多人可能读完以后会觉得很空洞，但真正在研发过程中，真正有价值的反而是这种看似空洞的指导思想和思路。——不信，可以尝试从零做做看，你就会发现，你真正需要的是什么了。
上一篇主要讲了几个原则：
（1） 一定要 MVC 架构，这个 MVC 架构不是说那个诸如 PureMVC 那种框架性架构，而是指的剥离“流程图形”“流程模型”“控制器”的设计结构，也就是 eclipse gef 中“ Model-EditPart-Figure ”这个架构。
（2） 玻璃板技术，外围拦截鼠标键盘事件，进行处理。
（3） Command 模式，来处理操作。可以轻松解决 redo-undo 。而且严格记住，你的 command 作用的对象是“ model ”，而不是“图形”。
（4） 使用 Layer 模式，将不同的图元放于不同的图层上。比如底层的 Grid 放在某个层，活动节点放于某个层，连接线放于某个层，拖拽的阴影放于某个层等等。
（5） 利用 Editor 和 EditorDomain 、 SelectManager 等等对象来维护针对当前流程的管理空间。这个在 eclipse gef 中是基本概念，不清楚的建议看看相关资料。
现在进入正题。
WorkbenchPart 、 EditorPart 、 ViewPart
如果对 Eclipse GEF/UI 了解的话，看到这三个对象，你一定知道接下来要说什么。
对一个 Flex 流程设计器来讲，不仅仅只是流程图绘制这一块，你还需要涉及到一些额外的“视图（ View ）”，比如你可能需要显示当前流程图的 OutLine ，你可能需要显示问题列表，显示 xml 格式视图等等情况。借鉴 eclipse gef/ui 中的 EditorPart 和 ViewPart 设计思路，是非常不错的。
如上图，
IEditorPart
接口的实现代表一个图形化的设计区域编辑器，而
IViewPart
代表视图，其中每个
ViewPart
都会有一个
Viewer
，来表示真正的视图实现。注意，此处
Viewer
本身不是一个
Flash DisplayObject
对象，或者说不是一个
Flex UIComponent
对象，其内部的
viewerControl
才是表明此
View
的真正展示对象，比如是一个
Tree
，还是一个
DataGrid
，抑或是其他的
UIComponent
。
IeditorPart 和 IviewPart 本身也不是 DisplayObject ，其仅仅表示这是一个 View 或者是一个 Editor 对象，索引一些资源。
看看 IWorkbenchPart 这个接口：
这个接口允许把Parent Contaier这个Display Object传递进来构建，也可以不传递进来。EditorPart和ViewPart都必须实现这个接口方法，来初始化其所代表的Display Object实现。
今天写的少了点，赶明再接着写。
