该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-07-13
最后修改:2009-07-30
javaeye 是25票良好的~~?
。。。投了个良好,结果眼睁睁看见一个良好贴出现,没有看到25票的字样,失望。。 |
|
返回顶楼 | |
发表时间:2009-07-30
beast里用到了acts_as_state_machine
|
|
返回顶楼 | |
发表时间:2009-07-30
近期一直在研究工作流,看WFMC,看SHARK/OSWORKFLOW/OBE,头都大了
从常用的模型来看,FSM比Petri Nets更好理解和使用 现在有点返璞归真的意味,在狂看Event-Driven FSM资料,痛并快乐着…… |
|
返回顶楼 | |
发表时间:2009-08-07
liusong1111 写道 如果一个状态结点,参与者很多,逻辑很复杂(比如80%的参与者处理后则进入下一结点),就需要用workitem了。
如果有workitem,就肯定需要持久化,因为这是跟人工操作有关的。 状态变迁、过程流转,如果涉及人工结点,就会伴随着workitem的分配、取消、查询计算等操作,但workitem代表的是授给一个人的任务,更贴近业务,与状态机本身无关(所以通常作为外接模块)。 一个流程的流转,可以认为是用token驱动的:一个串发流程在流转过程中,始终只有一个token向下传递,无论那个结点可能有几个参与者。 split-join从一个token生成了多个子token,最终又将其合并。 复杂的流程就是用token树驱动的,而不是workitem驱动。 --忘了这个观点从哪看来的,是不是与jbpm还是PetriNet有关了,我在工作流的理论上研究的不深。 一个串发流程在流转过程中,始终只有一个token向下传递,无论那个结点可能有几个参与者。 一个结点有多个参与者,也只有一个token,怎么进行驱动的? |
|
返回顶楼 | |
发表时间:2009-08-07
最后修改:2009-08-07
ActiveModel::StateMachine 已经集成到 Rails3 里面了
josh两天前的commit http://github.com/rails/rails/commit/aad5a30bf25d8a3167afd685fc91c99f4f09cc57 Add simple support for ActiveModel's StateMachine for ActiveRecord 更详细的讲解看 http://blog.envylabs.com/2009/08/the-rails-state-machine/ The Rails State Machine |
|
返回顶楼 | |