|
| Re: Containment proxies and resolving ELists [message #1715713 is a reply to message #1715707] |
Wed, 25 November 2015 12:17   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Markus,
Comments below.
On 25/11/2015 12:21 PM, Markus Scheidgen wrote:
> Hi,
>
> following situation: I have two resources, each contains an object.
> Containment proxies are enabled in the corresponding .genmodel. One
> object references the other via a containment reference and
> additionally via a non containment (regular cross) reference.
Is the containment reference bidirectional? I.e., do you have a
container reference involved?
> When I navigate from one object to the other via the containment
> reference, the referenced object is resolved correctly and its
> container (eContainer) is set properly.
Yes, the containment proxy resolution mechanism is designed to support
the case of a unidirectional containment reference that, when resolved,
also sets the opposite, i.e., the eContainer.
> When I navigate from one object to the other via the cross reference,
> it is also resolved, but its container is not set.
Yes, unless there is a proxy for the container, there is no way to know
where it is contained. Only the container knows this information, i.e.,
vi the proxy, in which case the contained object's eContainer is not
set, or via a resolved reference, in which case the process of resolving
sets the eContainer.
> A look in the implementation (EcoreEList::resolve(EObject proxy))
> reveals that EMF only sets the container of the resolved object, if
> the EList represents a containment reference (via
> ECoreEList::isContainment).
Indeed.
> I would expect the implementation to use the proxy's
> eContainingFeature and eContainer to determine and set the resolved
> object's container, no matter if the resolving EList represents
> containment or not.
There are typically two proxies involved. One held by the containment
reference and one by the container reference. The one used for the
non-containment reference has no eContainer set.
>
> Is this intentional?
One can't generally know this from the proxy held by the non-containment
reference.
> Is this a bug?
No.
> Do I understand the implementation wrong?
You're just observing the expected behavior. The only way to get around
this problem is to ensure that the cross-resource-contained object has a
proxy that references its container. That's only possible if you
define a container reference for it and set it to be non-transient so
that the serialization contains a proxy. Then you can always start with
that object and know where it is contained, without having navigated to
it from its container.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.03110 seconds
] 
Search
Help
Register
Login
Home
