Flex开发流程设计器的经验之谈

在(3)中,简要介绍了整个Flex版设计器的整体架构,那么今天就进入比较细粒度的Flex GEF的内核看看。

 

既然名称中有“GEF”,那么肯定会与Eclipse GEF的设计会有所类似,事实上,本身就是借鉴GEF的设计思想和对象概念模型,只是做了改造和简化。

 

如下图所示。Flex开发流程设计器的经验之谈_第1张图片

其最基本的核心在于“IModel、IEditPart、IFigure”,这构成了MVC的核心对象模型。

 

     IModel的变更会通知IEditPart这个控制器,由控制器刷新IFigure。—— 不过此处并没有采用EMF那种对象结构:EMF在底层对Model的所有属性变更都做了监听,任何变更都会引发Notifor操作,从而利用监听器来处理notification。在我最初的设计中,原本也想这么操作的,不过后来摒弃这个思路。如果在底层再引入一个类似EMF的框架,会再引入大量的基类,无形中增大了最终flash文件的大小。所以,此处虽然也支持Notifor操作,但是都是“外围显示主动通知Notifor”的方式,而且抛弃了Notification这一层。—— 这样的结果就是,我在command中,并不是非常彻底的只操作Model,或多或少都会会显示引发对EditPart的处理操作。(这是一个很“拖泥带水”的实现方式,但是处理方式要简化很多,而且节省了很多底层代码,缩减了flash文件)。

 

      当然,每一个Editor都会维持一个属于其自己的EditDomain,用于记录在当前操作空间的一些对象,比如“commands”、“那些对象被选中”、“Figure或Model与EditPart的快速索引”等等。

      另外,每个Editor都会由一个Viewer来,定义当前显示方式。同时,利用EditPartFactory、ModelFactory、FigureFactory来创建相应对象。上层业务层真正需要实现不同的Factory(已经包括相应的model、editpart、figure),这样就可以很容易快速实现不同“视图展现模式”。—— 外围大量的扩展代码都是在这个地方。

 

      当然,这里面有一个“Figure”概念。早在(1)中,就已经简单提过,Figure并不是Flex中的概念,只是用用于“声明这是一个GEF中的图形”而已。(注:这个Figure的处理很有技巧性,处于商业产品的限制,我无法更多的在这里做详细解释,大家只能自己揣摩了

 

      当然,真正的Flex GEF内核实现要比上面图形中的展现复杂不少。但基本逻辑关系的核心已经表示差不多了。

     

      这部分内容也只能“点到即止”,毕竟本身属于商业产品范畴。

你可能感兴趣的:(flex,flash,eclipse,图形,command,mvc)