Home » Modeling » Epsilon » Quick fix cannot find my editor
Quick fix cannot find my editor [message #877818] |
Sun, 27 May 2012 20:54 |
Maarten Bezemer Messages: 117 Registered: February 2012 |
Senior Member |
|
|
I am trying to make use of the quick fix functionality while using EVL validation.
The quick fix suggestions show up properly, but when I try to make use of a quick fix the editor is not found. After some debugging I noticed that EditorPart#editorInput has a different format than EmfMarkerResolver#getEditingDomain() uses.
My editor uses this format: L/<project>/relative/path/to/file (which is provided by Eclipse).
EmfMarkerResolver uses: L/file://absolute/path/to/file
Due to this mismatch, the editor is not found (by eclipse using the openEditor() methods) and a new one is opened (at least after I added code to convert the path into the format that Eclipse uses).
I suppose some conversion is required in EmfMarkerResolver#getEditingDomain()? Although I am wondering whether I am doing something wrong, as I suppose that others would have found this problem before...
[Updated on: Sun, 27 May 2012 20:55] Report message to a moderator
|
|
| | | |
Re: Quick fix cannot find my editor [message #880018 is a reply to message #877829] |
Fri, 01 June 2012 09:33 |
|
Hi Maarten,
Thanks for your patch. The first hunk looks safe, but I'm not sure about the second one. I suspect that the "uri" attribute may point in some cases not just to a resource (a file), but also to a specific model element through the URI's fragment (L/.../file.model#fragment).
I'm not sure why we use that "uri" attribute in particular, though. Where is it set from? I don't see it being set neither in evl.emf.validation nor in emf.validation. Dimitris, Louis: any ideas?
Cheers,
Antonio
|
|
|
Re: Quick fix cannot find my editor [message #880026 is a reply to message #880018] |
Fri, 01 June 2012 09:45 |
Maarten Bezemer Messages: 117 Registered: February 2012 |
Senior Member |
|
|
Hi Antonio,
Antonio Garcia-Dominguez wrote on Fri, 01 June 2012 11:33Thanks for your patch. The first hunk looks safe, but I'm not sure about the second one. I suspect that the "uri" attribute may point in some cases not just to a resource (a file), but also to a specific model element through the URI's fragment (L/.../file.model#fragment).
The fragment is filtered away by
final String location = getAbsoluteElementId(marker).split("#")[0];
so that should not give problems.
Quote:
I'm not sure why we use that "uri" attribute in particular, though. Where is it set from? I don't see it being set neither in evl.emf.validation nor in emf.validation
I also do not know where the 'uri' attribute is/should be coming from (by coincidence I used it in my markers as well). Maybe GMF adds it?
[Updated on: Fri, 01 June 2012 09:46] Report message to a moderator
|
|
|
Re: Quick fix cannot find my editor [message #881221 is a reply to message #880026] |
Mon, 04 June 2012 07:03 |
|
Hi Maarten,
If getAbsoluteElementId were only called in combination with getElementResourceLocation, that would work. However, it is called from getRelativeElementId and getResolutions as well, so I would like to keep its current behaviour if possible.
What we can do, however, is to check the "uri" field and if it is null, fall back to your approach. That should ensure getElementResourceLocation works, but I'm still not sure it would be the right approach.
Can't you set the "uri" field on your marker with the appropriate URI from your editor? getAbsoluteElementId should generate a URI to the *model element* being validated, and not just the file, after all :-/.
Is it a handmade editor, or has it been generated by EMF or some other means?
Cheers,
Antonio
|
|
| |
Re: Quick fix cannot find my editor [message #881764 is a reply to message #881245] |
Tue, 05 June 2012 08:12 |
|
Maarten Bezemer wrote on Mon, 04 June 2012 04:01I already use the uri attribute to find the part of any given marker (eg to remove it when revalidating the part). So, now it matches the expected value, no problems here anymore.
Only minor point is, that the field needs to be set by the editor in order to let it work, while the getResource() method always return the resource (ie file location) of the editor. So using this seems to be more robust, disadvantage it that it has no 'part fragment'.
We could still use it as a fallback method in getElementResourceLocation, and leave get(Absolute,Relative)ElementId as is. That'd take care of the first NPE.
Maarten Bezemer wrote on Mon, 04 June 2012 04:01Therefore, getEditingDomain(IEditorPart editor) returns null. This null value is directly used in resolve(IMarker marker):
ResourceSet resourceSet = getEditingDomain(marker).getResourceSet();
Resulting in the NPE.
The problem is that there's no way to get to the EMF ResourceSet unless it's from the editing domain. marker.getResource() will only give us an Eclipse IResource, not an EMF Resource, after all.
The full name of IEditingDomainProvider is org.eclipse.emf.edit.domain.IEditingDomainProvider, so it should be an EMF interface, not a GMF one. Could you try implementing it?
|
|
|
Re: Quick fix cannot find my editor [message #881776 is a reply to message #881764] |
Tue, 05 June 2012 08:32 |
Maarten Bezemer Messages: 117 Registered: February 2012 |
Senior Member |
|
|
Using the fallback method seems good to me.
Should I open a bug for that?
About the other NPE: I am using GEF (not GMF) and my problem is that both GEF uses different Commands and CommandStack. So I cannot easily implement IEditingDomainProvider as it expects the EMF CommandStack instead of the GEF CommandStack (and Commands).
I am looking on how to properly solve this issue as I would like to use EMF Transaction as well, which suffers from the same problem!
Besides this, the getEditingDomain(IEditorPart editor) method returns null if the IEditingDomainProvider interface is not implemented, which is fine by me.
But this returned null is directly used int the resolve(IMarker marker) method, resulting in the NPE.
Because the getEditingDomain method might return null, this should be checked first and if it indeed returned null, resolve() should return null as well (instead of the NPE). And so on until in methods calling resolve().
If you like, I can implement this and share the patch?
Another solution is to modify the canResolve() method to check whether getEditingDomain() returns null, but canResolve() is called lots of time, so that results in a major overhead... Or some caching should be added here...
|
|
|
Re: Quick fix cannot find my editor [message #884484 is a reply to message #881776] |
Mon, 11 June 2012 06:59 |
|
Sorry for the delay. Yes, I think opening a bug report to keep track of all this (not just the first NPE) would be nice.
Perhaps you should look into the source code of the GMF runtime. It is based on GEF, after all, so they will have probably done something like what you're looking for.
Is canResolve() called much more than resolve()? I don't think getEditingDomain() requires much more than accessing a field, and we'd need to change much less code. That, and I'd really like to avoid having to return null from a method: it feels unsafe.
|
|
|
Goto Forum:
Current Time: Tue Apr 23 07:03:39 GMT 2024
Powered by FUDForum. Page generated in 0.04058 seconds
|