关于编辑器

在IDE中编辑器是一个比较丰富的东西，它本身的操作比较丰富，另外就是它跟很多辅助的视图建立了很多联系。如果处理不好，会很难用实现起来也不爽。eclipse中目前编辑器都是基于gef框架进行实现的。

 

gef是一个MVC的三层结构，其实就算是不是gef，想合理实现一个编辑器，也应该采用这样一个结构。（设计模式比框架更宽泛，框架只是设计模型的具体体现）

 

编辑器的模型（model）：

如果想你的IDE更灵活，那么编辑器的模型涉及到的不仅仅是业务层的模型，也就是编辑器需要编辑的文件的模型。你需要为你的所有的需要展现的视图建立一套自己的定制的和描述的模型。

例如，你要使你的属性视图可配置，就应该有描述属性视图中的属性显示的方式的模型。还有palette面板，也可以实现可配置，这样在添加新的组件的时候，不至于需要写一大堆东西。

属性视图的描述模型和palette的描述模型的模型都是描述某类型节点的，例如button拥有属性，那属性描述模型就是描述button（这一类）的而不是描述button1（这一个）的，palette的是一样的效果。所以，属性描述文件，palette描述文件和业务流程文件的对应关系是1：1：n的。

 

我自己在实现编辑器的时候，是把属性描述文件的root放到业务模型的root里面保存的，而palette描述文件的root是放到编辑器里面的。主要是因为属性描述文件一般在属性视图中用到，这样我在选中某个节点的时候，获得业务模型的时候，同事获取到属性描述模型。而palette描述文件是在编辑器中用到，所以不用放到业务模型中。

 

除了模型的设计以外，每个model的属性也要进行考虑，无论在那个系统中模型都是用于存放数据的，而数据的存放就涉及到一个数据类型的转换。我的思路是实现一个数据转换器，当需要转换的时候，传入属性的类型和数据。它就根据属性的类型把数据转换成某种类型的数据。另外在使用数据的时候，如果没有特殊情况，我都是传输字符串的，等到使用的时候才转换。

 

 

编辑器的控制（Control）：

说道控制器，我就想起command，其实就是操作，只是换了个地方，换了个形式。只要稍加熟悉，会用这种方式创建command和响应就行了，不只是gef中，就算是其他的地方也就这个样。它的功能无非就是把电脑的输入端传递进来的操作，进行合理的变换，而这个变换就体现在view层上。

尽管如此，还是得提一下，因为编辑器和大纲，以及编辑器和属性视图的联动还是需要进行设计的。当然这个eclipse已经帮我们提供好了思路，思路的最根本原则就是，对方变我听的到，具体实现就不详述了。

 

编辑器的显示（view）：

说实在的，尽管它跟其它的模块联系的紧密度最低，但是想做好也是很需要基本功的，这也是我一直想多练习练习的地方。其实一个任何带界面的软件，除了操作的简洁和响应的速度以外就数这个好看了，很重要。