GPD extension point changes
koen.aers Mar 23, 2007 6:02 AMHi all,
Because of the need to specify the icon and label in a more flexible manner and the inability of the JpdlLabelProvider class to handle this, I have done some work on the extension points the last two weeks. As I expected, this resulted in a lot of refactoring and even in a complete revision of the two plugins. I have merged the 'org.jbpm.gd.jpdl.core' and the 'org.jbpm.gd.ui' plugin in one single plugin that is called 'org.jbpm.gd.jpdl'.
If you checkout this project you will see that some extension points have changed and that I added some new ones.
The first big change is that you now are able to contribute DSLs by using the 'org.jbpm.gd.jpdl.dsl' extension point. This dsl will be associated with an editor that is contributed to the 'org.eclipse.ui.editors' extension point. The association between the dsl and the editor still needs a lot of work. The idea is that you will derive from a class which has already a lot of the glue defined.
After you defined the DSL and have associated it with the editor, you can start contributing the semantic elements of this dsl by using the 'org.jbpm.gd.jpdl.semanticElements' extension point. As you can see, you specify for each contributed semanticElement to what DSL it belongs. For jpdl, the semantic elements are actions, nodes, swimlanes, etc. You can specify a label and an icon and of course an implementing class in the extension definition.
The third novelty is to define a mapping to the generated xml by using the 'org.jbpm.gd.jpdl.xmlMappings' extension point. Here you specify the implementing xml adapter class and the xml element that corresponds to the semantic element.
I think these changes will improve the flexibility a lot and make the plugin ready for complete pluggability of DSLs. Things that still have to be reviewed are as already said the Editor class itself but also the palette and editparts which should also be made completely pluggable. I will first try to get back to my planned roadmap and finish the jPDL language support.
In the future you can also expect a split (again!) of the plugin to isolate the common base classes that are the same for each DSL in a 'org.jbpm.gd.common' plugin.
Thoughts?
Regards,
Koen