[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by kukeltje
Custom example from the 'examples':
| <custom name="print dots"
| class="org.jbpm.examples.custom.PrintDots"
| g="96,16,100,52">
|
| <transition to="end" />
| </custom>
|
Needs a class. That has to be in the classpath from somewhere, so having this just as a xml file is (imo) impossible, you need the class somewhere for unittests and it needs to go in the .bar (jar currently) or whatever. So you need it *anyway* and why not combine the two and have it one class. But keep in mind, ONLY for this specific custom example which would satisfy lots of users and a pom.xml could/should be used for resolving the runtime dependencies or do I miss something?
Regarding the 'issues' about moving workspaces etc, you are right, but just like Jan mentions, I also think that not having a bloated (excusez le mot) pallet if there are to many 'nodes' on a high level in the GPD.
And it does not mean the more specific realy new nodes (elements) should be impossible, au contraire...
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254580#4254580
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254580
16 years, 1 month
[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by kukeltje
"koen.aers(a)jboss.com" wrote : "barteljan" wrote : 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 ....
| |
| The only good solution in my opinion is a plugin-based solution. IE every node you want to contribute is an extension to the extension point that defines how to add new nodes to the editor.
|
Yes
"koen.aers(a)jboss.com" wrote :
| The different elements of information that are needed to do this in its most simplified form are:
| - a description of the node that has to be added (the properties of the node)
| - how to serialize the node
| - how to deserialize the node
| Additionally the following elements are optional:
| - description of the figure representing the node
| - the icon and/or text that have to appear in the palette
| - the path in the palette where they have to be added
|
| Of course, you can even more generalize the possible extensions by defining a generic node type what is always serialized/deserialized in the same way and of which the properties are simple attributes and/or some well-known child elements. In this case the 'pure' xml solution comes in the picture.
|
Or one where you can implement a specific interface and/or annotations or both (not sure what is easier to find/parse classpath wise, maybe something like seam does)
"koen.aers(a)jboss.com" wrote :
| Nevertheless, I have a preference of describing these extensions in the plugin.xml of a plugin that adds these custom nodes instead of adding a jar file containing these xml files somewhere on the classpath (either by configuring a preference in the workspace or adding a jar file in a projet).
|
For the element-name based extensions I agree, for the generic (custom) node type extension I don't. Not having to know anything about eclipse plugins, distributing your own ones and still be able to create 'extensions' is a (u)sp
"koen.aers(a)jboss.com" wrote :
| The latter solution (including the xml config in a jar file) is a more specific case of the former one. The former solution is not yet completely implemented at present. Roughly the following things need to be done first:
| - define an extension point for serialization/deserialization
| - define an extension point for the palette items
|
| If you want to dive deeper into this, take a look at the Registry class in the package org.jboss.tools.flow.jpdl4.io and the JpdlPaletteFactory class in the org.jboss.tools.flow.jpdl4.editor package. The first step is to refactor these two classes and let them do their job based on information that is contributed in the plugin.xml by extensions of two new extension points. Another thing that you definitely want to look into is the already existing extension point for adding elements to the GPD (defined in the plugin.xml of the org.jboss.tools.flow.common plugin and used in the plugin.xml fo the org.jboss.tools.flow.jpdl4 plugin). It will show you how to create and use extension points. More in particular the class ElementRegistry in the package org.jboss.tools.flow.common.registry will be a good source of information.
| I'll have a look to"koen.aers(a)jboss.com" wrote :
|
| I'll add a reference to this thread to GPD 292 and we can continue the discussion there. Also feel free to attach patches if you're fiddling around (or happen to define the extension points) so that i can test them. Make sure you sign the contributor's agreement if you're going to do this.
|
| Cheers,
| Koen
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254536#4254536
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254536
16 years, 1 month
[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by koen.aers＠jboss.com
"barteljan" wrote : 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 ....
|
The only good solution in my opinion is a plugin-based solution. IE every node you want to contribute is an extension to the extension point that defines how to add new nodes to the editor.
The different elements of information that are needed to do this in its most simplified form are:
- a description of the node that has to be added (the properties of the node)
- how to serialize the node
- how to deserialize the node
Additionally the following elements are optional:
- description of the figure representing the node
- the icon and/or text that have to appear in the palette
- the path in the palette where they have to be added
Of course, you can even more generalize the possible extensions by defining a generic node type what is always serialized/deserialized in the same way and of which the properties are simple attributes and/or some well-known child elements. In this case the 'pure' xml solution comes in the picture. Nevertheless, I have a preference of describing these extensions in the plugin.xml of a plugin that adds these custom nodes instead of adding a jar file containing these xml files somewhere on the classpath (either by configuring a preference in the workspace or adding a jar file in a projet).
The latter solution (including the xml config in a jar file) is a more specific case of the former one. The former solution is not yet completely implemented at present. Roughly the following things need to be done first:
- define an extension point for serialization/deserialization
- define an extension point for the palette items
If you want to dive deeper into this, take a look at the Registry class in the package org.jboss.tools.flow.jpdl4.io and the JpdlPaletteFactory class in the org.jboss.tools.flow.jpdl4.editor package. The first step is to refactor these two classes and let them do their job based on information that is contributed in the plugin.xml by extensions of two new extension points. Another thing that you definitely want to look into is the already existing extension point for adding elements to the GPD (defined in the plugin.xml of the org.jboss.tools.flow.common plugin and used in the plugin.xml fo the org.jboss.tools.flow.jpdl4 plugin). It will show you how to create and use extension points. More in particular the class ElementRegistry in the package org.jboss.tools.flow.common.registry will be a good source of information.
I'll add a reference to this thread to GPD 292 and we can continue the discussion there. Also feel free to attach patches if you're fiddling around (or happen to define the extension points) so that i can test them. Make sure you sign the contributor's agreement if you're going to do this.
Cheers,
Koen
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254509#4254509
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254509
16 years, 1 month
[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by 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
16 years, 1 month