Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » Making sense of listeners in DiagramEditor
Making sense of listeners in DiagramEditor [message #734464] Fri, 07 October 2011 21:24 Go to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 181
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 #734872 is a reply to message #734464] Mon, 10 October 2011 08:47 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1640
Registered: July 2009
Location: Walldorf, Germany
Senior Member
Both adapters (updateAdapter and problemIndictaionAdapter) focus on
different aspects as you worked out. Hanving a look at that, I also wonder
if the problem indication adapter still needs to be a content adapter
(getting notifications on all tree changes and getting added to all EMF
objects in the tree). It used to make sense because in our old modeling
environment (MOF based) we had the possibility to add Eclipse problems to
any kind of model object. As far as I know with EMF Graphiti only supports
problem indications on resource level. So if I'm not wrong, this might be a
standard adapter now as well...

As I wrote, I'm not fully sure about that, so anybody please correct me in
case I'm not...

Michael
Re: Making sense of listeners in DiagramEditor [message #736215 is a reply to message #734464] Thu, 13 October 2011 20:30 Go to previous messageGo to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 181
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. Smile
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

Re: Making sense of listeners in DiagramEditor [message #758927 is a reply to message #736215] Fri, 25 November 2011 10:28 Go to previous message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1640
Registered: July 2009
Location: Walldorf, Germany
Senior Member
Hernan,

I have opened a bug as split-off form the editor discussion itself to track
this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=364803

Regardsing the comments, what you mentioned below is correct, at least the 1
comment is wrong. The second one might be misleading but at least bears some
truth (although it is checked only inside).

Michael
Previous Topic:Selection Listeners
Next Topic:Diagram Editor and its API
Goto Forum:
  


Current Time: Sat Dec 20 01:36:39 GMT 2014

Powered by FUDForum. Page generated in 0.09553 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software