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