使用gef构建一个图形化的流程设计器.

  我们总是在做着各种反潮流的事情..

  当jbpm4在N年以后终于推出了自己的 "羚羊"的时侯,我们却要从已有的web流程设计器退化为用eclipse plugin的形式绘制流程.在这个诡谲的客户第一的年代里面.我们操起了osgi.操起了eclipse plugin. 操起了各种swt jface.... 操起了更加诡异的gef.放下我心爱的web流程设计器.(T T .还没优化好呢.)

  避开难受的osgi类加载机制吧.他太过于繁琐.我们只需要知道plugin作为bundle插入了容器便好了. 避开各种操蛋的swt jface吧.(我十分期待eclipse v4的xwt.)在类xml语言描述界面的大潮下.swt确实写起来让人蛋疼. swt设计器生成代码又有诸多限制以及问题. . 好吧. 事实上我最想避开的是gef.这个东西实在是太过于复杂.
附图:

  恐怖的osgi类加载机制:



  eclipse plugin开发其实不是什么高深的学问.没什么复杂的技术.我归结了一下.用三个字表达:"基于xml编程的eclipse plugin开发." 嗯.三个字.. eclipse插件开发中最重要的三个个文件就是Activitor plugin.xml 跟 MANIFEST.MF.(此刻我是多么期望能有anotation大大前来救驾.)Activitor同android什么activitor的其实是类似的. 提供了一个加载bundle的入口.当然osgi规范也制定了一系列的bundle的install.uninstall.avtive什么的状态转换过程的规范.嗯.各种规范.  plugin.xml维护了插件的扩展点.所谓扩展点分为两种.一种为eclipse自身的扩展点.我们可以扩展很多东西.wizard.editor.menu什么的.另一种我们可以自己制定扩展点.(这里面包括真的是自己的扩展点.和别人开发的插件的扩展点.).当然eclipse给你提供了方便的插件扩展界面.通过界面可以轻松的扩展.但是.但是啊.. MANIFEST.MF实际上是osgi的遗孀.我们的插件需要他.来作为osgi的bundle.bundle之间有什么相互依赖.然后你的插件需要导出导入什么package给别人或者给自己用都可以在里面定义.osgi R4的规范里面用很大的篇幅描述了如何才是一个规范哦MANIFEST.MF文件.然后各大osgi框架用大量的代码来校验并使用这个文件.osgi规定了一套classload机制来loadclass.然后分出了各种层来确保安全.服务的完整性等等.. 在这里推荐想深入了解的阅读 osgi规范.其实开发插件只需要了解MANIFEST.MF文件寻找bundle的机制.以及export import package的规则就可以了.了解之后能避免很多不必要的时间浪费.

附图:

  bundle状态转换图:

 

  swt其实是好东西.好吧.我承认是对比swing.(看到swing的几刀有感而发.还想说两句. twaver也是好东西.) .但是对比mxml.xaml这样的东西.代码可阅读性上还是太差.并且对比类xml语言(发现过一个 swt/xml的东西.不过貌似不成熟..).代码生成与反生成的难度也会更高.(虽然没我什么事.不过流程设计器实际上跟这些界面设计器是类同的.).手写代码的郁闷程度上会高很多.jface封装过了swt.提供了一些常用的组件.抽象的层次有所提高.还是有很大用处的.实际上在开发eclipse plugin的过程中.最常用的方法就是查看eclipse其他plugin的源码.尤其是jdt的源码.可以翻到很多有用的组件.然后就可以为我所用.当然条件是要学会找.. 这个能力还是要有经验累积的.我就不会抄..T T.

  web模式的mvc中view请求经历了servlet/rack/...等的一次封装.将http请求封装为了"request".以至于大家可以处理.当然.在非web模式的mvc框架中.gef也存在这样的东西. 同样将界面操作自身封装为"request"以供policy接收并处理.这种类型的匹配也是师出同门.所以有必要将他们进行小小的对比.
  附:在rest大行其道的今天.有人提出了一个新的架构 RMR. 嗯.就是resource-method-representation. 理由很简单.web上面应该是以资源为主.method处理请求以处理资源.然后representation处展示. 好吧.可以认为他换个了马甲.除了resource的粒度发生了变化以外.m-r实际上就是controller跟view啊. 不过在sinatra.web.py等web dsl下.确实他们是method. rest的情况下提出RMR实际上也是对未来的web作出期许.期望web将来更加有序.(个人理解.) 接着继续对比 传统web框架与gef的异同.

request:
  springmvc; servlet容器封装view操作为request驱动整个应用运转.
  gef: 由Tools封装一些界面操作信息封装为request.框架内置一些常用request.

controller:
  springmvc: @controller处理各种request
  gef: request实际上请求给了policy.(虽然大家都知道editpart是controller.但实际上真正处理的是policy.)

view:
  springmvc: 各种模板引擎 html. flex什么的都可以.
  gef: draw2d.

model:
  springmvc: pojo.
  gef: 可以使用emf作为model. 也可以利用pojo实现IPropertySource来作为数据源.

  当然这只是gef的开始.我们还有各种command等着我们.gef内置了commandstack来帮你进行redo undo什么的.

  request => command => model 的过程.每一个图形界面的操作都会被封装为request.

  好吧.文章都快写完了还没介绍web流程设计器怎么做.嗯.忽悠的目的达到了..

  其实有一个不算很好的参考目标. jbpm的流程设计器.当然.不算太好是因为他使用了gef.然后自身封装又过于繁复.gef本身的学习曲线就已经非常高.在加上设计器本身的一层封装(在model上封装了wrapper. 有各种handler io什么的.).同时流程设计器又划分为四个小bundle.在MANIFEST.MF里面有各种bundle依赖.package导入导出什么的.导致新手接触项目就会有畏惧感. 不过做流程设计器的话扔不失为一个凑活的参考目标.(据我偷窥jbpm流程设计组的jira.貌似只有一个人在维护现有的代码了. 看到两个人的提交记录.)

  这里推荐下 八进制的gef小项目 =>gefpractice<=.  这个小项目可以说是gef的helloworld.对于理解gef有莫大的帮助.

晒图:

  图形化:

 

  源码化:

 

  我们的eclipse plugin流程设计器现在正在开发过程中.还有不少的bug.有可能的话(其实在规划之内.).会在一个时间在 淘蝌蚪上面开源.当然会连同我们的流程引擎PMC(并不是单纯的工作流.还可以结合页面流和业务流的强悍引擎.).以及基于Flex的流程设计器一起.

  最后推荐一篇eclipse gef自身的 wiki.对于了解gef的原理都有很大的帮助.

  最后的最后.我想说.eclipse v4赶快开发啊. 哥弄swt实在是抗不住了...