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

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

当jbpm4在N年以后终于推出了自己的[url=http://www.signavio.com/en/]"羚羊"[/url]的时侯,我们却要从已有的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类加载机制:

[img]http://dl.iteye.com/upload/attachment/305743/924cf13c-8782-3e1f-b587-d30889bc60e8.jpg[/img]

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.然后分出了各种层来确保安全.服务的完整性等等.. 在这里推荐想深入了解的阅读[url=http://www.osgi.org/download/r4v42/r4.core.pdf]osgi规范[/url].其实开发插件只需要了解MANIFEST.MF文件寻找bundle的机制.以及export import package的规则就可以了.了解之后能避免很多不必要的时间浪费.

附图:

bundle状态转换图:

[img]http://dl.iteye.com/upload/attachment/305747/6f8b16b4-fd7f-382a-b103-43d55810c343.jpg[/img]

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

web模式的mvc中view请求经历了servlet/rack/...等的一次封装.将http请求封装为了"request".以至于大家可以处理.当然.在非web模式的mvc框架中.gef也存在这样的东西. 同样将界面操作自身封装为"request"以供policy接收并处理.这种类型的匹配也是师出同门.所以有必要将他们进行小小的对比.
附:在rest大行其道的今天.有人提出了一个新的架构[url=http://www.peej.co.uk/articles/rmr-architecture.html]RMR[/url]. 嗯.就是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.貌似只有一个人在维护现有的代码了. 看到两个人的提交记录.)

这里推荐下[url=http://www.cnblogs.com/bjzhanghao/]八进制[/url]的gef小项目[url=http://files.cnblogs.com/bjzhanghao/gefpractice.zip]=>gefpractice<=[/url]. 这个小项目可以说是gef的helloworld.对于理解gef有莫大的帮助.

晒图:

图形化:

[img]http://dl.iteye.com/upload/attachment/305735/d94200d3-27a6-33f7-bd9b-208ede535f83.jpg[/img]

源码化:

[img]http://dl.iteye.com/upload/attachment/305737/cc9af3dd-6780-3147-9d1a-71249a2a4f0c.jpg[/img]

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

最后推荐一篇eclipse gef自身的[url=http://wiki.eclipse.org/GEF_Description]wiki[/url].对于了解gef的原理都有很大的帮助.

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