|
Since Foo is the container for Bar, I'll add Bar to
my list and directly call InternalEObject.eBasicSetContainer and pass in the Foo
object.
Randall,
The Bar objects have to behave as if they are already in the list and if a
relation is bidirectional, both ends have to behave as if the results are
already there on demand. Most definitely there can be no calls to add or
set to make this happen. Since the Bar object is new, you can call
InternalEObject.eInverseAdd to set only the one half of the bidirectional
relation (or if Foo is the container for Bar, you could call
InternalEObject.eBasicSetContainer for directly). If the relation is not
a containment, you could add a proxy for Foo to Bar and it will resolve later.
Randall Hauch wrote:
Thanks, Frank
and Ed. I think I've got
part of it working, but I'm running into a problem that I can't seem to get
my arms around. Lets say my metamodel has two metaclasses, Foo and
Bar, and Foo has a bi-directional containment relationship to Bar. The
generated FooImpl class uses a DelegatingEList in place of it's normal
EList. I then have my own Resource
implementation. Here's the
sequence that's getting me in trouble. A client calls
Resource.getContents() and gets the root-level Foo instance. At this
point, the Foo object hasn't created its DelegatingEList. The client
navigates to the Foo instance, and then calls it's "getBar" method - which
instantiates the DelegatingEList - and then "size()" on the returned
list. At this point, my DelegatingEList goes back to my Resource to
ask it for the Bar objects that are in this Foo object. How do I
create/materialize the Bar objects and add them to the List? The
feature is bi-directional, so if my Resource calls "setFoo(...)" on the Bar
object, the implementation will turn around and as for the List - but this
is what I'm trying to materialize, and I get into a loop. On the other
hand, if I add the Bar objects to the List (which is still my working copy
and not yet returned to the Foo object's DelegatingEList), this list isn't
bi-directional and won't set the Foo reference on the Bar
objects. Am I missing
something? Randall
"Frank
Budinsky" <frankb@xxxxxxxxxx>
wrote in message news:3F574820.1C867514@xxxxxxxxxx...Randall,
You're right that the delegating lists aren't being used anywhere in
EMF itself. They're used by clients that want to wrap their own storage
implementation.
You use them in one of two ways ... both involve subclassing. The first
approach is to override the delegateList() method to return an object
implementing the java.util.List interface, to which the delegating list
will delegate all the storage function. Alternatively, you can override
delegateList() to return null, and then also override all the methods
whose names start with "delegate" to use some other backing store.
The only currently available documentation on these classes is in our
EMF book: http://www.awprofessional.com/titles/0131425420.
It doesn't cover them in great detail either - just an overview and API
description.
Frank.
Randall Hauch wrote:
I'm intriqued by the following feature
listed on the http://www.eclipse.org/emf/
page:
- We have introduced
org.eclipse.emf.common.util.DelegatingEList,
org.eclipse.emf.common.notify.impl.DelegatingNotifyingListImpl, and
org.eclipse.emf.ecore.util.DelegatingEcoreEList to allow clients to
wrap an existing list implementation that they may have as the
"backing store" for a list that implements all the correct EMF
behaviors.
I've
searched the code and have found no use of these lists within the EMF or
XSD plugins. Is there any documentation for how these can be
used? If not, can you provide some direction? I have a
metamodel (i.e., genmodel/ecore model) and generated code, and my goal
is to materialize (lazily) instances of these classes (i.e., a model)
from some backing store. Particularly:
- Are there some logical places to
"wrap" existing list implementations? Modifying generated
impls? I can think of several possibilities, but perhaps there
are one or even a few that are more logical than others.
- What's the mechanism (particularly
in DelegatingEcoreEList) for inserting the logic to populate the list
from the backing store? Are there methods in the
DelegatingEcoreEList that should be overridden? Or, is it more
of a listener pattern?
Thanks in advance. Randall
|