背景
編輯器是IDE的重要組成部分。視覺化編輯器比文字編輯器更能體現IDE工具降低開發成本，提高開發效率的目的。另外對於功能完整，互動體驗，記憶體佔用與效能（一般都是連續使用很久）有一定要求。
編輯器的資料設計
視覺化編輯器的組成
-
視覺化編輯區
- 元件選中 選中是整個視覺化編輯的基礎。使用者的操作行為發生在檢視上（View）,當View上監聽到click事件後需快速對映到對應的資料物件（model）。當屬性性修改後，資料物件發生改變，又需要快速更新渲染檢視。所以負責橋接檢視和資料的部分稱為控制器（Control），這就是MVC模式的典型使用場景。最後將選中元件的資料向外傳遞，其他輔助模組如：屬性，大綱就可以正產工作了。當然別忘了凸現下當前選中的元件。
- 拖拽調整元件位置 滑鼠拖動過程中，如果懸浮的拖動目標元件對與當前拖動的元素有影響的話，例如：存在容器類元件，普通元件，普通元件無法容納普通元件，而容器可以容納。則需要實時獲取滑鼠下方的元件，並快速獲取元件的配置資訊以校驗後續的佈局策略。所以需要View -> model -> 元件配置 -> 產生拖動策略 的邏輯足夠快的執行。當拖拽完成時，產生移動命令(下面有詳細說明)修改model更新view.
- 拖拽新增元件 拖拽新增類似於拖拽移動。只是需要產生建立命令。
- 拖拽回顯（拖拽完成前的輔助線或模擬元件放置後的效果） 拖拽輔助線應繪製在獨立的上方圖層，可在拖動開始時，初始化可輔助的位置。校驗條件放寬些，達到吸附的效果。
-
元件選擇區
- 配置化元件 豐富的元件與視覺化編輯器的能力息息相關。元件新增和修改是開發比重較大且持續的部分。可通過配置化的方式完成。例如：元件的唯一標誌，元件圖示，元件名稱，元件型別，元件屬性（元件屬性的編輯方式）等等，提取成相似的配置。
- 個性化元件（進階） 編輯器提供的標準元件可完成大部分的場景開發，但是有些個性化的場景卻受限於標準元件功能無法實現。但採用標準元件擴充套件的方式不僅增加編輯器的研發負擔，還增加元件的複雜度。（例如 ：元件的某個屬性只會在特性場景使用）。所有如果支援使用者自己高度定製自己的元件，自定義元件與標準元件庫分離，獨立維護，會是更好的方式。但這也對元件的配置化設計，自定義元件功能實現者提出更高要求。
- 元件分級 上面描述了兩級，進一步推演下去。一些良好的個性化元件可以被編輯器吸收，由編輯器預設提供，於是就出現了三級分化。標準元件，公共自定義元件，自定義個性化元件。從業務角度來看，也是業務程度不斷增加的過程。
-
命令機制：
使用者所有的編輯行為（新增，刪除，修改）規範成統一的命令物件，稱為命令。命令可以被正向或反向執行（undo,redo）,並且命令執行後並不銷燬而是儲存到命令堆疊中。命令機制可實現使用者觸發相應的正反向執行，並提供檔案狀態，為檔案儲存提供準確時機。- 當使用者新增一個元件時，一個建立的命令產生，並正向執行。
- 將命令放入undoStack
- 更新相關狀態 由於undoStack.length>0 所以undo選單可點選；由於undoStack不為空，說明使用者產生了修改，所以更新檔案的編輯狀態為：產生了修改（dirty）
- 如果使用者觸發的undo，則取出undoStack的最上層的命令，反向執行命令邏輯（建立的命令的反向執行邏輯是刪除建立的元件），於是元件被刪除。
- 將命令放置的redoStack
- 更新狀態：由於undoStack，redoStack的變化更新undo選單為不可點選，redo選單為可點選，檔案狀態為未編輯（no dirty） ps：
- 如果使用者連續操作，只是佇列深淺的變化，不影響效果
- 這只是一個簡單的設計，未考慮使用者連續儲存，redo後又正常編輯等複雜情況。
-
熱鍵機制
- 編輯器全域性熱鍵的監聽
- 熱鍵觸發邏輯的配置化 由於熱鍵本身並不固定，新增，修改的情況比較多，另外良好的編輯器可以支援使用者自定熱鍵，甚至自定義熱鍵邏輯。所以配置的方式會提供便利。
-
屬性編輯區
- 根據元件配置資訊與使用者選中的元件，及時更新元件屬性的編輯域，並提供良好的編輯互動。使用者產生修改行為後，產生相應的修改命令。
-
大綱區
- 根據結構化資料生成結構樹，方便使用者檢視檔案結構，選中元件，刪除元件，具有一定輔助的功能。
結束語
架構上參考一部分Eclipse外掛開發中的GEF框架，有些自己設計實現了，有些自己YY的。可能有後續相關部落格。。。有啥意見建議及時交流哈:smile: