第一篇寫於2個多月前，其間趕上春節，同時去年底突然安排了新任務，忙於另外的研究去了，從而一直沒有再繼續總結。還有個原因，是因為期間在斷斷續續的flex

首先回顧一下上一篇的內容。其實上一篇是非常“原則性的設計思路”，很多人可能讀完以後會覺得很空洞，但真正在研發過程中，真正有價值的反而是這種看似空洞的指導思想和思路。——不信，可以嘗試從零做做看，你就會發現，你真正需要的是什麼了。

上一篇主要講了幾個原則：

（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

如果對Eclipse GEF/UI瞭解的話，看到這三個物件，你一定知道接下來要說什麼。

對一個Flex流程設計器來講，不僅僅只是流程圖繪製這一塊，你還需要涉及到一些額外的“檢視（View）”，比如你可能需要顯示當前流程圖的OutLine，你可能需要顯示問題列表，顯示xml格式檢視等等情況。借鑑eclipse gef/ui中的EditorPart和ViewPart設計思路，是非常不錯的。

       如上圖，IEditorPart介面的實現代表一個圖形化的設計區域編輯器，而IViewPart代表檢視，其中每個ViewPart都會有一個Viewer，來表示真正的檢視實現。注意，此處

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實現。

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