The original question:
Had a quick question on the ability to add a custom node to the designer. Checked the Jira to find that you had commented that this is already available in may 2005 - is that still valid?
Can you point me in the right direction? Have been looking at the plugin.xml for the jpdl designer and the pageflow designer (don't think the pageflow has caught up with the jpdl yet). Basically, I want to show up a custom node in the jBPM designer palette - its just a standard Node pre-associated with a specific ActionHandler and a custom icon, label, etc. Even a few on-liner descriptions of the semantic-element, notational-element, graphical-edit-parts would go a long way..
Thanks for the reply Koen.
Like I said, even a few one liners would probably go a long way in helping me. From what I have been able to figure out, we have the following structure:
- the plugin.xml defines two kinds of objects:
a) "core" objects - model or semantic elements
b) "ui" objects - also known as notation elements
- the model elements are associated with DomAdapters that serialize/deserialize the model into XML.
- the ui elements have corresponding EditParts to render them in the graphical editor or the tree view. The problem here is that the label/icon mapping is currently hard-coded in the code.
- we already have the ability to use a model element and plug it into the palette using an extension point. But am running into a fundamental problem with the XML schema itself...
The jBPM schema has elements like <fork ..> and <join ..>, whereas I think it might be more extensible if it were <node type="fork" ..> etc. Right now when my custom node gets added to the ProcessDefinitionDomAdapter, it automatically creates an XML element with the same name as the "id" of my model object in the plugin.xml.
Do you have any comments on this disconnect and the best way to solve it?
To repeat my underlying requirement: suppose I have an EmailActionHandler that I anticipate being used multiple times within a single workflow. I do not want my users to keep browsing and finding the action mapping. I want to provide a custom icon on the palette, which when placed in the flow will translate to a node with a pre-associated action-handler. (Am currently doing the pre-association by extending the Node class to create my own model object, which associates the action-handler in its constructor).
You are completely right as for what you found about the architecture of the GPD.
the dom adapters will probably be completely generic in the future; as you may have remarked much of the implementation is mere mapping information.
the editparts and their associated figures are probably the area where still a lot of work is needed to make things really pluggable. I am afraid there is at the moment no easy way to work around this problem. All the creation factories are implemented with switch statements based on instanceof logic. All this will be replaced by a generic factory that will instantiate configurable classes in the future... To plug-in your own representation, you would have to break open these factory classes. A quick patch would be for me to enable extenders of the GPD to add the label and icon information to the extension definition. If you would like this, file a JIRA issue and refer to this thread. I cannot however promise to implement this in the coming days. I think it will take at least a month before this change would make it into the codebase.
you are right also about the extensibility using the syntax. This is however a limitation of the implementation of the engine. In jBPM 4 it will probably change, but of course this does not help you now. The good news is that you can do something like you want to do with the current extension point:
<element id="mySpecialMailNode" name="node" adapterClass="org.jbpm.gd.jpdl.model.xml.MySpecialMailNodeDomAdapter" modelClass="org.jbpm.gd.jpdl.model.MySpecialMailNode"/>
I hope this helps you a little bit. However, I need to stress that the GPD and its extension mechanism are moving targets at the moment. The extension points and the API will without doubt still change in the near future. Let's keep this discussion going on so that you stay up to date with the latest changes.