"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#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...