[jbpm-dev] [jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor

[barteljan]

"kukeltje" wrote : 
  | That is not what I meant, I meant looking at the droolsflow editor to see how the extensibility is done there. I pretty confident an example in drools would work (I tested one myself here ;-))
  | 

I really did some SOA today, it looks like it leaves me a bit of braindead .... which is at least better than the first translation of this term.

Looking at the DroolsFlow editor is a good idea ....

I hope that I don't repeat things you already knew, but my first impression of the architecture involving workItems is the following:

DroolsFlow divides the definition of workItems in some sort of MVC concept .... 
At first there is a MVEL-Definition in your META-INF folder which describes how to represent a node type in the editor and it's abstract parameters and properties. And secondly there is a additional Representation of a WorkItem at runtime with a WorkItemHandler. Such a handler is itself a class implementing the WorkItem-Interface with a central executeWorkItem method containing your domain specific code. WorkItemHandlers are normal java objects which are intanciated by the developer and passed to a WorkItemManager at runtime. Those handlers are then notified when a process instance signals a workItem node. 

"kukeltje" wrote : 
  | Maybe a solution where the designer could pick up classes in the project and runtime adapt the pallet to those classes that are just within this project. Then just adding a jar to your project would be sufficient.
  | 

Yes adding such an option to the GPD could be a solution .... or did I miss the point again :-/ .  

"barteljan" wrote : 
  | I would prefer an option to configure it with a xml-jungle, but defaults which are using reflection or annotations ....
  | 

"kukeltje" wrote : 
  | hmmm.... where do you leave this config file then... I think it is more cumbersome than to just add a jar to your project.
  | 

Yes I fear that's true, I thought of a situation where I give a customer just the editor to create processdefinitions without a possibility of testing or executing them. It could even happen that I want him to model a process with actions which have to be implemented in the future.
In such a situation it would be a bit of annoying to provide java-classes or some stubs for him, but a config-file (even if this could be in the jbpm.config.xml) isn't really better ....


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254491#4254491

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254491