第一篇寫于 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 這個接口：

package com.primeton.framework.workbench { import mx.core.Container; import mx.core.UIComponent; public interface IWorkbenchPart { function createPartControl ( parent:Container=null ):Container; } }

這個接口允許把Parent Contaier這個Display Object傳遞進來構建，也可以不傳遞進來。EditorPart和ViewPart都必須實現這個接口方法，來初始化其所代表的Display Object實現。

今天寫的少了點，趕明再接著寫。

Flex開發流程設計器的經驗之談（2）