| file:// and platform:://resource URIs in ResourceSet [message #506577] |
Fri, 08 January 2010 07:00  |
 Robert Wloch
Messages: 109
Registered: July 2009 |
Senior Member |
|
|
Hi,
For a model consisting of several EMF and GMF files I have written a common model browser. Since the model can be located outside of the eclipse workspace the browser is using file:// URIs to load model data for showing the model structure. In order to make the browser interoperable with the generated EMF/GMF editors all (browser+editors) are using the same editing domain and resource set.
I was wondering why changes done via the browser are not reflected to the elements in the editors and vice versa until I descovered, that all resources exist twice in the ResourceSet: The browser uses the file:// URI resources but the editors use the platform://resource URI resources. Now I've been looking for a simple solution for this and discovered the ResourceSet is using an URIConverter.
Would replacing the URIConverter (and overriding normalize()) of the shared EditingDomain's ResourceSet be the simplest way to map file:// and platform://resource URIs to the same file? Is there another better way to achieve this? Does it actually make sense to replace the URI converter in my case?
Thanks for help and hints!
Regards
Rob
[Updated on: Fri, 08 January 2010 02:33] Report message to a moderator |
|
|
|
| Re: file:// and platform:://resource URIs in ResourceSet [message #506625 is a reply to message #506623] |
Fri, 08 January 2010 12:08  |
Robert Wloch
Messages: 109
Registered: July 2009 |
Senior Member |
|
|
Ed,
Thanks for your reply!
>Robert,
>
>Comments below.
>
>Robert Wloch wrote:
>> Hi,
>>
>> For model consisting of several EMF and GMF files I have written a
>> common model browser. Since the model can be located outside of the
>> eclipse workspace the browser is using file:// URIs to load model data
>> for showing the model structure.
>In all cases, or only for the ones outside the workspace?
My model browser always uses file:// URIs, no matter if they are in the workspace or not.
>> In order to mkae the browser interoperable with the generated EMF/GMF
>> editors all (browser+editors) are using the same editing domain and
>> resource set.
>>
>> I was wondering why changes done via the browser are not reflected to
>> the elements in the editors and vice versa until I descovered, that
>> all resources exist twice in the ResourceSet: The browser uses the
>> file:// URI resources but the editors use the platform://resource URI
>> resources.
>The URI converter only does a limited amount of normalization, primarily
>syntactic. You'd have to specialize it if you want to do semantic
>normalization.
Ok, I'll do that then.
>> Now I've been looking for a simple solution for this and discovered
>> the ResourceSet is using an URIConverter.
>>
>> Would replacing the URIConverter (and overriding normalize()) of the
>> shared EditingDomain's ResourceSet be the simplest way to map file://
>> and platform://resource URIs to the same file?
>It's a simple way.
>> Is there another better way to achieve this?
>No.
>> Does it actually make sence to replace the URI converter in my case?
>Yes, though you might just compute URI mappings from the workspace onto
>the file system and then apply that inverse mapping (so that access to
>the workspace properly uses the workspace URIs, e.g., a save will
>produce local history and produce a delta).
That's almost what I had in mind, too. Actually I was going to just always map platform URIs to the file system.
>>
>> Thanks for help and hints!
>>
>> Regards
>> Rob
|
|
|
| Re: file:// and platform:://resource URIs in ResourceSet [message #506651 is a reply to message #506625] |
Fri, 08 January 2010 14:10 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Robert,
Comments below.
Robert Wloch wrote:
> Ed,
>
> Thanks for your reply!
>
>> Robert,
>>
>> Comments below.
>>
>> Robert Wloch wrote:
>>> Hi,
>>>
>>> For model consisting of several EMF and GMF files I have written a
>>> common model browser. Since the model can be located outside of the
>>> eclipse workspace the browser is using file:// URIs to load model
>>> data for showing the model structure.
>> In all cases, or only for the ones outside the workspace?
>
> My model browser always uses file:// URIs, no matter if they are in
> the workspace or not.
That doesn't seem like a good idea. The workspace will become out of
sync with the file system, no local history, and so on...
>
>>> In order to mkae the browser interoperable with the generated
>>> EMF/GMF editors all (browser+editors) are using the same editing
>>> domain and resource set.
>>>
>>> I was wondering why changes done via the browser are not reflected
>>> to the elements in the editors and vice versa until I descovered,
>>> that all resources exist twice in the ResourceSet: The browser uses
>>> the file:// URI resources but the editors use the
>>> platform://resource URI resources.
>> The URI converter only does a limited amount of normalization,
>> primarily syntactic. You'd have to specialize it if you want to do
>> semantic normalization.
>
> Ok, I'll do that then.
>
>>> Now I've been looking for a simple solution for this and discovered
>>> the ResourceSet is using an URIConverter.
>>>
>>> Would replacing the URIConverter (and overriding normalize()) of the
>>> shared EditingDomain's ResourceSet be the simplest way to map
>>> file:// and platform://resource URIs to the same file?
>> It's a simple way.
>>> Is there another better way to achieve this?
>> No.
>>> Does it actually make sence to replace the URI converter in my case?
>> Yes, though you might just compute URI mappings from the workspace
>> onto the file system and then apply that inverse mapping (so that
>> access to the workspace properly uses the workspace URIs, e.g., a
>> save will produce local history and produce a delta).
>
> That's almost what I had in mind, too. Actually I was going to just
> always map platform URIs to the file system.
I think it's generally a bad idea to bypass the workspace given that it
will cause the workspace to be out of sync.
>
>>>
>>> Thanks for help and hints!
>>>
>>> Regards
>>> Rob
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03210 seconds
] 
Search
Help
Register
Login
Home
