Eclipse Community Forums: EMF » derived containments and eContents

Help

Home

Home » Modeling » EMF » derived containments and eContents

Show: Today's Messages :: Show Polls :: Message Navigator

derived containments and eContents [message #484458]

Mon, 07 September 2009 14:46

Knut Wannheden

Messages: 298
Registered: July 2009

Senior Member

Hi,

I have an EClass with an EReference declared both as "containment" and
"derived" (and "volatile"). The implementing class computes the values on the
fly every time the reference is queried. (The reason behind making it a
"containment" reference is that this often is a requirement in GMF.)

Now when I call eContents() on the container object it doesn't include any of
the objects owned by the "derived" containment. The reason seems to be the way
EClassImpl#getEAllStructuralFeatures() is implemented.

I could not find anything about this in the EMF book? What is the reasoning
behind this?

As an alternative I think I could use a non "derived" containment and have an
adapter which updates the contents of the reference as required (i.e. when the
underlying parts of the model change). Is that the recommended way to do this?

Regards,

--knut

Report message to a moderator

Re: derived containments and eContents [message #484464 is a reply to message #484458]

Mon, 07 September 2009 14:58

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Knut,

Comments below.

Knut Wannheden wrote:
> Hi,
>
> I have an EClass with an EReference declared both as "containment" and
> "derived" (and "volatile").
This is already starting to sound bad.
> The implementing class computes the values on the fly every time the
> reference is queried.
New ones each time?
> (The reason behind making it a "containment" reference is that this
> often is a requirement in GMF.)
Also kind of bad...
>
> Now when I call eContents() on the container object it doesn't include
> any of the objects owned by the "derived" containment. The reason
> seems to be the way EClassImpl#getEAllStructuralFeatures() is
> implemented.
>
> I could not find anything about this in the EMF book? What is the
> reasoning behind this?
Derived is really meant to mark features that are computed from the
values of other features. Given that EObjects really do know their
eContainer and even their eContainmentFeature it's not really possible
for a containment reference to be derived because this would lead to an
inconsistency...
>
> As an alternative I think I could use a non "derived" containment and
> have an adapter which updates the contents of the reference as
> required (i.e. when the underlying parts of the model change). Is that
> the recommended way to do this?
Perhaps you could spell out in more detail the nature of the problem
you're trying to solve because it's not immediately obvious to be what
to suggest...
>
> Regards,
>
> --knut

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: derived containments and eContents [message #484500 is a reply to message #484464]

Mon, 07 September 2009 18:43

Knut Wannheden

Messages: 298
Registered: July 2009

Senior Member

Hi Ed,

Thanks for the reply.

Ed Merks wrote:
> Knut Wannheden wrote:
>> I could not find anything about this in the EMF book? What is the
>> reasoning behind this?
> Derived is really meant to mark features that are computed from the
> values of other features. Given that EObjects really do know their
> eContainer and even their eContainmentFeature it's not really possible
> for a containment reference to be derived because this would lead to an
> inconsistency...

Makes sense. Should there be a corresponding validation?

>> As an alternative I think I could use a non "derived" containment and
>> have an adapter which updates the contents of the reference as
>> required (i.e. when the underlying parts of the model change). Is that
>> the recommended way to do this?
> Perhaps you could spell out in more detail the nature of the problem
> you're trying to solve because it's not immediately obvious to be what
> to suggest...

I would like to add GMF side-affixed children to a node figure. AFAIK the
model elements corresponding to the side-affixed children have to be
contained by the element corresponding to the node figure. However, in my
model there are no real child elements, so for this purpose I create new
transient elements. These transient elements are really just references to
other model elements, which are directly or indirectly referenced by the
model element of the node. But these real model elements are not directly
contained by the main element...

Regards,

--knut

Report message to a moderator

Re: derived containments and eContents [message #484607 is a reply to message #484500]

Tue, 08 September 2009 13:43

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Knut,

Comments below.

Knut Wannheden wrote:
> Hi Ed,
>
> Thanks for the reply.
>
> Ed Merks wrote:
>> Knut Wannheden wrote:
>>> I could not find anything about this in the EMF book? What is the
>>> reasoning behind this?
>> Derived is really meant to mark features that are computed from the
>> values of other features. Given that EObjects really do know their
>> eContainer and even their eContainmentFeature it's not really
>> possible for a containment reference to be derived because this would
>> lead to an inconsistency...
>
> Makes sense. Should there be a corresponding validation?
There are cases, such as delegation to a feature map, where the
containment is validly derived. It's these kinds of cases where the
eContents() wants to preserve the feature map's order and hence it's
special handling of derived.
>
>>> As an alternative I think I could use a non "derived" containment
>>> and have an adapter which updates the contents of the reference as
>>> required (i.e. when the underlying parts of the model change). Is
>>> that the recommended way to do this?
>> Perhaps you could spell out in more detail the nature of the problem
>> you're trying to solve because it's not immediately obvious to be
>> what to suggest...
>
> I would like to add GMF side-affixed children to a node figure. AFAIK
> the model elements corresponding to the side-affixed children have to
> be contained by the element corresponding to the node figure. However,
> in my model there are no real child elements, so for this purpose I
> create new transient elements. These transient elements are really
> just references to other model elements, which are directly or
> indirectly referenced by the model element of the node. But these real
> model elements are not directly contained by the main element...
It kind of sucks to have to "butcher" the model to make a viewer happy.
Perhaps you should model these placeholder elements as real containment
references, not derived ones and have them hold non-containment
references to other things...
>
> Regards,
>
> --knut
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	Discovering referenced models
Next Topic:	Re: How to make sure that a resource is written

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 11:23:01 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter