|
|
|
| Re: [EMF] Combining Reflective EMF with generated model code [message #431536 is a reply to message #431513] |
Wed, 15 July 2009 13:48   |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Sandro,
Comments below.
Sandro Böhme wrote:
> Hi Ed,
>
> please see my comments inline:
>
> Ed Merks schrieb:
>> Sandro,
>>
>> Comments below.
>>
>> Sandro Böhme wrote:
>>> Hello,
>>>
>>> I have the following usecase:
>>> There is a myDomainModel.ecore file that contains EClasses that all
>>> sooner or later extend from a generic EClass from an other package
>>> that in turn extends from EObject. The generic EClass acts as an API
>>> for arbitary myDomainModel.ecore files that have classes which
>>> extend from the generic EClass. It actually is the JCRMNode class
>>> from Eclipse JCR Management. That class has generated code that
>>> contains customizations while the models like the
>>> myDomainModel.ecore file do not have generated code (in this
>>> usecase). I would like to create an editor for the domain model
>>> ecore files that leverages the generic EClass.
>>> When I register the model containing the generic EClass in the
>>> package registry and load the domain model as XML in a resource the
>>> model objects are not instances of the generic EClass (JCRMNode) but
>>> instances of the reflective EClass. Is there any way to configure
>>> EMF to load a myDomainModel.ecore file and have instances of my
>>> generic EClass in the resource?
>> It should "just" be a matter of whether your myDomain.ecore refers to
>> the development time instance of the base or the runtime instance.
>> The later will refer to the model via the nsURI not via the platform
>> resource or platform plugin location.
> It sounds like it's a supported usecase - yeah, thats great.
> This is a snipped from the attached loadedLibrary.ecore file which I
> refered to as myDomainModel.ecore in the previous post. The JCRMNode
> is the generic EClass from the package with generated code. This code
> is already part of the running Eclipse instance.
> <eClassifiers xsi:type="ecore:EClass" name="base"
> eSuperTypes=" platform:/plugin/org.eclipse.emf.jcrm.dmodel/model/domainmod el.ecore#//JCRMNode ">
>
> ...
> </eClassifiers>
> This means I have the generic domainmodel package (in contrast to the
> concrete mydomainmodel package) that contains generated classes as
> plugin project in one Eclipse instance. I start a second Eclipse
> instance containing this generated classes in the VM. In this second
> instance the loadedLibrary.ecore is generated containing the reference
> to the generic domainmodel as you see in the snipped.
The second model is referring to the development time instance of the
first model, but likely you want that to refer to the actual generated
instance of the first model, which would be done using the nsURI of the
package, not the physical location of a/the serialized instance.
> After that I run this code:
> ResourceSet resourceSet = new ResourceSetImpl();
> resourceSet.getPackageRegistry().put(DmodelPackage.eNS_URI,
> DmodelPackage.eINSTANCE);
> URI fileURI = URI.createFileURI("/path/to/loadedLibrary.ecore");
> Resource resource = resourceSet.getResource(fileURI,true);
> But the resource does only contain instances of the reflective EClass
> and no instances of the JCRMNode class.
I suspect it contains instances of the JCRMNode class, but not of the
generated version of it because of what I mentioned above.
> What else do I need to configure?
>
>>> Or do I have to use generated code for the domain model to use the
>>> generated code of my generic EClass?
>> That certainly helps solve the above problem. Of course for the
>> generated models, the item providers are registered so the base
>> editor can pick them up. There's even the optional extended child
>> generation you can exploit...
> I would like to avoid that at the beginning. My goal is to write an
> editor that does not only work for this loadedLibrary.ecore but for
> all kinds of such models by utilizing EMF reflection, the generated
> classes of the generic domainmodel and maybe a seperate reflection
> mechanism.
>
> Relying on generated code of a loadedLibrary.ecore file would mean I
> would need to generate it on the fly and inject it to the running VM
> for the editor without user interaction. Of course it would be cool as
> it would be faster than relying on reflection but I afraid it would
> not be trivial to implement. But if you have any pointers at hand on
> how to do that I would appreciate it anyway :-)
Unfortunately the dynamic instance will have to refer to the actual
generated version of the base not the serialized development time version...
>
>
> Thanks,
>
> Sandro
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] Combining Reflective EMF with generated model code [message #431543 is a reply to message #431536] |
Wed, 15 July 2009 17:12 |
Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
yeah it works - this is really cool stuff!
There is one remark: I declared the JCRMNode to be abstract but to
create a concrete implementation EMF tries to create an instance of it
by passing the concrete EClass to the package factory of the generic
package. It only works when I make the JCRMNode non-abstract which isn't
really clean from the model point of view. But of course an instance is
needed for exactly my usecase.
Thanks Ed!
Bye,
Sandro
Ed Merks schrieb:
> Sandro,
>
> Comments below.
>
> Sandro Böhme wrote:
>> Hi Ed,
>>
>> please see my comments inline:
>>
>> Ed Merks schrieb:
>>> Sandro,
>>>
>>> Comments below.
>>>
>>> Sandro Böhme wrote:
>>>> Hello,
>>>>
>>>> I have the following usecase:
>>>> There is a myDomainModel.ecore file that contains EClasses that all
>>>> sooner or later extend from a generic EClass from an other package
>>>> that in turn extends from EObject. The generic EClass acts as an API
>>>> for arbitary myDomainModel.ecore files that have classes which
>>>> extend from the generic EClass. It actually is the JCRMNode class
>>>> from Eclipse JCR Management. That class has generated code that
>>>> contains customizations while the models like the
>>>> myDomainModel.ecore file do not have generated code (in this
>>>> usecase). I would like to create an editor for the domain model
>>>> ecore files that leverages the generic EClass.
>>>> When I register the model containing the generic EClass in the
>>>> package registry and load the domain model as XML in a resource the
>>>> model objects are not instances of the generic EClass (JCRMNode) but
>>>> instances of the reflective EClass. Is there any way to configure
>>>> EMF to load a myDomainModel.ecore file and have instances of my
>>>> generic EClass in the resource?
>>> It should "just" be a matter of whether your myDomain.ecore refers to
>>> the development time instance of the base or the runtime instance.
>>> The later will refer to the model via the nsURI not via the platform
>>> resource or platform plugin location.
>> It sounds like it's a supported usecase - yeah, thats great.
>> This is a snipped from the attached loadedLibrary.ecore file which I
>> refered to as myDomainModel.ecore in the previous post. The JCRMNode
>> is the generic EClass from the package with generated code. This code
>> is already part of the running Eclipse instance.
>> <eClassifiers xsi:type="ecore:EClass" name="base"
>> eSuperTypes=" platform:/plugin/org.eclipse.emf.jcrm.dmodel/model/domainmod el.ecore#//JCRMNode ">
>>
>> ...
>> </eClassifiers>
>> This means I have the generic domainmodel package (in contrast to the
>> concrete mydomainmodel package) that contains generated classes as
>> plugin project in one Eclipse instance. I start a second Eclipse
>> instance containing this generated classes in the VM. In this second
>> instance the loadedLibrary.ecore is generated containing the reference
>> to the generic domainmodel as you see in the snipped.
> The second model is referring to the development time instance of the
> first model, but likely you want that to refer to the actual generated
> instance of the first model, which would be done using the nsURI of the
> package, not the physical location of a/the serialized instance.
>> After that I run this code:
>> ResourceSet resourceSet = new ResourceSetImpl();
>> resourceSet.getPackageRegistry().put(DmodelPackage.eNS_URI,
>> DmodelPackage.eINSTANCE);
>> URI fileURI = URI.createFileURI("/path/to/loadedLibrary.ecore");
>> Resource resource = resourceSet.getResource(fileURI,true);
>> But the resource does only contain instances of the reflective EClass
>> and no instances of the JCRMNode class.
> I suspect it contains instances of the JCRMNode class, but not of the
> generated version of it because of what I mentioned above.
>> What else do I need to configure?
>>
>>>> Or do I have to use generated code for the domain model to use the
>>>> generated code of my generic EClass?
>>> That certainly helps solve the above problem. Of course for the
>>> generated models, the item providers are registered so the base
>>> editor can pick them up. There's even the optional extended child
>>> generation you can exploit...
>> I would like to avoid that at the beginning. My goal is to write an
>> editor that does not only work for this loadedLibrary.ecore but for
>> all kinds of such models by utilizing EMF reflection, the generated
>> classes of the generic domainmodel and maybe a seperate reflection
>> mechanism.
>>
>> Relying on generated code of a loadedLibrary.ecore file would mean I
>> would need to generate it on the fly and inject it to the running VM
>> for the editor without user interaction. Of course it would be cool as
>> it would be faster than relying on reflection but I afraid it would
>> not be trivial to implement. But if you have any pointers at hand on
>> how to do that I would appreciate it anyway :-)
> Unfortunately the dynamic instance will have to refer to the actual
> generated version of the base not the serialized development time
> version...
>>
>>
>> Thanks,
>>
>> Sandro
|
|
|
Powered by
FUDForum. Page generated in 0.04437 seconds
] 
Search
Help
Register
Login
Home
