Friday, October 7, 2011

use eclipse EEF as a property sheet for the Graphiti editor

I just dived into the Graphiti project recently because we needed to design a quick and simple graphical editor.
I do not want to get into a war between GMF and Graphiti but that was an opportunity to get to know this framework and GMF has proven having a steep learning curve and I did not have too much time to consume teaching GMF to our Talend colleges in China.
So I decided to make a POC for our own use case with the following requirements :

  • is must be a visual form editor.
  • it has to be very simple
  • allow infinite containment depth
  • you can specify layout to automatically place the components in the containers.
  • be able to edit the selected element properties.
So I decided to create a simple component metamodel using ecore (from the Eclipse Modeling Framework) looking like this.

I then started to follow the Graphiti tutorial available in the Eclipse help. I really invite anyone who wants to start with Graphiti to follow the tutorial, it covers a lot of features provided by Graphiti.

This blog title is about using EEF (Extended Editing Framework) so let's dive into the subject.
Graphiti default editor is able to link with an Eclipse tabbed property sheet that you may declare in your plugin.xml with the extension point. 
But you have to it all by yourself. This is where EEF comes into play, why not using the Obeo's contributed set of tools and framework to generate the tabbed property sheets automatically according to our ecore metamodel ? And indeed that is what I did.
here is a screen-cast explaining how I did it.

(here is a youtube link for those who have trouble with screecast-o-matic :

At 2mn25 there are a couple of files added that make the bridge between EEF and Graphiti.

1) The first file GraphitiEObjectFilter is a section filter to accep displaying the property sheet only when the edited graphiti business object is a EObject :

import org.eclipse.emf.ecore.EObject;
import org.eclipse.graphiti.ui.platform.AbstractPropertySectionFilter;

public class GraphitiEObjectFilter extends AbstractPropertySectionFilter {
 protected boolean accept(PictogramElement pe) {
  Object object = Graphiti.getLinkService().getBusinessObjectForLinkedPictogramElement(pe);
  if (object instanceof EObject) {
   return true;
  return false;

2) The second file extends an EEF class property sheet section implementation to return the proper EObject from the selection, because Graphiti provides a pictogram element as the selection.

import org.eclipse.core.runtime.IAdaptable;
import org.eclipse.emf.ecore.EObject;
import org.eclipse.gef.EditPart;

public class GraphitiPropertyEditionSection extends PropertiesEditionSection {
 protected EObject resolveSemanticObject(Object object) {
  if (object instanceof PictogramElement) {
   return Graphiti.getLinkService().getBusinessObjectForLinkedPictogramElement((PictogramElement) object);

  EditPart editPart = null;
  if (object instanceof EditPart) {
   editPart = (EditPart) object;
  } else if (object instanceof IAdaptable) {
   editPart = (EditPart) ((IAdaptable) object).getAdapter(EditPart.class);
  if (editPart != null && editPart.getModel() instanceof PictogramElement) {
   return Graphiti.getLinkService().getBusinessObjectForLinkedPictogramElement((PictogramElement) editPart.getModel());
  return super.resolveSemanticObject(object);

This last file would not be necessary if Graphiti would somehow provide a way to register some adapters to the pictogram element because EEF if a good citizen and the original resolveSemanticObject looks for an EObject adapter (see this issue).


PS : I'd like to thank Volker Wegert that did a GMF to Graphiti convertion of a complex form editor and gave me good advices to get me started.

1 comment:

  1. Nice blog post,
    But I should warn you that PropertiesEditionSection is deprecated in the version 1.0.0 of eef runtime.