Home » Modeling » EMF » Add structural feature at runtime to generated class
|
| Re: Add structural feature at runtime to generated class [message #428265 is a reply to message #428264] |
Mon, 16 March 2009 16:58   |
 Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Philip,
Comments below.
Philip Langer wrote:
> Hi,
>
> I'm curious if there is a possibility to generically add a structural
> feature to a not programatically generated EClass at runtime!
>
Yes, you can, but once instances of the model exist, it should be
treated as immutable.
> I need to annotate instances of any EClass by adding a simple String
> attribute. This annotation must be serializable to XMI and again be
> accessible after deserialization. As I have to keep it generic I don't
> know the specific EClass at runtime. So what I need to do is somehow the
> dynamic extension of an EClass with a single EAttribute to annotate its
> instances...
>
> I thought about getting the EClass from an EObject and adding an
> EStructuralFeature (my annotation with my own namespace) at runtime.
> Unfortunately this somehow won't work with compiled classes...
>
Definitely not. And given you an an EObject already, you have to treat
it as immutable.
> Is this possible? Or is there a better way to annotate EObject instances
> from one serializiation->deserialization to another?
>
Generally the model itself should define the mechanism for annotation or
decoration. Java, XML Schema, and Ecore are all examples where the
support for annotations is part of the design.
> I hope I could explain my problem clear enough :-)
>
XML Schema-style wildcards might be useful... But the model still needs
to explicitly define such support.
> Thank you very, very much in advance!!!
>
> Greetings,
>
> Philip
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Add structural feature at runtime to generated class [message #428268 is a reply to message #428265] |
Mon, 16 March 2009 18:51 |
Philip Langer
Messages: 31
Registered: July 2009 |
Member |
|
|
Ed,
thank you very much for your fast reply!
Unfortunately XML Schema wildcards aren't suitable for my problem as I
won't have the possibility to influence/extend the meta model.
Concretely, we somehow need to annotate EObjects (instances of any
EClass) with an ID to recognize the specific instances even after intense
modification without knowing the meta model to support every DSL, UML2
models, etc and every editor used by the client.
We send the model as XMI file to the client and after the client changed
the model we receive it again as XMI file. Then we reliably need to know
which origin model element corresponds to the changed model element.
Heuristics like used by EMF Compare unfortunately aren't enough.
It works if we manually add the IDs with a custom namespace in the XMI
file directly. These IDs usually won't get lost or changed by any editor.
Now we would need a nice programmatic way to achieve this -- independent
from the meta model.
It would be great if you could give us some hints to realize it!
Thanks a lot!
Greetings,
Philip
Am Mon, 16 Mar 2009 12:58:13 -0400 schrieb Ed Merks:
> Philip,
>
> Comments below.
>
> Philip Langer wrote:
>> Hi,
>>
>> I'm curious if there is a possibility to generically add a structural
>> feature to a not programatically generated EClass at runtime!
>>
> Yes, you can, but once instances of the model exist, it should be
> treated as immutable.
>> I need to annotate instances of any EClass by adding a simple String
>> attribute. This annotation must be serializable to XMI and again be
>> accessible after deserialization. As I have to keep it generic I don't
>> know the specific EClass at runtime. So what I need to do is somehow
>> the dynamic extension of an EClass with a single EAttribute to annotate
>> its instances...
>>
>> I thought about getting the EClass from an EObject and adding an
>> EStructuralFeature (my annotation with my own namespace) at runtime.
>> Unfortunately this somehow won't work with compiled classes...
>>
> Definitely not. And given you an an EObject already, you have to treat
> it as immutable.
>> Is this possible? Or is there a better way to annotate EObject
>> instances from one serializiation->deserialization to another?
>>
> Generally the model itself should define the mechanism for annotation or
> decoration. Java, XML Schema, and Ecore are all examples where the
> support for annotations is part of the design.
>> I hope I could explain my problem clear enough :-)
>>
> XML Schema-style wildcards might be useful... But the model still needs
> to explicitly define such support.
>> Thank you very, very much in advance!!!
>>
>> Greetings,
>>
>> Philip
>>
|
|
|
| Re: Add structural feature at runtime to generated class [message #428269 is a reply to message #428268] |
Mon, 16 March 2009 19:00 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080604000900000408000102
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Philip,
Comments below.
Philip Langer wrote:
> Ed,
>
> thank you very much for your fast reply!
>
> Unfortunately XML Schema wildcards aren't suitable for my problem as I
> won't have the possibility to influence/extend the meta model.
>
> Concretely, we somehow need to annotate EObjects (instances of any
> EClass) with an ID to recognize the specific instances even after intense
> modification without knowing the meta model to support every DSL, UML2
> models, etc and every editor used by the client.
>
So you could use xmi:id then...
> We send the model as XMI file to the client and after the client changed
> the model we receive it again as XMI file. Then we reliably need to know
> which origin model element corresponds to the changed model element.
> Heuristics like used by EMF Compare unfortunately aren't enough.
> It works if we manually add the IDs with a custom namespace in the XMI
> file directly. These IDs usually won't get lost or changed by any editor.
> Now we would need a nice programmatic way to achieve this -- independent
> from the meta model.
>
If you specialize XMLResourceImpl to have useUUIDs return true, you're
serialization will include xmi:id and UUIDs will automatically be
associated with your objects.
> It would be great if you could give us some hints to realize it!
>
I refer to these as extrinsic IDs since the resource manages them rather
than the object directly managing them.
> Thanks a lot!
>
> Greetings,
>
> Philip
>
> Am Mon, 16 Mar 2009 12:58:13 -0400 schrieb Ed Merks:
>
>
>> Philip,
>>
>> Comments below.
>>
>> Philip Langer wrote:
>>
>>> Hi,
>>>
>>> I'm curious if there is a possibility to generically add a structural
>>> feature to a not programatically generated EClass at runtime!
>>>
>>>
>> Yes, you can, but once instances of the model exist, it should be
>> treated as immutable.
>>
>>> I need to annotate instances of any EClass by adding a simple String
>>> attribute. This annotation must be serializable to XMI and again be
>>> accessible after deserialization. As I have to keep it generic I don't
>>> know the specific EClass at runtime. So what I need to do is somehow
>>> the dynamic extension of an EClass with a single EAttribute to annotate
>>> its instances...
>>>
>>> I thought about getting the EClass from an EObject and adding an
>>> EStructuralFeature (my annotation with my own namespace) at runtime.
>>> Unfortunately this somehow won't work with compiled classes...
>>>
>>>
>> Definitely not. And given you an an EObject already, you have to treat
>> it as immutable.
>>
>>> Is this possible? Or is there a better way to annotate EObject
>>> instances from one serializiation->deserialization to another?
>>>
>>>
>> Generally the model itself should define the mechanism for annotation or
>> decoration. Java, XML Schema, and Ecore are all examples where the
>> support for annotations is part of the design.
>>
>>> I hope I could explain my problem clear enough :-)
>>>
>>>
>> XML Schema-style wildcards might be useful... But the model still needs
>> to explicitly define such support.
>>
>>> Thank you very, very much in advance!!!
>>>
>>> Greetings,
>>>
>>> Philip
>>>
>>>
>
>
--------------080604000900000408000102
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Philip,<br>
<br>
Comments below.<br>
<br>
Philip Langer wrote:
<blockquote cite="mid:gpm73l$bem$1@build.eclipse.org" type="cite">
<pre wrap="">Ed,
thank you very much for your fast reply!
Unfortunately XML Schema wildcards aren't suitable for my problem as I
won't have the possibility to influence/extend the meta model.
Concretely, we somehow need to annotate EObjects (instances of any
EClass) with an ID to recognize the specific instances even after intense
modification without knowing the meta model to support every DSL, UML2
models, etc and every editor used by the client.
</pre>
</blockquote>
So you could use xmi:id then...<br>
<blockquote cite="mid:gpm73l$bem$1@build.eclipse.org" type="cite">
<pre wrap="">
We send the model as XMI file to the client and after the client changed
the model we receive it again as XMI file. Then we reliably need to know
which origin model element corresponds to the changed model element.
Heuristics like used by EMF Compare unfortunately aren't enough.
It works if we manually add the IDs with a custom namespace in the XMI
file directly. These IDs usually won't get lost or changed by any editor.
Now we would need a nice programmatic way to achieve this -- independent
from the meta model.
</pre>
</blockquote>
If you specialize XMLResourceImpl to have useUUIDs return true, you're
serialization will include xmi:id and UUIDs will automatically be
associated with your objects.<br>
<blockquote cite="mid:gpm73l$bem$1@build.eclipse.org" type="cite">
<pre wrap="">
It would be great if you could give us some hints to realize it!
</pre>
</blockquote>
I refer to these as extrinsic IDs since the resource manages them
rather than the object directly managing them.<br>
<blockquote cite="mid:gpm73l$bem$1@build.eclipse.org" type="cite">
<pre wrap="">
Thanks a lot!
Greetings,
Philip
Am Mon, 16 Mar 2009 12:58:13 -0400 schrieb Ed Merks:
</pre>
<blockquote type="cite">
<pre wrap="">Philip,
Comments below.
Philip Langer wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I'm curious if there is a possibility to generically add a structural
feature to a not programatically generated EClass at runtime!
</pre>
</blockquote>
<pre wrap="">Yes, you can, but once instances of the model exist, it should be
treated as immutable.
</pre>
<blockquote type="cite">
<pre wrap="">I need to annotate instances of any EClass by adding a simple String
attribute. This annotation must be serializable to XMI and again be
accessible after deserialization. As I have to keep it generic I don't
know the specific EClass at runtime. So what I need to do is somehow
the dynamic extension of an EClass with a single EAttribute to annotate
its instances...
I thought about getting the EClass from an EObject and adding an
EStructuralFeature (my annotation with my own namespace) at runtime.
Unfortunately this somehow won't work with compiled classes...
</pre>
</blockquote>
<pre wrap="">Definitely not. And given you an an EObject already, you have to treat
it as immutable.
</pre>
<blockquote type="cite">
<pre wrap="">Is this possible? Or is there a better way to annotate EObject
instances from one serializiation->deserialization to another?
</pre>
</blockquote>
<pre wrap="">Generally the model itself should define the mechanism for annotation or
decoration. Java, XML Schema, and Ecore are all examples where the
support for annotations is part of the design.
</pre>
<blockquote type="cite">
<pre wrap="">I hope I could explain my problem clear enough :-)
</pre>
</blockquote>
<pre wrap="">XML Schema-style wildcards might be useful... But the model still needs
to explicitly define such support.
</pre>
<blockquote type="cite">
<pre wrap="">Thank you very, very much in advance!!!
Greetings,
Philip
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------080604000900000408000102--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Add structural feature at runtime to generated class [message #428270 is a reply to message #428268] |
Mon, 16 March 2009 19:51 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
This sounds like you want to use UUIDs, not?
Tom
Philip Langer schrieb:
> Ed,
>
> thank you very much for your fast reply!
>
> Unfortunately XML Schema wildcards aren't suitable for my problem as I
> won't have the possibility to influence/extend the meta model.
>
> Concretely, we somehow need to annotate EObjects (instances of any
> EClass) with an ID to recognize the specific instances even after intense
> modification without knowing the meta model to support every DSL, UML2
> models, etc and every editor used by the client.
>
> We send the model as XMI file to the client and after the client changed
> the model we receive it again as XMI file. Then we reliably need to know
> which origin model element corresponds to the changed model element.
> Heuristics like used by EMF Compare unfortunately aren't enough.
> It works if we manually add the IDs with a custom namespace in the XMI
> file directly. These IDs usually won't get lost or changed by any editor.
> Now we would need a nice programmatic way to achieve this -- independent
> from the meta model.
>
> It would be great if you could give us some hints to realize it!
>
> Thanks a lot!
>
> Greetings,
>
> Philip
>
> Am Mon, 16 Mar 2009 12:58:13 -0400 schrieb Ed Merks:
>
>> Philip,
>>
>> Comments below.
>>
>> Philip Langer wrote:
>>> Hi,
>>>
>>> I'm curious if there is a possibility to generically add a structural
>>> feature to a not programatically generated EClass at runtime!
>>>
>> Yes, you can, but once instances of the model exist, it should be
>> treated as immutable.
>>> I need to annotate instances of any EClass by adding a simple String
>>> attribute. This annotation must be serializable to XMI and again be
>>> accessible after deserialization. As I have to keep it generic I don't
>>> know the specific EClass at runtime. So what I need to do is somehow
>>> the dynamic extension of an EClass with a single EAttribute to annotate
>>> its instances...
>>>
>>> I thought about getting the EClass from an EObject and adding an
>>> EStructuralFeature (my annotation with my own namespace) at runtime.
>>> Unfortunately this somehow won't work with compiled classes...
>>>
>> Definitely not. And given you an an EObject already, you have to treat
>> it as immutable.
>>> Is this possible? Or is there a better way to annotate EObject
>>> instances from one serializiation->deserialization to another?
>>>
>> Generally the model itself should define the mechanism for annotation or
>> decoration. Java, XML Schema, and Ecore are all examples where the
>> support for annotations is part of the design.
>>> I hope I could explain my problem clear enough :-)
>>>
>> XML Schema-style wildcards might be useful... But the model still needs
>> to explicitly define such support.
>>> Thank you very, very much in advance!!!
>>>
>>> Greetings,
>>>
>>> Philip
>>>
>
|
|
|
| Re: Add structural feature at runtime to generated class [message #428361 is a reply to message #428269] |
Wed, 18 March 2009 08:43 |
Philip Langer
Messages: 31
Registered: July 2009 |
Member |
|
|
Hi Ed, hi Tom,
thank you both for your great help!
The usage of xmi:id by extending XMLResourceImpl sounds exactly what I
was looking for.
I will try that! Thanks again!
Philip
Am Mon, 16 Mar 2009 15:00:04 -0400 schrieb Ed Merks:
> Philip,
>
> Comments below.
>
> Philip Langer wrote:
>> Ed,
>>
>> thank you very much for your fast reply!
>>
>> Unfortunately XML Schema wildcards aren't suitable for my problem as I
>> won't have the possibility to influence/extend the meta model.
>>
>> Concretely, we somehow need to annotate EObjects (instances of any
>> EClass) with an ID to recognize the specific instances even after
>> intense modification without knowing the meta model to support every
>> DSL, UML2 models, etc and every editor used by the client.
>>
> So you could use xmi:id then...
>> We send the model as XMI file to the client and after the client
>> changed the model we receive it again as XMI file. Then we reliably
>> need to know which origin model element corresponds to the changed
>> model element. Heuristics like used by EMF Compare unfortunately aren't
>> enough. It works if we manually add the IDs with a custom namespace in
>> the XMI file directly. These IDs usually won't get lost or changed by
>> any editor. Now we would need a nice programmatic way to achieve this
>> -- independent from the meta model.
>>
> If you specialize XMLResourceImpl to have useUUIDs return true, you're
> serialization will include xmi:id and UUIDs will automatically be
> associated with your objects.
>> It would be great if you could give us some hints to realize it!
>>
> I refer to these as extrinsic IDs since the resource manages them rather
> than the object directly managing them.
>> Thanks a lot!
>>
>> Greetings,
>>
>> Philip
>>
>> Am Mon, 16 Mar 2009 12:58:13 -0400 schrieb Ed Merks:
>>
>>
>>> Philip,
>>>
>>> Comments below.
>>>
>>> Philip Langer wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm curious if there is a possibility to generically add a structural
>>>> feature to a not programatically generated EClass at runtime!
>>>>
>>>>
>>> Yes, you can, but once instances of the model exist, it should be
>>> treated as immutable.
>>>
>>>> I need to annotate instances of any EClass by adding a simple String
>>>> attribute. This annotation must be serializable to XMI and again be
>>>> accessible after deserialization. As I have to keep it generic I
>>>> don't know the specific EClass at runtime. So what I need to do is
>>>> somehow the dynamic extension of an EClass with a single EAttribute
>>>> to annotate its instances...
>>>>
>>>> I thought about getting the EClass from an EObject and adding an
>>>> EStructuralFeature (my annotation with my own namespace) at runtime.
>>>> Unfortunately this somehow won't work with compiled classes...
>>>>
>>>>
>>> Definitely not. And given you an an EObject already, you have to
>>> treat it as immutable.
>>>
>>>> Is this possible? Or is there a better way to annotate EObject
>>>> instances from one serializiation->deserialization to another?
>>>>
>>>>
>>> Generally the model itself should define the mechanism for annotation
>>> or decoration. Java, XML Schema, and Ecore are all examples where the
>>> support for annotations is part of the design.
>>>
>>>> I hope I could explain my problem clear enough :-)
>>>>
>>>>
>>> XML Schema-style wildcards might be useful... But the model still
>>> needs to explicitly define such support.
>>>
>>>> Thank you very, very much in advance!!!
>>>>
>>>> Greetings,
>>>>
>>>> Philip
>>>>
>>>>
>>>>
>>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html>
> <head>
> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
> <title></title>
> </head>
> <body bgcolor="#ffffff" text="#000000"> Philip,<br>
> <br>
> Comments below.<br>
> <br>
> Philip Langer wrote:
> <blockquote cite="mid:gpm73l$bem$1@build.eclipse.org" type="cite">
> <pre wrap="">Ed,
>
> thank you very much for your fast reply!
>
> Unfortunately XML Schema wildcards aren't suitable for my problem as I
> won't have the possibility to influence/extend the meta model.
>
> Concretely, we somehow need to annotate EObjects (instances of any
> EClass) with an ID to recognize the specific instances even after
> intense modification without knowing the meta model to support every
> DSL, UML2 models, etc and every editor used by the client.
> </pre>
> </blockquote>
> So you could use xmi:id then...<br>
> <blockquote cite="mid:gpm73l$bem$1@build.eclipse.org" type="cite">
> <pre wrap="">
> We send the model as XMI file to the client and after the client changed
> the model we receive it again as XMI file. Then we reliably need to know
> which origin model element corresponds to the changed model element.
> Heuristics like used by EMF Compare unfortunately aren't enough. It
> works if we manually add the IDs with a custom namespace in the XMI file
> directly. These IDs usually won't get lost or changed by any editor. Now
> we would need a nice programmatic way to achieve this -- independent
> from the meta model.
> </pre>
> </blockquote>
> If you specialize XMLResourceImpl to have useUUIDs return true, you're
> serialization will include xmi:id and UUIDs will automatically be
> associated with your objects.<br>
> <blockquote cite="mid:gpm73l$bem$1@build.eclipse.org" type="cite">
> <pre wrap="">
> It would be great if you could give us some hints to realize it!
> </pre>
> </blockquote>
> I refer to these as extrinsic IDs since the resource manages them rather
> than the object directly managing them.<br> <blockquote
> cite="mid:gpm73l$bem$1@build.eclipse.org" type="cite">
> <pre wrap="">
> Thanks a lot!
>
> Greetings,
>
> Philip
>
> Am Mon, 16 Mar 2009 12:58:13 -0400 schrieb Ed Merks:
>
> </pre>
> <blockquote type="cite">
> <pre wrap="">Philip,
>
> Comments below.
>
> Philip Langer wrote:
> </pre>
> <blockquote type="cite">
> <pre wrap="">Hi,
>
> I'm curious if there is a possibility to generically add a structural
> feature to a not programatically generated EClass at runtime!
>
> </pre>
> </blockquote>
> <pre wrap="">Yes, you can, but once instances of the model exist, it
> should be
> treated as immutable.
> </pre>
> <blockquote type="cite">
> <pre wrap="">I need to annotate instances of any EClass by adding
> a simple String
> attribute. This annotation must be serializable to XMI and again be
> accessible after deserialization. As I have to keep it generic I don't
> know the specific EClass at runtime. So what I need to do is somehow the
> dynamic extension of an EClass with a single EAttribute to annotate its
> instances...
>
> I thought about getting the EClass from an EObject and adding an
> EStructuralFeature (my annotation with my own namespace) at runtime.
> Unfortunately this somehow won't work with compiled classes...
>
> </pre>
> </blockquote>
> <pre wrap="">Definitely not. And given you an an EObject already,
> you have to treat
> it as immutable.
> </pre>
> <blockquote type="cite">
> <pre wrap="">Is this possible? Or is there a better way to
> annotate EObject
> instances from one serializiation->deserialization to another?
>
> </pre>
> </blockquote>
> <pre wrap="">Generally the model itself should define the mechanism
> for annotation or
> decoration. Java, XML Schema, and Ecore are all examples where the
> support for annotations is part of the design.
> </pre>
> <blockquote type="cite">
> <pre wrap="">I hope I could explain my problem clear enough :-)
>
> </pre>
> </blockquote>
> <pre wrap="">XML Schema-style wildcards might be useful... But the
> model still needs
> to explicitly define such support.
> </pre>
> <blockquote type="cite">
> <pre wrap="">Thank you very, very much in advance!!!
>
> Greetings,
>
> Philip
>
> </pre>
> </blockquote>
> </blockquote>
> <pre wrap=""><!---->
> </pre>
> </blockquote>
> </body>
> </html>
|
|
|
Goto Forum:
Current Time: Thu Apr 18 12:21:06 GMT 2024
Powered by FUDForum. Page generated in 0.01931 seconds |
] 
Search
Help
Register
Login
Home
