JWT ExtensionsThis page provides information on how to extend the JWT Workflow Editor (JWT-WE) through plugins. OverviewThe JWT Workflow Editor defines several extension points and mechanisms that allow users to customize and extend the abilities and properties of JWT-WE without changing the editor itself. However, there may be cases in which it becomes necessary to alter the Workflow Editor code itself, notably when the new features need to be implemented by committers of the JWT project. This page is intended to describe how third party suppliers can extend JWT-WE (e.g. with custom views on the model elements) through external plugins using the defined extension points (if you're instead looking for tutorials on how to modify the Workflow Editor or how to directly implement new features, please take a look at JWT_Modifications). Extending JWT-WE through PluginsThe JWT-WE PlatformThe Workflow Editor can be extended using standard Eclipse extension points and it also defines several new extension points. Adding Actions to Menu/ToolbarNew actions can be added to the Workflow Editor using the org.eclipse.jwt.we.menu extension point. It is then added to the WE toolbar as a selectable option in the External Functions dropdown menu. If the editor is run in RCP mode, an additional entry in the main menu bar is created. The action itself has access to several resources of the editor and the loaded model.
Help methods available in WEExternalAction are:
Additional interesting points for plugin developers:
The required steps to register one ore more actions with JWT-WE are:
If you want to listen to selection changes, WEExternalActions are already ISelectionListener but you have to make it listen to them by adding this code to your own WEExternalAction : Plugin.getInstance().getWorkbench().getActiveWorkbenchWindow().getSelectionService().addSelectionListener(this); To register the external actions shown above, you will need to add the following code to your plugin.xml: <extension id="org.eclipse.jwt.we.menu" name="org.eclipse.jwt.we.menu" point="org.eclipse.jwt.we.menu"> <action class="org.eclipse.jwt.we.ExternSample.actions.SampleAction1" description="Sample1 Description" forceText="false" name="Sample1" requiresOpenEditor="true" showInMenu="true" showInToolbar="true"/> <action class="org.eclipse.jwt.we.ExternSample.actions.SampleAction2" description="Sample2Description" forceText="true" name="Sample2" requiresOpenEditor="true" showInMenu="true" showInToolbar="false"/> <action class="org.eclipse.jwt.we.ExternSample.actions.SampleAction3" description="Sample3 Description" forceText="true" name="Sample3" requiresOpenEditor="true" showInMenu="false" showInToolbar="true"/> <action class="org.eclipse.jwt.we.ExternSample.actions.SampleAction4" description="Sample4 Description" forceText="true" name="Sample4" requiresOpenEditor="false" showInMenu="true" showInToolbar="true"/> </extension> Example plugin for defining external actions (org.eclipse.jwt.we.ExternSample):
Adding ViewsThe Workflow Editor can be extended with views that allow to customize how the model is displayed. JWT comes with a technical, business, Event-driven Process Chains and an UML Activity view. Views must be registered through the org.eclipse.jwt.we.view extension point. How to create external views:
A FactoryRegistry allows to provide a custom Palette, FigureFactory, EditPartFactory and ImageFactory thereby enabling to completely change the layout of the displayed mode. Adding Editor sheetsThe Workflow Editor is of the type MultiEditorPart and thus may contain multiple editors which are represented as independet sheets. JWT-WE already contains two built-in editor sheets:
Through the extension point for external editor sheets, it is possible to integrate your own editors into JWT-WE. They can be opened automatically when loading a workflow model or manually using the context menu of the Workflow Editor. The sheet must be provided to the Workflow Editor through an IWEExternalSheetProvider, i.e. a class must be created that implements org.eclipse.jwt.we.editors.pages.externalSheet.IWEExternalSheetProvider. This interface contains two methods:
The required steps to register one ore more sheets with JWT-WE are:
If you want your editor sheet to be notified about changes in the model, you'll need to implement org.eclipse.emf.common.notify.Adapter and add your sheet as listener to the main model element of the editor ((EObject)editor.getModel()).eAdapters().add(this) and remove the listener in thedispose() method. To register the external sheets as shown above, you will need to add the following code to your plugin.xml: <extension id="org.eclipse.jwt.we.sheet" name="Example" point="org.eclipse.jwt.we.sheet"> <sheet autoshow="true" class="org.eclipse.jwt.we.plugins.sheetexample.sheets.ExampleSheet1SheetProvider" closable="false" multiple="false" title="%sheet_Example1_title"> </sheet> <sheet autoshow="true" class="org.eclipse.jwt.we.plugins.sheetexample.sheets.ExampleSheet2SheetProvider" closable="true" multiple="true" title="%sheet_Example2_title"> </sheet> </extension> The example plugin for defining external editor sheets (org.eclipse.jwt.we.plugins.sheetexample):
Adding Property Sheet PagesThe workflow editor contains support for a multi-tab property sheet (TabbedPropertiesView) which is only activated if additional tabs are provided by plugins. If this is not the case, the classical property sheet is used which does not display any tabs. If the multi-tab sheet is used, a single tab Standard is always shown, which contains the model element properties as would be normally shown in the classical property sheet. To add a new property sheet page to the editor, it is necessary to define a new property tab in the plugin.xml and fill it with one or more property sections. The implementation of property sections is described in this Eclipse article. Once the property section have been implemented, they can be registered with the property tab. The required steps to create one ore more new property tab(s) are:
The required steps to register property sections with the newly defined tab(s) are:
The following excerpt from plugin.xml shows the definition of a new property tab (Advanced) that contains only one section (implemented in org.eclipse.jwt.we.propertiesexample.sections.AdvancedPropertySection). The new property tab is only activated if a model element of the typeorg.eclipse.jwt.we.model.processes.ActivityNode is selected. <extension point="org.eclipse.ui.views.properties.tabbed.propertyTabs"> <propertyTabs contributorId="org.eclipse.jwt.we.editors.WEEditor"> <propertyTab afterTab="org.eclipse.jwt.we.propertytabs.Standard" category="WEStandardCategory" id="org.eclipse.jwt.we.propertytabs.Advanced" label="%properties_Advanced_label"> </propertyTab> </propertyTabs> </extension> <extension point="org.eclipse.ui.views.properties.tabbed.propertySections"> <propertySections contributorId="org.eclipse.jwt.we.editors.WEEditor"> <propertySection class="org.eclipse.jwt.we.propertiesexample.sections.AdvancedPropertySection" enablesFor="1" id="org.eclipse.jwt.we.propertysections.Advanced" tab="org.eclipse.jwt.we.propertytabs.Advanced"> <input type="org.eclipse.jwt.we.model.processes.ActivityNode"> </input> </propertySection> </propertySections> </extension> Adding an import or export transformationAdding a new Double click handlerDescriptionThe extension point org.eclipse.jwt.we.doubleclick allows you to add an handler for double clicks event on model elements, Behavior
CodeTODO when committed Adding a new DropTargetAdapterDescriptionThe extension point org.eclipse.jwt.we.dnd allows you to add TransferDropTargetListener to the activity diagram editor and to the Outine tree. You simply have to plus to this extension point a factory that creates the TransferDropTargetListener for the workflow editor. Behavior
CodeTODO when committed Adding Custom PropertyDescriptor (and editors) in property sheetsDescriptionThe aim of this extension is to provide the ability to use a different Property Editor than the default one provided by EMF. This can be used for example to facilitate the input of data by proposing choices instead of letting user type something (reduce error risks). The extension point is named org.eclipse.jwt.we.propertyDescriptor, it is made of:
For each property descriptor that should be different than the original, you need to extend the predefined extension point as follows: <extension point="org.eclipse.jwt.we.propertyDescriptor"> <customPropertyEditor PropertyDescriptorFactoryImpl="de.uniAugsburg.project.ProjectSpecificPropertyDescriptorFactory" className="NameOfTheClassInEMF" featureName="NameOfTheFeatureThatIsSpecifiedInTheMetamodelOrConfModel" packageName="de.uniAugsburg.project> </customPropertyEditor> </extension> In my example "NameOfTheClassInEMF" is a subclass of AspectInstance and provides the feature "NameOfTheFeatureThatIsSpecifiedInTheMetamodelOrConfModel". The factory is pretty simple. It looks as follows: public class ProjectSpecificPropertyDescriptorFactory implements
PropertyDescriptorFactory {
public IPropertyDescriptor getPropertyDescriptor(Object object, IItemPropertyDescriptor itemPropertyDescriptor) {
return new ProjectSpecificPropertyDescriptor(object, itemPropertyDescriptor);
}
}
The ProjectSpecificPropertyDescriptor extends the EMF PropertyDescriptor and overrides the createPropertyEditor method. In this case it creates an own ProjectSpecificDialogCellEditor: public class ProjectSpecificPropertyDescriptor extends PropertyDescriptor {
public ProjectSpecificPropertyDescriptor(Object object, IItemPropertyDescriptor itemPropertyDescriptor)
{
super(object, itemPropertyDescriptor);
}
@Override
public CellEditor createPropertyEditor(Composite parent) {
ProjectSpecificDialogCellEditor cellEdit =
(ProjectSpecificDialogCellEditor) new ProjectSpecificDialogCellEditor(parent, getLabelProvider(), "");
return cellEdit;
}
}
In this case the ProjectSpecificDialogCellEditor extends the ExtendedDialogCellEditor and simply opens a dialog box. Behavior
Utils
Example / Code
HowTo / WinkTODO Use cases
Adding NotificationChangeListener when a value is changed in EMF ModelDescriptionThe aim of this extension is to provide the ability to listen to changes of EMF values of EMF Model and then to run a piece of code according to the notification. For example, automatically generate an alert when a value does not fit a constraint, or automatically set a property value according to the one that just changed (eg set parameters of an application according to the choosen method signature) The extension point org.eclipse.jwt.we.changeListener is defined by:
BehaviorA notification listener on a feature is applied to feature of specified class and subclasses. When several extensions associates a change listener to the same feature, then all listeners will run their notifyChanged method when notified in an order that can not be previwed. Code / ExampleTODO when commited Demo / Howto / WinkTODO Use cases
Adding Meta Model ExtensionsSee JWT_Metamodel_Extension :
See also |
|
|
