可視化編輯器的設計

背景

編輯器是IDE的重要組成部分。可視化編輯器比文本編輯器更能體現IDE工具下降開發成本，提升開發效率的目的。另外對於功能完整，交互體驗，內存佔用與性能（通常都是連續使用好久）有必定要求。

編輯器的數據設計

   上圖，仍是比較清晰地描述了這一過程。編輯器在打開和關閉/保存是會進行實際文件的操做。而在編輯器運行時，都是對結構化的運行 數據對象進行操做。因此組件的數據結構設計，以及良好的API，對於後續的研發相當重要。若是可視化編輯框架採用第三方開源框架（例如： mxgraph），還需將運行時數據對象與框架標準數據進行轉化，由於每每公司已有的數據結構是本身定製的不會和框架一致，也不會爲了使用框架而修改。:grimacing:    索引是基於結構化數據，針對文件內容快速檢索的功能。就像針對文件可檢索的數據庫。基於索引可進行組件使用統計。文件結構校驗等功能。

可視化編輯器的組成

• 可視化編輯區

  • 組件選中    選中是整個可視化編輯的基礎。用戶的操做行爲發生在視圖上（View）,當View上監聽到click事件後需快速映射到對應的數據對象（model）。當屬性性修改後，數據對象發生改變，又須要快速更新渲染視圖。因此負責橋接視圖和數據的部分稱爲控制器（Control），這就是MVC模式的典型使用場景。最後將選中組件的數據向外傳遞，其餘輔助模塊如：屬性，大綱就能夠正產工做了。固然別忘了凸現下當前選中的組件。
  • 拖拽調整組件位置    鼠標拖動過程當中，若是懸浮的拖動目標組件對與當前拖動的元素有影響的話，例如：存在容器類組件，普通組件，普通組件沒法容納普通組件，而容器能夠容納。則須要實時獲取鼠標下方的組件，並快速獲取組件的配置信息以校驗後續的佈局策略。因此須要View -> model -> 組件配置 -> 產生拖動策略 的邏輯足夠快的執行。當拖拽完成時，產生移動命令(下面有詳細說明)修改model更新view.
  • 拖拽添加組件    拖拽新增相似於拖拽移動。只是須要產生建立命令。
  • 拖拽回顯（拖拽完成前的輔助線或模擬組件放置後的效果）    拖拽輔助線應繪製在獨立的上方圖層，可在拖動開始時，初始化可輔助的位置。校驗條件放寬些，達到吸附的效果。

• 組件選擇區

  • 配置化組件    豐富的組件與可視化編輯器的能力息息相關。組件新增和修改是開發比重較大且持續的部分。可經過配置化的方式完成。例如：組件的惟一標誌，組件圖標，組件名稱，組件類型，組件屬性（組件屬性的編輯方式）等等，提取成類似的配置。
  • 個性化組件（進階）    編輯器提供的標準組件可完成大部分的場景開發，可是有些個性化的場景卻受限於標準組件功能沒法實現。但採用標準組件擴展的方式不只增長編輯器的研發負擔，還增長組件的複雜度。（例如 ：組件的某個屬性只會在特性場景使用）。全部若是支持用戶本身高度定製本身的組件，自定義組件與標準組件庫分離，獨立維護，會是更好的方式。但這也對組件的配置化設計，自定義組件功能實現者提出更高要求。
  • 組件分級    上面描述了兩級，進一步推演下去。一些良好的個性化組件能夠被編輯器吸取，由編輯器默認提供，因而就出現了三級分化。標準組件，公共自定義組件，自定義個性化組件。從業務角度來看，也是業務程度不斷增長的過程。

• 命令機制：

  用戶全部的編輯行爲（新增，刪除，修改）規範成統一的命令對象，稱爲命令。命令能夠被正向或反向執行（undo,redo）,而且命令執行後並不銷燬而是保存到命令堆棧中。命令機制可實現用戶觸發相應的正反向執行，並提供文件狀態，爲文件保存提供準確時機。

  

  1. 當用戶新增一個組件時，一個建立的命令產生，並正向執行。
  2. 將命令放入undoStack
  3. 更新相關狀態 因爲undoStack.length>0 因此undo菜單可點擊；因爲undoStack不爲空，說明用戶產生了修改，因此更新文件的編輯狀態爲：產生了修改（dirty）
  4. 若是用戶觸發的undo，則取出undoStack的最上層的命令，反向執行命令邏輯（建立的命令的反向執行邏輯是刪除建立的組件），因而組件被刪除。
  5. 將命令放置的redoStack
  6. 更新狀態：因爲undoStack，redoStack的變化更新undo菜單爲不可點擊，redo菜單爲可點擊，文件狀態爲未編輯（no dirty） ps：
  7. 若是用戶連續操做，只是隊列深淺的變化，不影響效果
  8. 這只是一個簡單的設計，未考慮用戶連續保存，redo後又正常編輯等複雜狀況。

• 熱鍵機制

  1. 編輯器全局熱鍵的監聽
  2. 熱鍵觸發邏輯的配置化    因爲熱鍵自己並不固定，新增，修改的狀況比較多，另外良好的編輯器能夠支持用戶自定熱鍵，甚至自定義熱鍵邏輯。因此配置的方式會提供便利。

• 屬性編輯區

  1. 根據組件配置信息與用戶選中的組件，及時更新組件屬性的編輯域，並提供良好的編輯交互。用戶產生修改行爲後，產生相應的修改命令。

• 大綱區

  1. 根據結構化數據生成結構樹，方便用戶查看文件結構，選中組件，刪除組件，具備必定輔助的功能。

結束語

架構上參考一部分Eclipse插件開發中的GEF框架，有些本身設計實現了，有些本身YY的。可能有後續相關博客。。。有啥意見建議及時交流哈:smile: