[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.platform] Re: [Databinding] Problem with MasterDetail and EObjectObservableMap 
Boris,

thanks for your hint, in fact, this is exactly what I already did. The point that I was trying to make - and I admit that this has not been very clear - is that I was hoping that this functionality could - somehow? - be provided by the framework itself. I still think that the scenario described by me is not a "special" case, I rather tend to claim that this is the "general" case and the EMFEditObservables "only" handles a "special" case (where all children of the master list are of the same type).

Michael

Boris Bokowski wrote: 
Michael,

I would be surprised if you could not implement a variant of EMFEditObservables.observeDetailList that works the way you need it to. The method observeDetailList is a convenience method for MasterDetailObservables.detailList(master, listFactory, propertyType); you should be able to write a list factory that wraps the original one but first performs whatever checks you need.

Boris

"Michael Haeberlen" <haeber@xxxxxxxxxx> wrote in message news:g0k68c$8vi$1@xxxxxxxxxxxxxxxxxxxx 
Ed,

I'm not quite sure I understand. (actually I don't know what a "wildcard feature" is). So, you are saying that the solution I sketched will not work in general? Would you agree that in my special case I described it does work? Or do you see problems even there? (however, I don't think this solution makes it worse, logically at least).
Or are you saying that I should not use a ComputedList the way I did in order to combine the two lists? (btw., forget the line with the "UnionList" it should have been commented out)

The other question is what else could I do in order to fix the problem (and still use (emf-)databinding) ?

Thanks,
Michael

Ed Merks wrote: 
Michael,

This approach would end up not supporting open content features, i.e., features of a document root that are accepted by a wildcard feature of the actual class. I don't think you should be applying it for invalid cases. I believe it fails with an exception right now if you do that, which seems to me the right approach.


Michael Haeberlen wrote: 
Sorry, the method in EMFEditObservables has to be changed to:

public IObservable createObservable(Object target)
{
if (eStructuralFeature.getEContainingClass().isSuperTypeOf(((EObject) target).eClass()))
{
return observeList(realm, domain, (EObject)target, eStructuralFeature);
}
return new EmptyObservableList(realm, eStructuralFeature);
}

i.e. we must not return null here.


Michael


Michael Haeberlen wrote: 
Hi,

I am using a org.eclipse.jface.databinding.viewers.ObservableListTreeContentProvider as content provider in my master tree view. I use a IObservableFactory which provides a combination of two IObservableList lists like follows:

public IObservable createObservable(Object target) {
final IObservableList list1 = EMFEditObservables.observeList(domain, target, XYZPackage.Literals.TARGET_FEATURE1);
final IObservableList list2 = EMFEditObservables.observeList(domain, target, XYZPackage.Literals.TARGET_FEATURE2);
return new UnionList(new IObservableList[] {categoryList, childList});
return new ComputedList() {
protected List calculate() {
List list = new ArrayList(list1.size()+list2.size());
list.addAll(list1);
list.addAll(list2);
return list;
}
};
}

So now I have objects in my tree which represent different features, and so I have different details pages.
In the details pages, I have code like this:

IObservableValue selection = ViewersObservables.observeSingleSelection(viewer); //viewer is the master view tree viewer
EMFEditObservables.observeDetailList(realm, domain, selection, XYZPackage.Literals.FEATURE_OF_SELECTION));

And here is my problem: EMFEditObservables uses a IObservableFactory which assumes that the target (=selection) is always an EObject having the specified feature:

public IObservable createObservable(Object target)
{
return observeList(realm, domain, (EObject)target, eStructuralFeature);
}

If the above method was changed to the following:

public IObservable createObservable(Object target)
{
if (eStructuralFeature.getEContainingClass().isSuperTypeOf(((EObject)target).eClass()))
{
return observeList(realm, domain, (EObject)target, eStructuralFeature);
}
return null;
}

then my problem is gone.
Before opening a bug I just wanted to ask if this is the right way to solve it or if I should have done something different?

Thanks,
Michael