Home » Modeling » EMF » EMF References using Generics, Proxy are created
| EMF References using Generics, Proxy are created [message #468346] |
Wed, 05 August 2009 08:05  |
 Maik Wurdel
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Hi,
I'm exploring the support for generics in EMF and facing a problem when
having a generic reference in a class and using the generated editor.
Basically what I want to have is a generic class with an attribute to
attach a certain object by reference.
The generated interface, which is exactly what I want to have, looks
like this:
public interface LTSStateTransitionAttached<E> extends LTSStateTransition {
E getAttached();
void setAttached(E value);
}
The corresponging ecore snippet:
<eClassifiers xsi:type="ecore:EClass" name="LTSStateTransitionAttached"
eSuperTypes="#//lts/LTSStateTransition">
<eTypeParameters name="E"/>
<eStructuralFeatures xsi:type="ecore:EReference"
name="attached" resolveProxies="false">
<eGenericType
eTypeParameter="#//lts/profiles/LTSStateTransitionAttached/E "/>
</eStructuralFeatures>
</eClassifiers>
So far so good.
When I use the generated editor I'm following the common approach of
loading a resource and being able to use the property view to reference
arbitrary objects to set the field, "attached" in this case.
However, when I close the editor and re-open it the reference are proxies.
Am I right, that those references should be resolved, and if not
possible proxies are created?
As far as I can tell this problem is related to attributes with a
generic type. I already compared the way the references are serialized
to attributes with a fixed type. Since those attributes are supposed to
implement references hrefs are used, in both cases.
Any help would be appreciated.
Maik
|
|
|
| Re: EMF References using Generics, Proxy are created [message #468413 is a reply to message #468346] |
Wed, 05 August 2009 13:22  |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Maik,
Comments below.
Maik Wurdel wrote:
> Hi,
>
> I'm exploring the support for generics in EMF and facing a problem
> when having a generic reference in a class and using the generated
> editor.
>
> Basically what I want to have is a generic class with an attribute to
> attach a certain object by reference.
>
> The generated interface, which is exactly what I want to have, looks
> like this:
>
> public interface LTSStateTransitionAttached<E> extends
> LTSStateTransition {
>
> E getAttached();
>
> void setAttached(E value);
>
> }
>
> The corresponging ecore snippet:
>
> <eClassifiers xsi:type="ecore:EClass"
> name="LTSStateTransitionAttached"
> eSuperTypes="#//lts/LTSStateTransition">
> <eTypeParameters name="E"/>
> <eStructuralFeatures xsi:type="ecore:EReference"
> name="attached" resolveProxies="false">
So cross document references will not be supported.
> <eGenericType
> eTypeParameter="#//lts/profiles/LTSStateTransitionAttached/E "/>
> </eStructuralFeatures>
> </eClassifiers>
>
> So far so good.
>
> When I use the generated editor I'm following the common approach of
> loading a resource and being able to use the property view to
> reference arbitrary objects to set the field, "attached" in this case.
>
> However, when I close the editor and re-open it the reference are
> proxies.
Are they in other resources?
>
> Am I right, that those references should be resolved, and if not
> possible proxies are created?
Cross document references are always created as proxies and then there
is an attempt to resolve them when first they are access (which you've
disabled).
>
> As far as I can tell this problem is related to attributes with a
> generic type. I already compared the way the references are serialized
> to attributes with a fixed type. Since those attributes are supposed
> to implement references hrefs are used, in both cases.
>
> Any help would be appreciated.
Try changing resolveProxies to true.
>
> Maik
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF References using Generics, Proxy are created [message #468436 is a reply to message #468413] |
Wed, 05 August 2009 14:23 |
Maik Wurdel
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Ed,
thanks for your fast response and comments.
Ed Merks schrieb:
> Maik,
>
> Comments below.
>
> Maik Wurdel wrote:
>> Hi,
>>
>> I'm exploring the support for generics in EMF and facing a problem
>> when having a generic reference in a class and using the generated
>> editor.
>>
>> Basically what I want to have is a generic class with an attribute to
>> attach a certain object by reference.
>>
>> The generated interface, which is exactly what I want to have, looks
>> like this:
>>
>> public interface LTSStateTransitionAttached<E> extends
>> LTSStateTransition {
>>
>> E getAttached();
>>
>> void setAttached(E value);
>>
>> }
>>
>> The corresponging ecore snippet:
>>
>> <eClassifiers xsi:type="ecore:EClass"
>> name="LTSStateTransitionAttached"
>> eSuperTypes="#//lts/LTSStateTransition">
>> <eTypeParameters name="E"/>
>> <eStructuralFeatures xsi:type="ecore:EReference"
>> name="attached" resolveProxies="false">
> So cross document references will not be supported.
>> <eGenericType
>> eTypeParameter="#//lts/profiles/LTSStateTransitionAttached/E "/>
>> </eStructuralFeatures>
>> </eClassifiers>
>>
>> So far so good.
>>
>> When I use the generated editor I'm following the common approach of
>> loading a resource and being able to use the property view to
>> reference arbitrary objects to set the field, "attached" in this case.
>>
>> However, when I close the editor and re-open it the reference are
>> proxies.
> Are they in other resources?
Yes they are.
>>
>> Am I right, that those references should be resolved, and if not
>> possible proxies are created?
> Cross document references are always created as proxies and then there
> is an attempt to resolve them when first they are access (which you've
> disabled).
What is the purpose of a not resolving proxy? When I'm trying to access
an attribute of the object the proxy should always be resolved or at
least the corresponding attribute. Otherwise null is returned.
For me the only question for a proxies is when it is resolved not if. :)
>>
>> As far as I can tell this problem is related to attributes with a
>> generic type. I already compared the way the references are serialized
>> to attributes with a fixed type. Since those attributes are supposed
>> to implement references hrefs are used, in both cases.
>>
>> Any help would be appreciated.
> Try changing resolveProxies to true.
Well, how can I? ;) Still using Rational Rose.
Okay, I think I found the general issue. I thought that modeling a field
by reference results in the same ecore model as modeling an
association, but this is apparently not the case, since the ecore
specific attribute for a field and a reference differ (as in this case:
a reference has the resolveProxies field, an attribute not).
Therefore my problem results from modeling generics in Rational Rose
(since a generic reference is modeled as attribute <<reference>> E:
attached). Thus, I can't set or use the default value of the ecore
propertues. :(
I know, from my last post, that you are not involved in Rational Rose
anymore.
Is there a comparable tool to Rational Rose for free?
Thanks again!
Maik
>>
>> Maik
>>
|
|
|
| Re: EMF References using Generics, Proxy are created [message #468464 is a reply to message #468436] |
Wed, 05 August 2009 15:34 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020609080404000302090002
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Maik,
Comments below.
Maik Wurdel wrote:
> Ed,
>
> thanks for your fast response and comments.
>
>
> Ed Merks schrieb:
>> Maik,
>>
>> Comments below.
>>
>> Maik Wurdel wrote:
>>> Hi,
>>>
>>> I'm exploring the support for generics in EMF and facing a problem
>>> when having a generic reference in a class and using the generated
>>> editor.
>>>
>>> Basically what I want to have is a generic class with an attribute
>>> to attach a certain object by reference.
>>>
>>> The generated interface, which is exactly what I want to have, looks
>>> like this:
>>>
>>> public interface LTSStateTransitionAttached<E> extends
>>> LTSStateTransition {
>>>
>>> E getAttached();
>>>
>>> void setAttached(E value);
>>>
>>> }
>>>
>>> The corresponging ecore snippet:
>>>
>>> <eClassifiers xsi:type="ecore:EClass"
>>> name="LTSStateTransitionAttached"
>>> eSuperTypes="#//lts/LTSStateTransition">
>>> <eTypeParameters name="E"/>
>>> <eStructuralFeatures xsi:type="ecore:EReference"
>>> name="attached" resolveProxies="false">
>> So cross document references will not be supported.
>>> <eGenericType
>>> eTypeParameter="#//lts/profiles/LTSStateTransitionAttached/E "/>
>>> </eStructuralFeatures>
>>> </eClassifiers>
>>>
>>> So far so good.
>>>
>>> When I use the generated editor I'm following the common approach of
>>> loading a resource and being able to use the property view to
>>> reference arbitrary objects to set the field, "attached" in this case.
>>>
>>> However, when I close the editor and re-open it the reference are
>>> proxies.
>> Are they in other resources?
>
> Yes they are.
>
>>>
>>> Am I right, that those references should be resolved, and if not
>>> possible proxies are created?
>> Cross document references are always created as proxies and then
>> there is an attempt to resolve them when first they are access (which
>> you've disabled).
>
> What is the purpose of a not resolving proxy?
There are cases where the reference is assumed to be in the same
resource. An example in Ecore is references to type parameters. In XML
Schema, IDREFs are a good example.
> When I'm trying to access an attribute of the object the proxy should
> always be resolved or at least the corresponding attribute.
No doubt.
> Otherwise null is returned.
> For me the only question for a proxies is when it is resolved not if. :)
>
>>>
>>> As far as I can tell this problem is related to attributes with a
>>> generic type. I already compared the way the references are
>>> serialized to attributes with a fixed type. Since those attributes
>>> are supposed to implement references hrefs are used, in both cases.
>>>
>>> Any help would be appreciated.
>> Try changing resolveProxies to true.
>
> Well, how can I? ;) Still using Rational Rose.
There are Rose properties.
> Okay, I think I found the general issue. I thought that modeling a
> field by reference results in the same ecore model as modeling an
> association, but this is apparently not the case, since the ecore
> specific attribute for a field and a reference differ (as in this
> case: a reference has the resolveProxies field, an attribute not).
Yes.
>
> Therefore my problem results from modeling generics in Rational Rose
> (since a generic reference is modeled as attribute <<reference>> E:
> attached). Thus, I can't set or use the default value of the ecore
> propertues. :(
I see now.
>
> I know, from my last post, that you are not involved in Rational Rose
> anymore.
I could use it for free while at IBM.
>
> Is there a comparable tool to Rational Rose for free?
The Ecore Tools project supports a very nice graphical editor that I use
instead of Rose. Look at all the nice diagrams I used it for:
< http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.ht ml>
http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.ht ml
>
> Thanks again!
> Maik
>
>
>>>
>>> Maik
>>>
>
--------------020609080404000302090002
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Maik,<br>
<br>
Comments below.<br>
<br>
<br>
Maik Wurdel wrote:
<blockquote cite="mid:h5c4le$m5s$1@build.eclipse.org" type="cite">Ed,
<br>
<br>
thanks for your fast response and comments.
<br>
<br>
<br>
Ed Merks schrieb:
<br>
<blockquote type="cite">Maik,
<br>
<br>
Comments below.
<br>
<br>
Maik Wurdel wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
I'm exploring the support for generics in EMF and facing a problem when
having a generic reference in a class and using the generated editor.
<br>
<br>
Basically what I want to have is a generic class with an attribute to
attach a certain object by reference.
<br>
<br>
The generated interface, which is exactly what I want to have, looks
like this:
<br>
<br>
public interface LTSStateTransitionAttached<E> extends
LTSStateTransition {
<br>
<br>
E getAttached();
<br>
<br>
void setAttached(E value);
<br>
<br>
}
<br>
<br>
The corresponging ecore snippet:
<br>
<br>
<eClassifiers xsi:type="ecore:EClass"
name="LTSStateTransitionAttached"
eSuperTypes="#//lts/LTSStateTransition">
<br>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF References using Generics, Proxy are created [message #478406 is a reply to message #468464] |
Thu, 06 August 2009 09:23 |
Maik Wurdel
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Thanks Ed.
I tried the Ecore Diagram of the Ecore Tools. Look really mature.
However, it is inconvenient to have a diagra for each package.
Otherwise I'd take for sure.
Maik
Ed Merks schrieb:
> Maik,
>
> Comments below.
>
>
> Maik Wurdel wrote:
>> Ed,
>>
>> thanks for your fast response and comments.
>>
>>
>> Ed Merks schrieb:
>>> Maik,
>>>
>>> Comments below.
>>>
>>> Maik Wurdel wrote:
>>>> Hi,
>>>>
>>>> I'm exploring the support for generics in EMF and facing a problem
>>>> when having a generic reference in a class and using the generated
>>>> editor.
>>>>
>>>> Basically what I want to have is a generic class with an attribute
>>>> to attach a certain object by reference.
>>>>
>>>> The generated interface, which is exactly what I want to have, looks
>>>> like this:
>>>>
>>>> public interface LTSStateTransitionAttached<E> extends
>>>> LTSStateTransition {
>>>>
>>>> E getAttached();
>>>>
>>>> void setAttached(E value);
>>>>
>>>> }
>>>>
>>>> The corresponging ecore snippet:
>>>>
>>>> <eClassifiers xsi:type="ecore:EClass"
>>>> name="LTSStateTransitionAttached"
>>>> eSuperTypes="#//lts/LTSStateTransition">
>>>> <eTypeParameters name="E"/>
>>>> <eStructuralFeatures xsi:type="ecore:EReference"
>>>> name="attached" resolveProxies="false">
>>> So cross document references will not be supported.
>>>> <eGenericType
>>>> eTypeParameter="#//lts/profiles/LTSStateTransitionAttached/E "/>
>>>> </eStructuralFeatures>
>>>> </eClassifiers>
>>>>
>>>> So far so good.
>>>>
>>>> When I use the generated editor I'm following the common approach of
>>>> loading a resource and being able to use the property view to
>>>> reference arbitrary objects to set the field, "attached" in this case.
>>>>
>>>> However, when I close the editor and re-open it the reference are
>>>> proxies.
>>> Are they in other resources?
>>
>> Yes they are.
>>
>>>>
>>>> Am I right, that those references should be resolved, and if not
>>>> possible proxies are created?
>>> Cross document references are always created as proxies and then
>>> there is an attempt to resolve them when first they are access (which
>>> you've disabled).
>>
>> What is the purpose of a not resolving proxy?
> There are cases where the reference is assumed to be in the same
> resource. An example in Ecore is references to type parameters. In XML
> Schema, IDREFs are a good example.
>> When I'm trying to access an attribute of the object the proxy should
>> always be resolved or at least the corresponding attribute.
> No doubt.
>> Otherwise null is returned.
>> For me the only question for a proxies is when it is resolved not if. :)
>>
>>>>
>>>> As far as I can tell this problem is related to attributes with a
>>>> generic type. I already compared the way the references are
>>>> serialized to attributes with a fixed type. Since those attributes
>>>> are supposed to implement references hrefs are used, in both cases.
>>>>
>>>> Any help would be appreciated.
>>> Try changing resolveProxies to true.
>>
>> Well, how can I? ;) Still using Rational Rose.
> There are Rose properties.
>> Okay, I think I found the general issue. I thought that modeling a
>> field by reference results in the same ecore model as modeling an
>> association, but this is apparently not the case, since the ecore
>> specific attribute for a field and a reference differ (as in this
>> case: a reference has the resolveProxies field, an attribute not).
> Yes.
>>
>> Therefore my problem results from modeling generics in Rational Rose
>> (since a generic reference is modeled as attribute <<reference>> E:
>> attached). Thus, I can't set or use the default value of the ecore
>> propertues. :(
> I see now.
>>
>> I know, from my last post, that you are not involved in Rational Rose
>> anymore.
> I could use it for free while at IBM.
>>
>> Is there a comparable tool to Rational Rose for free?
> The Ecore Tools project supports a very nice graphical editor that I use
> instead of Rose. Look at all the nice diagrams I used it for:
> < http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.ht ml>
>
> http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.ht ml
>
>>
>> Thanks again!
>> Maik
>>
>>
>>>>
>>>> Maik
>>>>
>>
|
|
|
| Re: EMF References using Generics, Proxy are created [message #478690 is a reply to message #478406] |
Thu, 06 August 2009 12:28 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Maik,
You can drag things from other models onto the diagram surface. You
load them into additional resources and then can use them the Change
model's diagram makes use of this to use EObject...
Maik Wurdel wrote:
> Thanks Ed.
>
> I tried the Ecore Diagram of the Ecore Tools. Look really mature.
> However, it is inconvenient to have a diagra for each package.
> Otherwise I'd take for sure.
>
> Maik
>
> Ed Merks schrieb:
>> Maik,
>>
>> Comments below.
>>
>>
>> Maik Wurdel wrote:
>>> Ed,
>>>
>>> thanks for your fast response and comments.
>>>
>>>
>>> Ed Merks schrieb:
>>>> Maik,
>>>>
>>>> Comments below.
>>>>
>>>> Maik Wurdel wrote:
>>>>> Hi,
>>>>>
>>>>> I'm exploring the support for generics in EMF and facing a problem
>>>>> when having a generic reference in a class and using the generated
>>>>> editor.
>>>>>
>>>>> Basically what I want to have is a generic class with an attribute
>>>>> to attach a certain object by reference.
>>>>>
>>>>> The generated interface, which is exactly what I want to have,
>>>>> looks like this:
>>>>>
>>>>> public interface LTSStateTransitionAttached<E> extends
>>>>> LTSStateTransition {
>>>>>
>>>>> E getAttached();
>>>>>
>>>>> void setAttached(E value);
>>>>>
>>>>> }
>>>>>
>>>>> The corresponging ecore snippet:
>>>>>
>>>>> <eClassifiers xsi:type="ecore:EClass"
>>>>> name="LTSStateTransitionAttached"
>>>>> eSuperTypes="#//lts/LTSStateTransition">
>>>>> <eTypeParameters name="E"/>
>>>>> <eStructuralFeatures xsi:type="ecore:EReference"
>>>>> name="attached" resolveProxies="false">
>>>> So cross document references will not be supported.
>>>>> <eGenericType
>>>>> eTypeParameter="#//lts/profiles/LTSStateTransitionAttached/E "/>
>>>>> </eStructuralFeatures>
>>>>> </eClassifiers>
>>>>>
>>>>> So far so good.
>>>>>
>>>>> When I use the generated editor I'm following the common approach
>>>>> of loading a resource and being able to use the property view to
>>>>> reference arbitrary objects to set the field, "attached" in this
>>>>> case.
>>>>>
>>>>> However, when I close the editor and re-open it the reference are
>>>>> proxies.
>>>> Are they in other resources?
>>>
>>> Yes they are.
>>>
>>>>>
>>>>> Am I right, that those references should be resolved, and if not
>>>>> possible proxies are created?
>>>> Cross document references are always created as proxies and then
>>>> there is an attempt to resolve them when first they are access
>>>> (which you've disabled).
>>>
>>> What is the purpose of a not resolving proxy?
>> There are cases where the reference is assumed to be in the same
>> resource. An example in Ecore is references to type parameters. In
>> XML Schema, IDREFs are a good example.
>>> When I'm trying to access an attribute of the object the proxy
>>> should always be resolved or at least the corresponding attribute.
>> No doubt.
>>> Otherwise null is returned.
>>> For me the only question for a proxies is when it is resolved not
>>> if. :)
>>>
>>>>>
>>>>> As far as I can tell this problem is related to attributes with a
>>>>> generic type. I already compared the way the references are
>>>>> serialized to attributes with a fixed type. Since those attributes
>>>>> are supposed to implement references hrefs are used, in both cases.
>>>>>
>>>>> Any help would be appreciated.
>>>> Try changing resolveProxies to true.
>>>
>>> Well, how can I? ;) Still using Rational Rose.
>> There are Rose properties.
>>> Okay, I think I found the general issue. I thought that modeling a
>>> field by reference results in the same ecore model as modeling an
>>> association, but this is apparently not the case, since the ecore
>>> specific attribute for a field and a reference differ (as in this
>>> case: a reference has the resolveProxies field, an attribute not).
>> Yes.
>>>
>>> Therefore my problem results from modeling generics in Rational Rose
>>> (since a generic reference is modeled as attribute <<reference>> E:
>>> attached). Thus, I can't set or use the default value of the ecore
>>> propertues. :(
>> I see now.
>>>
>>> I know, from my last post, that you are not involved in Rational
>>> Rose anymore.
>> I could use it for free while at IBM.
>>>
>>> Is there a comparable tool to Rational Rose for free?
>> The Ecore Tools project supports a very nice graphical editor that I
>> use instead of Rose. Look at all the nice diagrams I used it for:
>> < http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.ht ml>
>>
>> http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.ht ml
>>
>>>
>>> Thanks again!
>>> Maik
>>>
>>>
>>>>>
>>>>> Maik
>>>>>
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue Apr 16 09:55:36 GMT 2024
Powered by FUDForum. Page generated in 1.39800 seconds |
] 
Search
Help
Register
Login
Home
