|
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
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
|