[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.tools.emf] Re: Any documentation with delegating ELists
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