Java Reference
In-Depth Information
return diagramMap.get(view.getType());
}
@Override
protected Class getNodeEditPartClass(View view) {
return shapeMap.get(view.getType());
}
}
Here again, we could replace the use of the semanticHint as the key by the
EClass of the element. The EClass can be resolved from the View using the
provided getReferencedElementEClass() method, as shown here:
private final Map<EClass, Class<?>> shapeMap = new HashMap<EClass,
Class<?>>();
{
shapeMap.put(MindmapPackage.eINSTANCE.getTopic(),
TopicEditPart. class );
}
@Override
protected Class getNodeEditPartClass(View view) {
Class clazz = null ;
final EClass eClass = getReferencedElementEClass(view);
clazz = shapeMap.get(eClass);
return clazz;
}
Taking a look at the provided DiagramEditPart class, you can see in its
createDefaultEditPolicies() method that it installs a CreationEdit
Policy . When our creation tool is selected in the palette, the Topic
IElementType is set on the tool. When the mouse hovers over the diagram, the
installed CreationEditPolicy on the DiagramEditPart receives a
CreateViewAndElementRequest and returns a CompositeCommand contain-
ing a SemanticCreateCommand . Because we haven't specified the containment
feature of our Map class in which to hold new Topic objects, the runtime uses
the PackageUtil.findFeature() method to discover one. In our case, only
one is appropriate: the elements containment reference. If there were multiple
options, or if we wanted to explicitly declare the containment feature, we could
provide our own EditPolicy that would set the containment feature on the
request before creating the command. Or we could add an EditHelper for the
Map class that would return the proper containment feature by overriding the
getDefaultContainmentFeature() method.
Search WWH ::




Custom Search