[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
15 years, 4 months
[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
15 years, 4 months