| Making sense of listeners in DiagramEditor [message #734464] |
Fri, 07 October 2011 21:24  |
 Hernan Gonzalez
Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina |
Senior Member |
|
|
I'm trying to understand all the listeners/adapters in DiagramEditor/DiagramEditorBehavior, I'll post some summary here for developers reference when I have it more clear.
In particular, in DiagramEditorBehavior:
updateProblemIndication keeps updated the resourceToDiagnosticMap by reacting to notifications that are related to errors in a resource (errors/warnings and also loading)
updateAdapter reacts when some Resource notifies that it has been unloaded (it then tries to close the editor or to reload everything)
Now, updateAdapter is a AdapterImpl, is added to each resource at creation time
(resourceSetUpdateAdapter is another AdapterImpl that is added to the ResourceSet, it reacts in case a Resource is added or removed [can this happen currently in Graphiti? I wonder]; it adds or removes the updateAdapter to it)
updateProblemIndication instead is a EContentAdapter, an adapter that can attach itself to children. It is added to the ResourceSet, and hence it attaches itself to the Resources.
I scratched my head quite a bit trying to understand why it didn't also attached to all the objects as it should (in which case even moving a shape should trigger a notification - it doesn't) till I discovered that the overriden method setTarget(Resource target) does the trick. This, however, does not avoid the attachment of the adapter to new (business) objects. Nothing tragic, but slightly wrong (and easy to fix).
But I wonder why the complication: if both updateProblemIndication/updateAdapter are intended to be always attached to the Resources, wouldn't be more logical and clean they be both either AdapterImpl or EContentAdapter and have the same attaching/detaching logic? (I would tend to the former in this case)
[Updated on: Fri, 07 October 2011 21:25] Report message to a moderator |
|
|
|
| Re: Making sense of listeners in DiagramEditor [message #736215 is a reply to message #734464] |
Thu, 13 October 2011 20:30  |
Hernan Gonzalez
Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina |
Senior Member |
|
|
Some more related doubts/discoveries/tidbits:
In DiagramEditorInternal we have 4 listeners:
1 cmdStackListener: CommandStackEventListener (GEF)
2 fwListener: FWCommandStackListener -> CommandStackListener (EMF)
Both listen for changes in the commandstack (in the GEF and EMF worlds respectively) and trigger firePropertyChange(IEditorPart.PROP_DIRTY);
3 domainModelListener (DomainModelChangeListener)
4 diagramChangeListener (DiagramChangeListener)
Both are registered (registerBOListener() and registerDiagramResourceSetListener() ) as ResourceSetListener with the editing domain (this mean they react after a EMF transaction commit)
domainModelListener is supposed to react to changes in the Domain objects, and invoke Update (to update the diagram) if appropiate
diagramChangeListener is supposed to react to changes in the Diagram, to refresh the display (GEF/Draw2d)
I hope I got it right. 
Some doubts:
1. The comment on registerDiagramResourceSetListener() says:
* Register diagram change listener. Since the diagram comes from a
* ModelEditorInput and ModelEditor input provides an own ResourceSet for
* every editor instance, we can safely register a listener with the provided
* ResourceSet: we will be notified only by events regarding the diagram!
This seems pretty false (outdated?) to me. All scenarios I've considered so far in Graphiti involve one single EditingDomain and hence a single ResourceSet, that is shared for Diagram and model objects. Hence, this listener will react to diagram AND BO objects... (supposedly the method isGraphitiMmObject() inside it will filter the irrelevant notifications).
2. The same for domainModelListener : it will listen not only for BO changes but also for Diagram changes - This might not be a bug, I guess the method calculateRelatedPictogramElements() implicitly ignores out the unwanted non-BO objects. Anyway, the comments are a bit misleading
( eg: "// Compute changed BOs." ; actually we are working with all modified objects, aslo pictograms, etc).
I also guess the performance penaly is not important (right?).
3. It's also not very clear for me the interaction of these trigerred updates with those done explicitly. Example: in the tutorial, I program a DirectEditingFeature that modifies the name of EClass; this is a modification in a BO, that we be caught by the listener and supposedly invoke the pictogram update. Does this mean that I do not need to explicitly do the update in in my feature? It did not work for me. [EDITED: my bad, it worked] Further, the comment in the tutorial seems to point to a related doubt:
// Explicitly update the shape to display the new value in the diagram
// Note, that this might not be necessary in future versions of Graphiti
// (currently in discussion)
In a (my) "model only" scenario, in which the diagram is not stored but recreated on loading (and the BO includes the basic graphic info: locations and sizes) this can turn more problematic:
I had programmed a MoveShapeFeature that updates the diagram and the BO position (seemed straightforward). Now I see that this will awake the domain listener (for each move!) which will call the updatefeature each time to update the pictogram position... Again, not a tragedy, but anyway, it's good to be aware...
[Updated on: Thu, 13 October 2011 21:11] Report message to a moderator |
|
|
|
Powered by
FUDForum. Page generated in 0.03943 seconds
] 
Search
Help
Register
Login
Home
