Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » DefaultMarkerBehavior woes
DefaultMarkerBehavior woes [message #1384000] Tue, 27 May 2014 19:03 Go to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 181
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
It took me some time to troubleshoot why my Eclipse editor removed all my problem markers on opening. Then I found that the DiagramBehaviour has a DefaultMarkerBehavior that has this code:

  void updateProblemIndication() {
     ...
     if (markerHelper.hasMarkers(resourceSet)) {
      markerHelper.deleteMarkers(resourceSet);
     }
     if (diagnostic.getSeverity() != Diagnostic.OK) {
        markerHelper.createMarkers(diagnostic);
     ...
     }
   }
  }


This looks objectionable in that:

- Isn't there a more cooperative way of adding its own problem markers, without deleting all (including perhaps problems from other participants)?
I'm not sure about the (non Graphiti) markerHelper.hasMarkers() doc: "Returns whether the a maker with id equals to the return of getMarkerID() " (and that method is private!), I'm not sure who sets that id, and if all "Problem" markers must share it or not.

- If I want to disable that behaviour (assuming I'm not interested in marking those EMF problems), I guess the way is to override MyDiagramBehaviour.createMarkerBehavior() . Sadly, that is less extensible than in looks, because it (as all DiagramBehaviour.create***Behaviour()) returns a concrete class instead of an interface, so I'm forced to extend DefaultMarkerBehavior instead of providing a dummy "no op" implementation.
I'm not a fan of Java interfaces explosion, but I think that they have a point here.

(Even worse, DefaultMarkerBehavior.updateProblemIndication() is package private!)

(Even worse 2: DefaultMarkerBehavior instantiates a private EContentAdapter problemIndicationAdapter field, and that cannot be prevented by a descendant class! the only thing I can do, I guess, is to override initialize() to not registering that adapter ; all very unclean and frafile).


Of corse, in theory I could also provide my own MyDiagramBehaviour that does not extend Graphiti's DiagramBehaviour , but that is not practical either, as DiagramBehaviour is a pretty fat class.

[Updated on: Tue, 27 May 2014 19:09]

Report message to a moderator

Re: DefaultMarkerBehavior woes [message #1384274 is a reply to message #1384000] Wed, 28 May 2014 15:24 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1635
Registered: July 2009
Location: Walldorf, Germany
Senior Member
Hernan,

please see below.

Michael

"Hernan Gonzalez" wrote in message news:lm2nh8$1td$1@xxxxxxxxe.org...

....

This looks objectionable in that:

- Isn't there a more cooperative way of adding its own problem markers,
without deleting all (including perhaps problems from other participants)?
I'm not sure about the (non Graphiti) markerHelper.hasMarkers() doc:
"Returns whether the a maker with id equals to the return of getMarkerID() "
(and that method is private!), I'm not sure who sets that id, and if all
"Problem" markers must share it or not.

Michael: yes, good point. Not sure what we can do here, but that should be
tracked. Would you file a bug for that, please?

- If I want to disable that behaviour (assuming I'm not interested in
marking those EMF problems), I guess the way is to override
MyDiagramBehaviour.createMarkerBehavior() . Sadly, that is less extensible
than in looks, because it (as all DiagramBehaviour.create***Behaviour())
returns a concrete class instead of an interface, so I'm forced to extend
DefaultMarkerBehavior instead of providing a dummy "no op" implementation.
I'm not a fan of Java interfaces explosion, but I think that they have a
point here.

Michael: Yes, should be, see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=428096


....
Re: DefaultMarkerBehavior woes [message #1384730 is a reply to message #1384274] Fri, 30 May 2014 20:47 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
Michael Wenz wrote on Wed, 28 May 2014 12:24



Michael: yes, good point. Not sure what we can do here, but that should be
tracked. Would you file a bug for that, please?



Sure, done:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=436262
Re: DefaultMarkerBehavior woes [message #1462141 is a reply to message #1384730] Wed, 05 November 2014 08:48 Go to previous messageGo to next message
Robert Brodt is currently offline Robert BrodtFriend
Messages: 616
Registered: August 2010
Location: Colorado Springs, CO
Senior Member

Hi guys,

I've recently run into some more problems with DefaultMarkerBehavior. I'm trying to load an XML file that contains numerous parsing errors (around 500) that need to be reported, but do not necessarily invalidate the file - the editor should still continue loading the file and allow it to be edited.

The DefaultMarkerBehavior class responds to the XML loader error notifications by scheduling a call to updateProblemIndication() to run in the UI thread (which makes sense). These updates are run during the initial graphical viewer update, and by that time the entire file has been loaded and all of the diagnostics have been collected in the EMF ResourceImpl. So, what is happening is that updateProblemIndication() recreates Problem Markers for all 500 diagnostics 500 times. The MarkerHelper.createMarkers() is already an expensive operation and invoking it 250000 times (instead of just 500) causes the workbench to appear to "hang". I haven't waited for it complete, but it seems to run for hours!

Because of the way this class has been designed, it is not possible to work around this situation. The only solution I've found is to copy the entire class and modify the private (!) problemIndicationAdapter.notify() so that it only responds the Resource.RESOURCE__IS_LOADED event. Besides including this EContentAdpater as part of the public interface, I think it needs to be redesigned to either collect the reported error diagnostics and schedule only a single call to createMarkers(), or respond only to the RESOURCE__IS_LOADED event which, I believe, is always reported (needs investigation).

Cheers,
Bob
Re: DefaultMarkerBehavior woes [message #1463389 is a reply to message #1462141] Thu, 06 November 2014 14:12 Go to previous message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1635
Registered: July 2009
Location: Walldorf, Germany
Senior Member
Robert,

you seem to have hit the pain-point of that class...

I will try to have a deeper look into this and report back in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=436262 .

On the other hand: if you have a sketch of what could be done here, feel
free to propose a change either as patch or Gerrit change.

Michael
Previous Topic:Filled attribute always true?
Next Topic:why my icon is not showing in the shape ?
Goto Forum:
  


Current Time: Sat Nov 22 08:55:08 GMT 2014

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

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