Home » Modeling » Graphiti » DefaultMarkerBehavior woes
DefaultMarkerBehavior woes [message #1384000] |
Tue, 27 May 2014 19:03 |
Hernan Gonzalez Messages: 188 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 |
Michael Wenz Messages: 1931 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 #1462141 is a reply to message #1384730] |
Wed, 05 November 2014 08:48 |
|
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
|
|
| |
Goto Forum:
Current Time: Tue Mar 19 05:09:00 GMT 2024
Powered by FUDForum. Page generated in 0.02304 seconds
|