Home » Modeling » EMF » Where to setIntrinsicIDToEObjectMap
| | | |
| Re: Where to setIntrinsicIDToEObjectMap [message #489022 is a reply to message #488877] |
Thu, 01 October 2009 09:18   |
 Dirk Hoffmann
Messages: 163
Registered: July 2009 |
Senior Member |
|
|
Ed Merks schrieb:
> Dirk,
>
> Comments below.
>
> Dirk Hoffmann wrote:
>> Ed Merks schrieb:
>>> Dirk,
>>>
>>> Comments below.
>>>
>>> Dirk Hoffmann wrote:
>>>> Hi,
>>>>
>>>> from searching the web I learned that providing a map via
>>>>
>>>> ResourceImpl.setIntrinsicIDToEObjectMap(Map)
>>>>
>>>> may improve the load performance when using IDs for references
>>>> (correct me if I'm wrong).
>>> Yes, it definitely will.
>>>>
>>>> First I wondered if there is an OPTION to get the same effect and
>>>> considered OPTION_USE_CACHED_LOOKUP_TABLE a candidate but couldn't
>>>> clarify that.
>>> No.
>>>>
>>>> If there is no option where then is the right place to call the
>>>> setIntrinsicIDToEObjectMap method.
>>> Perhaps in the factory where the resource is first created.
>>>>
>>>> Normally I load the resource using:
>>>>
>>>> resource = editingDomain.getResourceSet().getResource(resourceURI,
>>>> true);
>>>>
>>>> And this is how I call setIntrinsicIDToEObjectMap:
>>>>
>>>> if (resource instanceof ResourceImpl) {
>>>> ResourceImpl impl = (ResourceImpl) resource;
>>>>
>>>> if (impl.getIntrinsicIDToEObjectMap() == null) {
>>>> impl.setIntrinsicIDToEObjectMap(new HashMap());
>>>> }
>>>> }
>>>>
>>>> I guess there is no point calling setIntrinsicIDToEObjectMap after
>>>> it is already loaded like outlined above. So where could I intervene
>>>> in order to provide that HashMap before the actual loading takes place?
>>> The factory seems best.
>>
>>
>> Seems reasonable, however when customizing the generated editor where
>> can I hook in my own Resource.Factory implementation without having to
>> recreate the mappings from URIs to Factories?
> The model typically registers a resource factory based on the extension
> or the content type. If you don't have one already, change the
> GenPackage settings so generate a XyzResourceFactoryImpl.#
Ah thanks for that.
Ok, changed the xyz.genmodel to produce an XyzResourceFactoryImpl and an
XyzResourceImpl. Changed the generated XyzResourceImpl to use the
HashMap when loading and respect the save and load options.
However the generated editor still uses the standard XMIResourceImpl
instead of the XyzResourceImpl. I guess the XyzResourceFactoryImpl has
to be registered somewhere with the .xyz file extension. From the book I
learned that this can be achieved with an extension point or put
directly into the code. As I want the extension to be customizable
through an Eclipse preference the extension point solution is not an
option. Maybe using "*" as the extension and checking the URIs outside
of EMF could be another solution.
So the question is. Where is the best place to do that
XyzResourceFactoryImpl registering?
Register with the Resource.Factory.Registry or with each newly created
ResourceSet?
All that resource stuff is quite confusing to me (and then there is also
the package registry).
>>
>> All I have is the EditingDomain which I can ask to get the ResourceSet
>> which I can ask to get the Registry for Resource.Factories. But what
>> then to do with the registry - do I need to iterate through the maps
>> and replace the XMIResourceFactories with my own one (may be a generic
>> factory just wrapping the original one)?
> No. Does your model have an XyzResourceFactoryImpl yet?
>>
>>
>>>>
>>>> Thanks and Regards,
>>>> Dirk
|
|
|
| Re: Where to setIntrinsicIDToEObjectMap [message #489039 is a reply to message #488877] |
Thu, 01 October 2009 09:51 |
Dirk Hoffmann
Messages: 163
Registered: July 2009 |
Senior Member |
|
|
Ed Merks schrieb:
> Dirk,
>
> Comments below.
>
> Dirk Hoffmann wrote:
>> Ed Merks schrieb:
>>> Dirk,
>>>
>>> Comments below.
>>>
>>> Dirk Hoffmann wrote:
>>>> Hi,
>>>>
>>>> from searching the web I learned that providing a map via
>>>>
>>>> ResourceImpl.setIntrinsicIDToEObjectMap(Map)
>>>>
>>>> may improve the load performance when using IDs for references
>>>> (correct me if I'm wrong).
>>> Yes, it definitely will.
>>>>
>>>> First I wondered if there is an OPTION to get the same effect and
>>>> considered OPTION_USE_CACHED_LOOKUP_TABLE a candidate but couldn't
>>>> clarify that.
>>> No.
>>>>
>>>> If there is no option where then is the right place to call the
>>>> setIntrinsicIDToEObjectMap method.
>>> Perhaps in the factory where the resource is first created.
>>>>
>>>> Normally I load the resource using:
>>>>
>>>> resource = editingDomain.getResourceSet().getResource(resourceURI,
>>>> true);
>>>>
>>>> And this is how I call setIntrinsicIDToEObjectMap:
>>>>
>>>> if (resource instanceof ResourceImpl) {
>>>> ResourceImpl impl = (ResourceImpl) resource;
>>>>
>>>> if (impl.getIntrinsicIDToEObjectMap() == null) {
>>>> impl.setIntrinsicIDToEObjectMap(new HashMap());
>>>> }
>>>> }
>>>>
>>>> I guess there is no point calling setIntrinsicIDToEObjectMap after
>>>> it is already loaded like outlined above. So where could I intervene
>>>> in order to provide that HashMap before the actual loading takes place?
>>> The factory seems best.
>>
>>
>> Seems reasonable, however when customizing the generated editor where
>> can I hook in my own Resource.Factory implementation without having to
>> recreate the mappings from URIs to Factories?
> The model typically registers a resource factory based on the extension
> or the content type. If you don't have one already, change the
> GenPackage settings so generate a XyzResourceFactoryImpl.#
Ah thanks for that.
Ok, changed the xyz.genmodel to produce an XyzResourceFactoryImpl and an
XyzResourceImpl. Changed the generated XyzResourceImpl to use the
HashMap when loading and respect the save and load options.
However the generated editor still uses the standard XMIResourceImpl
instead of the XyzResourceImpl.
I'm wondering why the code generator didn't generate the right code so
that the EditingDomain would be aware of the special
XyzResourceFactoryImpl. Maybe I forgot to do some adjustments or there
are "@generated NOT" preventing the generator to do the right thing.
So is there something I can do to let the generator create that code?
Anyway I changed the editor's piece of code responsible for the creation
of the EditingDomain like this:
ResourceSet resourceSet = new ResourceSetImpl();
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
.put(Resource.Factory.Registry.DEFAULT_EXTENSION,
new XyzResourceFactory());
editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
commandStack, resourceSet);
I guess the XyzResourceFactoryImpl could also be registered somewhere
with the .xyz file extension. From the book I
learned that this can be achieved with an extension point or put
directly into the code. As I want the extension to be customizable
through an Eclipse preference the extension point solution is not an
option unless using "*" as the extension and checking the URIs outside
of EMF.
So the question is: What is actually considered the best place to
register the XyzResourceFactoryImpl?
Register with the Resource.Factory.Registry or with each newly created
ResourceSet?
All that resource stuff is quite confusing to me (and then there is also
the package registry).
>>
>> All I have is the EditingDomain which I can ask to get the ResourceSet
>> which I can ask to get the Registry for Resource.Factories. But what
>> then to do with the registry - do I need to iterate through the maps
>> and replace the XMIResourceFactories with my own one (may be a generic
>> factory just wrapping the original one)?
> No. Does your model have an XyzResourceFactoryImpl yet?
>>
>>
>>>>
>>>> Thanks and Regards,
>>>> Dirk
|
|
|
| Re: Where to setIntrinsicIDToEObjectMap [message #489047 is a reply to message #489039] |
Thu, 01 October 2009 11:14 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Dirk,
Comments below.
Dirk Hoffmann wrote:
> Ed Merks schrieb:
>> Dirk,
>>
>> Comments below.
>>
>> Dirk Hoffmann wrote:
>>> Ed Merks schrieb:
>>>> Dirk,
>>>>
>>>> Comments below.
>>>>
>>>> Dirk Hoffmann wrote:
>>>>> Hi,
>>>>>
>>>>> from searching the web I learned that providing a map via
>>>>>
>>>>> ResourceImpl.setIntrinsicIDToEObjectMap(Map)
>>>>>
>>>>> may improve the load performance when using IDs for references
>>>>> (correct me if I'm wrong).
>>>> Yes, it definitely will.
>>>>>
>>>>> First I wondered if there is an OPTION to get the same effect and
>>>>> considered OPTION_USE_CACHED_LOOKUP_TABLE a candidate but couldn't
>>>>> clarify that.
>>>> No.
>>>>>
>>>>> If there is no option where then is the right place to call the
>>>>> setIntrinsicIDToEObjectMap method.
>>>> Perhaps in the factory where the resource is first created.
>>>>>
>>>>> Normally I load the resource using:
>>>>>
>>>>> resource = editingDomain.getResourceSet().getResource(resourceURI,
>>>>> true);
>>>>>
>>>>> And this is how I call setIntrinsicIDToEObjectMap:
>>>>>
>>>>> if (resource instanceof ResourceImpl) {
>>>>> ResourceImpl impl = (ResourceImpl) resource;
>>>>>
>>>>> if (impl.getIntrinsicIDToEObjectMap() == null) {
>>>>> impl.setIntrinsicIDToEObjectMap(new HashMap());
>>>>> }
>>>>> }
>>>>>
>>>>> I guess there is no point calling setIntrinsicIDToEObjectMap after
>>>>> it is already loaded like outlined above. So where could I
>>>>> intervene in order to provide that HashMap before the actual
>>>>> loading takes place?
>>>> The factory seems best.
>>>
>>>
>>> Seems reasonable, however when customizing the generated editor
>>> where can I hook in my own Resource.Factory implementation without
>>> having to recreate the mappings from URIs to Factories?
>> The model typically registers a resource factory based on the
>> extension or the content type. If you don't have one already, change
>> the GenPackage settings so generate a XyzResourceFactoryImpl.#
>
> Ah thanks for that.
>
> Ok, changed the xyz.genmodel to produce an XyzResourceFactoryImpl and an
> XyzResourceImpl. Changed the generated XyzResourceImpl to use the
> HashMap when loading and respect the save and load options.
>
> However the generated editor still uses the standard XMIResourceImpl
> instead of the XyzResourceImpl.
The plugin.xml doesn't regenerate so you have to delete it to update it
to include the registration for the newly generated factory.
>
> I'm wondering why the code generator didn't generate the right code so
> that the EditingDomain would be aware of the special
> XyzResourceFactoryImpl. Maybe I forgot to do some adjustments or there
> are "@generated NOT" preventing the generator to do the right thing.
>
> So is there something I can do to let the generator create that code?
>
> Anyway I changed the editor's piece of code responsible for the
> creation of the EditingDomain like this:
>
> ResourceSet resourceSet = new ResourceSetImpl();
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
> .put(Resource.Factory.Registry.DEFAULT_EXTENSION,
> new XyzResourceFactory());
>
> editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
> commandStack, resourceSet);
You won't need that if it's registered.
>
> I guess the XyzResourceFactoryImpl could also be registered somewhere
> with the .xyz file extension. From the book I
> learned that this can be achieved with an extension point or put
> directly into the code. As I want the extension to be customizable
> through an Eclipse preference the extension point solution is not an
> option unless using "*" as the extension and checking the URIs outside
> of EMF.
>
> So the question is: What is actually considered the best place to
> register the XyzResourceFactoryImpl?
>
> Register with the Resource.Factory.Registry or with each newly created
> ResourceSet?
>
> All that resource stuff is quite confusing to me (and then there is also
> the package registry).
>
>>>
>>> All I have is the EditingDomain which I can ask to get the
>>> ResourceSet which I can ask to get the Registry for
>>> Resource.Factories. But what then to do with the registry - do I
>>> need to iterate through the maps and replace the
>>> XMIResourceFactories with my own one (may be a generic factory just
>>> wrapping the original one)?
>> No. Does your model have an XyzResourceFactoryImpl yet?
>>>
>>>
>>>>>
>>>>> Thanks and Regards,
>>>>> Dirk
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Where to setIntrinsicIDToEObjectMap [message #489052 is a reply to message #489047] |
Thu, 01 October 2009 11:28 |
Dirk Hoffmann
Messages: 163
Registered: July 2009 |
Senior Member |
|
|
Ed Merks schrieb:
> Dirk,
>
> Comments below.
>
> Dirk Hoffmann wrote:
>> Ed Merks schrieb:
>>> Dirk,
>>>
>>> Comments below.
>>>
>>> Dirk Hoffmann wrote:
>>>> Ed Merks schrieb:
>>>>> Dirk,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Dirk Hoffmann wrote:
>>>>>> Hi,
>>>>>>
>>>>>> from searching the web I learned that providing a map via
>>>>>>
>>>>>> ResourceImpl.setIntrinsicIDToEObjectMap(Map)
>>>>>>
>>>>>> may improve the load performance when using IDs for references
>>>>>> (correct me if I'm wrong).
>>>>> Yes, it definitely will.
>>>>>>
>>>>>> First I wondered if there is an OPTION to get the same effect and
>>>>>> considered OPTION_USE_CACHED_LOOKUP_TABLE a candidate but couldn't
>>>>>> clarify that.
>>>>> No.
>>>>>>
>>>>>> If there is no option where then is the right place to call the
>>>>>> setIntrinsicIDToEObjectMap method.
>>>>> Perhaps in the factory where the resource is first created.
>>>>>>
>>>>>> Normally I load the resource using:
>>>>>>
>>>>>> resource = editingDomain.getResourceSet().getResource(resourceURI,
>>>>>> true);
>>>>>>
>>>>>> And this is how I call setIntrinsicIDToEObjectMap:
>>>>>>
>>>>>> if (resource instanceof ResourceImpl) {
>>>>>> ResourceImpl impl = (ResourceImpl) resource;
>>>>>>
>>>>>> if (impl.getIntrinsicIDToEObjectMap() == null) {
>>>>>> impl.setIntrinsicIDToEObjectMap(new HashMap());
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> I guess there is no point calling setIntrinsicIDToEObjectMap after
>>>>>> it is already loaded like outlined above. So where could I
>>>>>> intervene in order to provide that HashMap before the actual
>>>>>> loading takes place?
>>>>> The factory seems best.
>>>>
>>>>
>>>> Seems reasonable, however when customizing the generated editor
>>>> where can I hook in my own Resource.Factory implementation without
>>>> having to recreate the mappings from URIs to Factories?
>>> The model typically registers a resource factory based on the
>>> extension or the content type. If you don't have one already, change
>>> the GenPackage settings so generate a XyzResourceFactoryImpl.#
>>
>> Ah thanks for that.
>>
>> Ok, changed the xyz.genmodel to produce an XyzResourceFactoryImpl and an
>> XyzResourceImpl. Changed the generated XyzResourceImpl to use the
>> HashMap when loading and respect the save and load options.
>>
>> However the generated editor still uses the standard XMIResourceImpl
>> instead of the XyzResourceImpl.
> The plugin.xml doesn't regenerate so you have to delete it to update it
> to include the registration for the newly generated factory.
Ok, deleted the plugin.xml to try that out and yes its there.
Unfortunately the generator also replaced the MANIFEST file with the
generated version. It should check for the existance of the files
individually. Working with EMF 2.2.5.
>>
>> I'm wondering why the code generator didn't generate the right code so
>> that the EditingDomain would be aware of the special
>> XyzResourceFactoryImpl. Maybe I forgot to do some adjustments or there
>> are "@generated NOT" preventing the generator to do the right thing.
>>
>> So is there something I can do to let the generator create that code?
>>
>> Anyway I changed the editor's piece of code responsible for the
>> creation of the EditingDomain like this:
>>
>> ResourceSet resourceSet = new ResourceSetImpl();
>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>> .put(Resource.Factory.Registry.DEFAULT_EXTENSION,
>> new XyzResourceFactory());
>>
>> editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
>> commandStack, resourceSet);
> You won't need that if it's registered.
>>
>> I guess the XyzResourceFactoryImpl could also be registered somewhere
>> with the .xyz file extension. From the book I
>> learned that this can be achieved with an extension point or put
>> directly into the code. As I want the extension to be customizable
>> through an Eclipse preference the extension point solution is not an
>> option unless using "*" as the extension and checking the URIs outside
>> of EMF.
>>
>> So the question is: What is actually considered the best place to
>> register the XyzResourceFactoryImpl?
>>
>> Register with the Resource.Factory.Registry or with each newly created
>> ResourceSet?
>>
>> All that resource stuff is quite confusing to me (and then there is also
>> the package registry).
>>
>>>>
>>>> All I have is the EditingDomain which I can ask to get the
>>>> ResourceSet which I can ask to get the Registry for
>>>> Resource.Factories. But what then to do with the registry - do I
>>>> need to iterate through the maps and replace the
>>>> XMIResourceFactories with my own one (may be a generic factory just
>>>> wrapping the original one)?
>>> No. Does your model have an XyzResourceFactoryImpl yet?
>>>>
>>>>
>>>>>>
>>>>>> Thanks and Regards,
>>>>>> Dirk
>>
|
|
|
| Re: Where to setIntrinsicIDToEObjectMap [message #489053 is a reply to message #489052] |
Thu, 01 October 2009 11:37 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Dirk,
Comments below.
Dirk Hoffmann wrote:
> Ed Merks schrieb:
>> Dirk,
>>
>> Comments below.
>>
>> Dirk Hoffmann wrote:
>>> Ed Merks schrieb:
>>>> Dirk,
>>>>
>>>> Comments below.
>>>>
>>>> Dirk Hoffmann wrote:
>>>>> Ed Merks schrieb:
>>>>>> Dirk,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Dirk Hoffmann wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> from searching the web I learned that providing a map via
>>>>>>>
>>>>>>> ResourceImpl.setIntrinsicIDToEObjectMap(Map)
>>>>>>>
>>>>>>> may improve the load performance when using IDs for references
>>>>>>> (correct me if I'm wrong).
>>>>>> Yes, it definitely will.
>>>>>>>
>>>>>>> First I wondered if there is an OPTION to get the same effect
>>>>>>> and considered OPTION_USE_CACHED_LOOKUP_TABLE a candidate but
>>>>>>> couldn't clarify that.
>>>>>> No.
>>>>>>>
>>>>>>> If there is no option where then is the right place to call the
>>>>>>> setIntrinsicIDToEObjectMap method.
>>>>>> Perhaps in the factory where the resource is first created.
>>>>>>>
>>>>>>> Normally I load the resource using:
>>>>>>>
>>>>>>> resource = editingDomain.getResourceSet().getResource(resourceURI,
>>>>>>> true);
>>>>>>>
>>>>>>> And this is how I call setIntrinsicIDToEObjectMap:
>>>>>>>
>>>>>>> if (resource instanceof ResourceImpl) {
>>>>>>> ResourceImpl impl = (ResourceImpl) resource;
>>>>>>>
>>>>>>> if (impl.getIntrinsicIDToEObjectMap() == null) {
>>>>>>> impl.setIntrinsicIDToEObjectMap(new HashMap());
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> I guess there is no point calling setIntrinsicIDToEObjectMap
>>>>>>> after it is already loaded like outlined above. So where could I
>>>>>>> intervene in order to provide that HashMap before the actual
>>>>>>> loading takes place?
>>>>>> The factory seems best.
>>>>>
>>>>>
>>>>> Seems reasonable, however when customizing the generated editor
>>>>> where can I hook in my own Resource.Factory implementation without
>>>>> having to recreate the mappings from URIs to Factories?
>>>> The model typically registers a resource factory based on the
>>>> extension or the content type. If you don't have one already,
>>>> change the GenPackage settings so generate a XyzResourceFactoryImpl.#
>>>
>>> Ah thanks for that.
>>>
>>> Ok, changed the xyz.genmodel to produce an XyzResourceFactoryImpl
>>> and an
>>> XyzResourceImpl. Changed the generated XyzResourceImpl to use the
>>> HashMap when loading and respect the save and load options.
>>>
>>> However the generated editor still uses the standard XMIResourceImpl
>>> instead of the XyzResourceImpl.
>> The plugin.xml doesn't regenerate so you have to delete it to update
>> it to include the registration for the newly generated factory.
>
> Ok, deleted the plugin.xml to try that out and yes its there.
> Unfortunately the generator also replaced the MANIFEST file with the
> generated version. It should check for the existance of the files
> individually. Working with EMF 2.2.5.
An initially empty EMF plugin project needs a manifest to be considered
correct by PDE so we're often faced with this situation. In any case,
Eclipse has a nice local history and it's simple to replace a file with
an earlier version...
>
>>>
>>> I'm wondering why the code generator didn't generate the right code
>>> so that the EditingDomain would be aware of the special
>>> XyzResourceFactoryImpl. Maybe I forgot to do some adjustments or
>>> there are "@generated NOT" preventing the generator to do the right
>>> thing.
>>>
>>> So is there something I can do to let the generator create that code?
>>>
>>> Anyway I changed the editor's piece of code responsible for the
>>> creation of the EditingDomain like this:
>>>
>>> ResourceSet resourceSet = new ResourceSetImpl();
>>> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap()
>>> .put(Resource.Factory.Registry.DEFAULT_EXTENSION,
>>> new XyzResourceFactory());
>>>
>>> editingDomain = new AdapterFactoryEditingDomain(adapterFactory,
>>> commandStack, resourceSet);
>> You won't need that if it's registered.
>>>
>>> I guess the XyzResourceFactoryImpl could also be registered
>>> somewhere with the .xyz file extension. From the book I
>>> learned that this can be achieved with an extension point or put
>>> directly into the code. As I want the extension to be customizable
>>> through an Eclipse preference the extension point solution is not an
>>> option unless using "*" as the extension and checking the URIs outside
>>> of EMF.
>>>
>>> So the question is: What is actually considered the best place to
>>> register the XyzResourceFactoryImpl?
>>>
>>> Register with the Resource.Factory.Registry or with each newly created
>>> ResourceSet?
>>>
>>> All that resource stuff is quite confusing to me (and then there is
>>> also
>>> the package registry).
>>>
>>>>>
>>>>> All I have is the EditingDomain which I can ask to get the
>>>>> ResourceSet which I can ask to get the Registry for
>>>>> Resource.Factories. But what then to do with the registry - do I
>>>>> need to iterate through the maps and replace the
>>>>> XMIResourceFactories with my own one (may be a generic factory
>>>>> just wrapping the original one)?
>>>> No. Does your model have an XyzResourceFactoryImpl yet?
>>>>>
>>>>>
>>>>>>>
>>>>>>> Thanks and Regards,
>>>>>>> Dirk
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 14:51:21 GMT 2024
Powered by FUDForum. Page generated in 0.04396 seconds |
] 
Search
Help
Register
Login
Home
