updateNeeded preconditions [message #1067530] |
Tue, 09 July 2013 08:56 |
Albert Hofkamp Messages: 41 Registered: August 2009 |
Member |
|
|
While adding an update feature, I had a crash in updateNeeded() when opening an editor with an existing Automaton object.
The update feature functions of interest are wrapper functions to the real handler:
@Override
public boolean canUpdate(IUpdateContext context) {
return autHandler.canUpdate(context.getPictogramElement());
}
@Override
public IReason updateNeeded(IUpdateContext context) {
boolean un = autHandler.updateNeeded(context.getPictogramElement());
return un ? Reason.createTrueReason() : Reason.createFalseReason();
}
The real handler functions are then
@Override
public boolean canUpdate(PictogramElement pe) {
IPeService pes = Graphiti.getPeService();
String val = pes.getPropertyValue(pe, AutomatonEditorData.AUT_ELEMENT);
System.out.printf("canUpdate kind=%s val=%s pe=%s\n", kind, val, pe);
return AutomatonEditorData.isOuterElement(pe);
}
@Override
public boolean updateNeeded(PictogramElement pe) {
IPeService pes = Graphiti.getPeService();
String val = pes.getPropertyValue(pe, AutomatonEditorData.AUT_ELEMENT);
System.out.printf("updateNeeded kind=%s val=%s pe=%s\n", kind, val, pe);
Assert.check(AutomatonEditorData.isOuterElement(pe));
AutomatonEditorData aed = new AutomatonEditorData(pe, fp);
Object obj = AutomatonEditorData.getAutomaton(pe);
return aed.updateElements(obj, false);
} In both functions, code below the empty line is the original code, code above the empty line is debugging code, which basically dumps the data that is being checked in isOuterElement().
As you can see, the check in canUpdate() is mirrored as assertion in updateNeeded(). The reason is that I interpreted the tutorial description of the update feature as such.
Quote:In this case we have to implement/overwrite 3 methods:
* The method canUpdate has to check whether the values of the current pictogram element of the given context can be updated.
* The method update has to ...
* The method updateNeeded has to check whether the values in the pictogram element are up to date, that means whether the graphics algorithm of this pictogram element contain the latest values from the business objects.
To me this reads as canUpdate() acts as check whether the given element can be handled, and updateNeeded may assume it is given sane elements only.
Apparently, this is not true. The debugging output says
updateNeeded kind=Plant val=outer_aut pe=org.eclipse.graphiti.mm.pictograms.impl.ContainerShapeImpl@1536152 (visible: true, active: true)
updateNeeded kind=Plant val=name_aut pe=org.eclipse.graphiti.mm.pictograms.impl.ShapeImpl@187f133 (visible: true, active: true)
<crash due to assert failure at the "Assert.check" line>
The first line is the outer element I intended to handle.
The second line is a shape I didn't expect. It is a linked shape though, so I can see why Graphiti would want to verify it.
I consider this a bug in my own code, I should extend the update feature to handle this shape as well.
What worries me however is the fact that canUpdate() is never even consulted. Is that intended behavior? What if I ever decide to handle the "name_aut" shape (the 2nd call) in another feature?
This behavior seems to imply that the checks in canUpdate() have to be duplicated in updateNeeded().
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03629 seconds