Good to see that you are agree with me at least in something.. about your other points:
1 a. As you may know, casting and the use of interfaces let us (in the java world) provide support for different types of processes. So no matter which type of processes we are handling this method will always return a ProcessInstance. In your case you cast to RuleFlowProcessInstance, and that's ok, but if you have another type of process instance you should use another interface. b. I'm not sure what you mean with this, but call a method to get node instances sound pretty easy to be a developer task. c. we, as developers, iterate stuff all the times d. getNodeInstances only returns the wait state, not node in progress. e. depends on the mechanism that you choose, as you can see the WSHT module uses a client api to not do that kind of queries directly. 2. Probably you got this feeling because you think about process like things that you must continue. In drools flow this is not the common way to think about processes. Because we consider that processes are smart enough to continue them selves their executions. I see sub processes in the same way, it don't think that it's a complication. If you see how WSHT works, you will see that no matter which process is running (parentflow, subflow, subsubflow,subsubsubflow) all the human task created will be in the same human task list to be completed. I think that these "low level" (for you) APIs are enough because it let us implement a high level layer, like the one you want for each specific implementation. The problem with high level layers is that you end up with something that is not too flexible as the "low level" APIs. Feel free to implement a high level APIs and create a new project that can be used on top of drools flow. Greetings! On Fri, Apr 2, 2010 at 2:27 PM, tolitius <webaka...@gmail.com> wrote: > > yes, but: > > 1. It is too low level to be a true clean / simple client API. Instead of > something as simple as: > > "process.findWorkInProgress()" > > developers need to know to: > > a. cast the processInstance, > b. get a hold of NodeInstances > c. iterate over them > d. filter out what nodes are in progress > e. query DB for the data associated with those nodes > > 2. There is no "one view" to all the wait nodes, because of the > sub-processes, so this solution gets even hairier when there are multiple > subflows, subflows within subflows, etc.. > > That is why it is rather odd that you think these low level APIs are > enough. > > /Anatoly > -- > View this message in context: > http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WORKITEM-ID-tp607507p693482.html > Sent from the Drools - User mailing list archive at Nabble.com. > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
