Home » Modeling » EMF » [CDO]Are derived features supported ?
[CDO]Are derived features supported ? [message #631167] |
Wed, 06 October 2010 12:25 |
Stephane fournier Messages: 340 Registered: July 2009 |
Senior Member |
|
|
Ed,
Sorry my initial post was not at the right location.
http://www.eclipse.org/forums/index.php?t=msg&th=197906& amp; amp;start=0&S=b07d0c3f0d1eff9222f5fcd7f318
b889
I have a look at generated code when using GenModel's Feature Delegation, which is the case when using the CDOImporter(this property is set to Reflective).
With such a feature delegation property, generated code for a derived feature is the following :
public EList<MyType> getMyTypes() {
return (EList<MyType>)eGet(Package.Literals.ELEMENT__MYTYPES, true);
}
At runtime, that ends to execute :
eSettingDelegate(eFeature).dynamicGet(this, eSettings(), dynamicFeatureID, resolve, coreType) that always returns an empty collection.
No chance to have the expected behavior implemented by my java code.
I don't understand why derived features are not handled as usual when using feature delegation.
I also notice no eGet(..) generated method (the one with a switch implementation that points to generated methods).
As a consequence, reflective calls are not working for my derived features.
Could you please give me more details ?
My goal is to provide 2 implementations of the same model: one classic and one generated against CDO, but I need to keep the same behavior on derived features.
I don't have a look to the Class.javajet template, is Operation handled in the same way as derived feature when using feature delegation ?
Stephane.
[Updated on: Wed, 06 October 2010 12:25] Report message to a moderator
|
|
|
Re: [CDO]Are derived features supported ? [message #631212 is a reply to message #631167] |
Wed, 06 October 2010 15:00 |
|
Hi Stephane,
I think what you need is *dynamic* feature delegation, as offered by the new CDO Migrator. For your existing genmodel you'd just have to change the feature delegation property to "Dynamic" manually.
Does that help?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 06.10.2010 14:25, schrieb Stéphane Fournier:
> Ed,
> Sorry my initial post which was not at the right location.
> http://www.eclipse.org/forums/index.php?t=msg&th=197906& amp;start=0&S=b07d0c3f0d1eff9222f5fcd7f318
> b889
>
> I have a look at generated code when using GenModel's Feature Delegation, which is the case when using the CDOImporter(this property is set to Reflective).
>
> With such a feature delegation property, generated code for a derived feature is the following :
>
> public EList<MyType> getMyTypes() {
> return (EList<MyType>)eGet(Package.Literals.ELEMENT__MYTYPES, true);
> }
>
> At runtime, that ends to execute : eSettingDelegate(eFeature).dynamicGet(this, eSettings(), dynamicFeatureID, resolve, coreType) that always returns an empty collection.
>
> No chance to have the expected behavior implemented by my java code.
>
> I don't understand why derived features are not handled as usual when using feature delegation.
> I also notice no eGet(..) generated method (the one with a switch implementation that points to generated methods).
> As a consequence, reflective calls are not working for my derived features.
>
> Could you please give me more details ?
> My goal is to provide 2 implementations of the same model: one classic and one generated against CDO, but I need to keep the same behavior on derived features.
>
> I don't have a look to the Class.javajet template, is Operation handled in the same way as derived feature when using feature delegation ?
>
> Stephane.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO]Are derived features supported ? [message #631224 is a reply to message #631212] |
Wed, 06 October 2010 15:50 |
Stephane fournier Messages: 340 Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Thanks for your help.
I've tried what you suggest. It changed the generated code but derived features are still implemented by a call to eGet(....).
Anyway, as I use EMF dynamic templates, I customized a bit the Class.javajet template to get "my" expected result:
- same generation for derived feature as no feature delegation
- generation of eGet(..) method, with only switch case for derived features.
It seems to run smoothly with CDO 3.0.
Stephane.
Eike Stepper wrote on Wed, 06 October 2010 11:00 | Hi Stephane,
I think what you need is *dynamic* feature delegation, as offered by the new CDO Migrator. For your existing genmodel you'd just have to change the feature delegation property to "Dynamic" manually.
Does that help?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 06.10.2010 14:25, schrieb Stéphane Fournier:
> Ed,
> Sorry my initial post which was not at the right location.
> http://www.eclipse.org/forums/index.php?t=msg&th=197906& amp; amp;start=0&S=b07d0c3f0d1eff9222f5fcd7f318
> b889
>
> I have a look at generated code when using GenModel's Feature Delegation, which is the case when using the CDOImporter(this property is set to Reflective).
>
> With such a feature delegation property, generated code for a derived feature is the following :
>
> public EList<MyType> getMyTypes() {
> return (EList<MyType>)eGet(Package.Literals.ELEMENT__MYTYPES, true);
> }
>
> At runtime, that ends to execute : eSettingDelegate(eFeature).dynamicGet(this, eSettings(), dynamicFeatureID, resolve, coreType) that always returns an empty collection.
>
> No chance to have the expected behavior implemented by my java code.
>
> I don't understand why derived features are not handled as usual when using feature delegation.
> I also notice no eGet(..) generated method (the one with a switch implementation that points to generated methods).
> As a consequence, reflective calls are not working for my derived features.
>
> Could you please give me more details ?
> My goal is to provide 2 implementations of the same model: one classic and one generated against CDO, but I need to keep the same behavior on derived features.
>
> I don't have a look to the Class.javajet template, is Operation handled in the same way as derived feature when using feature delegation ?
>
> Stephane.
|
|
|
|
Re: [CDO]Are derived features supported ? [message #631234 is a reply to message #631224] |
Wed, 06 October 2010 15:58 |
|
Am 06.10.2010 17:50, schrieb Stéphane Fournier:
> Hi Eike,
> Thanks for your help.
>
> I've tried what you suggest. It changed the generated code but derived features are still implemented by a call to eGet(....).
Yes, I've seen that. But for derived features you just remove the body, add your own body and markl the method @generated NOT, right?
IIRC. Ed doesn't see an urgent need to initially generate a //TODO comment instead of the wrong call.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> Anyway, as I use EMF dynamic templates, I customized a bit the Class.javajet template to get "my" expected result:
> - same generation for derived feature as no feature delegation
> - generation of eGet(..) method, with only switch case for derived features.
>
> It seems to run smoothly with CDO 3.0.
>
> Stephane.
>
>
> Eike Stepper wrote on Wed, 06 October 2010 11:00
>> Hi Stephane,
>>
>> I think what you need is *dynamic* feature delegation, as offered by the new CDO Migrator. For your existing genmodel you'd just have to change the feature delegation property to "Dynamic" manually.
>>
>> Does that help?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Am 06.10.2010 14:25, schrieb Stéphane Fournier:
>> > Ed,
>> > Sorry my initial post which was not at the right location.
>> > http://www.eclipse.org/forums/index.php?t=msg&th=197906& amp; amp; amp;start=0&S=b07d0c3f0d1eff9222f5fcd7f318
>> > b889
>> >
>> > I have a look at generated code when using GenModel's Feature Delegation, which is the case when using the CDOImporter(this property is set to Reflective).
>> >
>> > With such a feature delegation property, generated code for a derived feature is the following :
>> >
>> > public EList<MyType> getMyTypes() {
>> > return (EList<MyType>)eGet(Package.Literals.ELEMENT__MYTYPES, true);
>> > }
>> >
>> > At runtime, that ends to execute : eSettingDelegate(eFeature).dynamicGet(this, eSettings(), dynamicFeatureID, resolve, coreType) that always returns an empty collection.
>> >
>> > No chance to have the expected behavior implemented by my java code.
>> >
>> > I don't understand why derived features are not handled as usual when using feature delegation.
>> > I also notice no eGet(..) generated method (the one with a switch implementation that points to generated methods).
>> > As a consequence, reflective calls are not working for my derived features.
>> >
>> > Could you please give me more details ?
>> > My goal is to provide 2 implementations of the same model: one classic and one generated against CDO, but I need to keep the same behavior on derived features.
>> >
>> > I don't have a look to the Class.javajet template, is Operation handled in the same way as derived feature when using feature delegation ?
>> >
>> > Stephane.
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO]Are derived features supported ? [message #631279 is a reply to message #631234] |
Wed, 06 October 2010 19:25 |
Stephane fournier Messages: 340 Registered: July 2009 |
Senior Member |
|
|
You are right, it is a possibility.
But we also have to think about the eGet(..) implementation to add a case for the derived feature that calls the generated method. Without that, reflective call does not work, e.g properties view are not filled in.
Instead of generating a //TODO comment, the JET template should call the same @include getGenFeature.TODO.override. This way, people providing a dynamic template matching this include have the generated code direclty fill in.
For sure, it is time-consuming to handle JET templates, I agree with you and Ed, it is not an urgent need.
Thanks again for your help.
Stephane.
> Yes, I've seen that. But for derived features you just remove the body, add > your own body and markl the method @generated NOT, right?
>
>IIRC. Ed doesn't see an urgent need to initially generate a //TODO comment instead of the wrong call.
|
|
|
Goto Forum:
Current Time: Wed Sep 25 10:11:18 GMT 2024
Powered by FUDForum. Page generated in 0.03786 seconds
|