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

[kukeltje]

"barteljan" wrote : Hi :-),
  | 
  | At first thank you for your detailed comments about this task,
  | i'm trying to answer every point, please alert me if I miss one :-).
  | 
We will 

"barteljan" wrote : 
  | @add extensibility to jpdl schema
  | Althought I like the idea of an extendable schema  for jpdl,I suspect this task is a bit of to much for our purpose, extending the schema means extending jpdl, which itself means extending the jpdl-core-engine. Since we want to use jbpm because of it's current stability, a modification of the engine itself should be avoided, because it holds a great danger for nasty bugs, which could be avoided by the "custom node approach". (Second approach noted by Ronald). I would prefer this approach because it looks like the easiest way to achieve extendebility. I would change my opinion if there are good arguments for doing that ;).
  | 

That would be my preference to. At first sight it indeed would leave the core as it is. 
And it comes closest to what would be needed for BPMN2 as well. 

"barteljan" wrote : 
  | @BPMN2
  | I have to read more about it ....
  | although I would propose to use an already existing node-type (java or custom),
  | a new "service"-node would be  acceptable for me.
  | 
I think it is not needed since the custom node (jpdl) and the service node (bpmn2) are close enough.

"barteljan" wrote : 
  | @specific node fuctionality
  | I'm not quite shure what you mean with "generic", although we need a domain specific representation of our nodes (a stupid User should be able to differentiate two different "action-types" by sight ), It would be absolutly sufficient if those two different "action-types"  are representated by the same node-type on xml-level.
  | And at last I suppose that there should be a generic approach for adding such action-types.
  | 
With generic I meant an esb, ftp, ws, .... node, but I agree on the 'action-types' 
 
"barteljan" wrote : 
  | @eclipse development
  | My knowledge of eclipse-plugin-developement is quite limited,
  | I know the concept of an extension point, but I wouldn't be able to define one,
  | but this can be changed ;).
  | 
Then you are already further then I am ;-) Lets see how Koen can help, he is the 'master' ;-)

Might be interesting to also have a look at the RuleFlow editor (not sure if all the latest things are in the drools or jboss tools svn or there at all). Since we seem to be going to borrow/share something that Koen had an idea for a long time ago and Kris seems to have implemented it in quite a nice a way.

"barteljan" wrote : 
  | @timeline
  | We are calculating with about two days for jbpm-developement per week,
  | starting with evaluating the basics and targets in september.
  | Active programming could start in october, hoping about first eyecatchers in november and a nearly working solution in december ....
  | But that's only a rough calculation .... more time could be afforded if it is needed ....
  | 
The next release of jBPM is scheduled for the 1st of November, with a code freeze (at least of the core) 2 weeks before, so that seems a bit to early. But the next release of january 1st could be a nice target. 
"barteljan" wrote : 
  | Thank you for your comments and your time,
  | 
  | Jan
  | 
  | P.S. I will configure and co the svn in the next days and cry for your help if I can't manage that :-)  
  | 

Don't cry, it is better to shout it out loud, at least that would be my preference and I think Koen agrees. 

So to summarize:

We need a way to specifiy
- A node type (name)
- reference to a pallet icon
- reference a node icon (process diagram level but could be the same as the palet icon)
- a reference to a custom node implementation (java class) that has to be included in the process archive
- some way to edit 'properties' of this node in a user friendly way (non-xml)

Designing these should be almost as easy as  defining custom node, maybe by having the class implement a specific interface and find all implementing classes via reflection or use annotations or whatever and add them to the pallet on runtime. No XML hell... right ;-)

Would be good if we could break up all these things in jira and maybe some underlying things for Koen so it is clear what needs to be done etc.

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

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