[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by kukeltje
"barteljan" wrote : "kukeltje" wrote :
| | 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.
| |
|
| I could write a simple drools-eclipse-project using some workItems if you want a simple example using the latest stable drools release (5.0.0).
| But if you have good connections to Kris, asking him would be excellent ....
|
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 ;-))
"barteljan" wrote :
| "kukeltje" wrote :
| | 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 ;-)
| |
|
| Avoiding xml-hell sounds good,but what should we do if there are classes in the classpath who are correctly annotated or implement the right interface, but which shouldn't be shown in the editor (thinking of the example nodes provided in the jmpm.jar or the jar of project x, which uses nearly the same classes, but different "action-type nodes").
|
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.
"barteljan" wrote :
| Another problem is that this means that the implementation class is needed while designing the process, which might be unwanted ....
|
Au contraire mon ami, I think you want to have them available for unittesting. Maybe they are even one and the same class (why not?)
"barteljan" wrote :
| I would prefer an option to configure it with a xml-jungle, but defaults which are using reflection or annotations ....
|
hmmm.... where do you leave this config file then... I think it is more cumbersome than to just add a jar to your project.
"barteljan" wrote :
| "kukeltje" wrote :
| | 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.
|
| Hmm .... seems like i will spend my weekend with jbpm :-P.
| More with the GPD, and be glad it is not with a SOA (depending on your native language)
"barteljan" wrote :
| I would suggest starting a new forum-thread summarizing all requirements, so that we can split them up into different jira-issues.
| Would you agree with that ?
|
Yep, or even start a wiki page... Is even better I think and just post a link in this new topic if someting changes.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254448#4254448
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254448
15 years, 6 months
[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by barteljan
"kukeltje" wrote :
| Then you are already further then I am ;-) Lets see how Koen can help, he is the 'master' ;-)
|
that sounds good ;).
"kukeltje" wrote :
| 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.
|
I could write a simple drools-eclipse-project using some workItems if you want a simple example using the latest stable drools release (5.0.0).
But if you have good connections to Kris, asking him would be excellent ....
"kukeltje" wrote :
| 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 ;-)
|
Avoiding xml-hell sounds good,but what should we do if there are classes in the classpath who are correctly annotated or implement the right interface, but which shouldn't be shown in the editor (thinking of the example nodes provided in the jmpm.jar or the jar of project x, which uses nearly the same classes, but different "action-type nodes").
Another problem is that this means that the implementation class is needed while designing the process, which might be unwanted ....
I would prefer an option to configure it with a xml-jungle, but defaults which are using reflection or annotations ....
"kukeltje" wrote :
| 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.
Hmm .... seems like i will spend my weekend with jbpm :-P.
I would suggest starting a new forum-thread summarizing all requirements, so that we can split them up into different jira-issues.
Would you agree with that ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254441#4254441
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254441
15 years, 6 months
[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by 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
15 years, 6 months
[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by barteljan
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 :-).
@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 ;).
@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.
@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.
@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 ;).
@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 ....
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 :-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254224#4254224
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254224
15 years, 6 months