可视化编辑器的设计

背景

编辑器是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: