With this commit the functionality to extend the Application model editor is augmented to allow for horizontal extension of its elements. So what does this mean?

Lars describes in his tutorial how to vertically extend the application model, that is, how to add additional model elements and provide a respective editor for it. But what if I want additional editing capabilities to already existing model elements like e.g. the command element?

This is where the new extension point org.eclipse.e4.tools.emf.ui.editors.editorTab comes into play. The following image shows an example of the current usage within the Écrit project:

We added the possibility to augment existing model elements with additional documentation artifacts – but this will become part of another blog (series) 😉

Back to the extension point. In order to use it you have to first extend this new extension point, directing it to a class extending org.eclipse.e4.tools.emf.ui.common.AbstractElementEditorContribution:

This class may look like

import org.eclipse.core.databinding.observable.value.WritableValue;
import org.eclipse.core.resources.IProject;
import org.eclipse.e4.tools.emf.ui.common.AbstractElementEditorContribution;
import org.eclipse.e4.ui.model.application.commands.MCommand;
import org.eclipse.emf.databinding.EMFDataBindingContext;
import org.eclipse.emf.edit.domain.EditingDomain;
import org.eclipse.swt.widgets.Composite;

public class blaClass extends AbstractElementEditorContribution {

@Override
public void createContributedEditorTab(Composite arg0,
EMFDataBindingContext arg1, WritableValue arg2, EditingDomain arg3,
IProject arg4) {
// create the editor tab in here
}

@Override
public Class<?> getContributableTo() {
return MCommand.class;
}

@Override
public String getTabLabel() {
return "myNewTab";
}
}

The getContributableTo denotes to what model elements the editorTab will be added (this is determined as you returned Class must be instanceof).

If you want to have a look at a more specific example, take a look at the Écrit implementation of the extension point.

Questions, comments? 🙂

In order to address model elements out of the application model itsef, and out of contributing classes, the resp. model element id is used. During development you often run into errors because of wrong id strings.

To mitigate this problem a new action, called  Export Model Ids is now available within the e4 tooling starting with this build.

On execution it selects all the element ids available within the application model, and presents it to the user:

In this table you see the type of element, the static key it is gonna have in the resulting java class, and the original id. Currently the key is built out of the element type and the element id.

After execution you should find a java file called AppModelId.java, probably containing some errors due to you using duplicate ids, such as in the following image:

There are several things I would like to change to this feature, but it seems a good start – thanks a lot to Wim for the feedbacks and reviews!

Things I would like to add/change in the future

• make the output class, package and project selectable (currently this would introduce too much dependencies)
• care for double occuring ids
• make subtrees of the application model exportable (currently the whole app model ids are exported)
• perform automatically configurable update of the target file(s)
• remove dependency to org.eclipse.jdt.core

If you have any other feedback or comments, please put them on here!