Bug 263850

Comment 1 Matthew Hall 2009-02-05 16:08:18 EST

Boris, do you recall why the event type constants were kept private?

Comment 2 Matthew Hall 2009-02-05 16:09:34 EST

Tom, have you looked into using SimpleListProperty for this?

Comment 3 Thomas Schindl 2009-02-05 16:29:48 EST

Yes but as far as I've seen the ObservableListContentProvider needs an IObservableList so it doesn't help me or am I mistaken? I've ported the new properties API to EMF last week and now write an EMF-Example application for it.

The code looks like this:

		viewer = new TableViewer(form);
		ObservableListContentProvider cp = new ObservableListContentProvider();
		viewer.setContentProvider(cp);
		CondiditionalTemplate defaultTemplate = new CondiditionalTemplate(
				"${0}") {

			@Override
			public boolean isTemplate(EObject element) {
				return element.eGet(EXTLibraryPackage.Literals.LIBRARY__NAME) != null;
			}
		};
		IObservableMap map = EMFEditObservables.observeMap(
				p.getEditingDomain(), cp.getKnownElements(),
				EXTLibraryPackage.Literals.LIBRARY__NAME);
		viewer.setLabelProvider(new ObservableColumnLabelProvider(
				new IObservableMap[] { map }, Collections
						.singletonList(defaultTemplate)));
		EList<EObject> list = p.getLibraries();
		viewer.setInput(new EWritableList<EObject>(list));

I'll use it for my EclipseCon presentation on Datacentric RCP applications!

Comment 4 Matthew Hall 2009-02-05 16:36:56 EST

I'm thinking of something like this (see also bug 263868 which I just CC'd to you).

class SelfListProperty extends SimpleListProperty {
  protected List doGetList(Object source) {
    // the observable caches the result of this method, so we must clone it
    // to prevent computed diffs from always being empty
    return new ArrayList((List) source);
  }
  
  protected void doSetList(Object source, List list, ListDiff diff) {
    diff.applyTo((List)source);
  }
  
  public INativePropertyListener adaptListener(
        ISimplePropertyListener listener) {
    // ignored, no listener API
  }
  
  protected void doAddListener(Object source,
        INativePropertyListener listener) {
    // ignored
  }
                  
  protected void doRemoveListener(Object source,
        INativePropertyListener listener) {
    // ignored
  }
}

With something like this you could do wrap a List in an IObservableValue fairly simply:

List list = ...
IObservableList observableList = new SelfListProperty().observe(list);

This is what I have in mind for bug 263868, what you need would be a minor extension to it to add support for EList.move().

Comment 5 Thomas Schindl 2009-02-05 16:40:36 EST

oh that's nice skipped the incoming mail from this bug and commented here before hand. I faced exactly the "problem" you described in your last blog (addding e.g. all those getterCalled() calls to make ObservableTracker happy :-) 

Comment 6 Thomas Schindl 2009-02-05 16:42:33 EST

Another possibility would be to provide an AbstractObservableList which only has implements the addListChangeListener because then the TYPE must not be public any more.

Comment 7 Matthew Hall 2009-02-05 17:06:04 EST

Tom, you're aware that there are two base IObservableList implementations?

* AbstractObservableList extends java.util.AbstractList, you pretty much have to implement everything yourself
* ObservableList extends AbstractObservable, embeds the concept of a wrapped list.  This is probably the one you want to extend.

Both of these implementations provide default addListChangeListener() / removeListChangeListener() implementations.  Am I missing something?

Comment 8 Thomas Schindl 2009-02-05 17:11:49 EST

I know but they didn't made 100% sense to me for subclassing when wrapping in an EMF-List because I had to overwrite at least all of the write-methods.

Comment 9 Thomas Schindl 2009-02-07 17:48:48 EST

I've now implemented the possibility to observe an Resource#getContents() in bug 262160 but I would need the possibility to access the TYPE-Attribute. The class making this happen is org.eclipse.emf.databinding.internal.EWritableList.

Comment 10 Matthew Hall 2009-02-09 17:14:42 EST

I would prefer to leave this field private--it was always intended for internal use only (kind of like Device.internal_new_GC) and the only reason it is public is to make it visible between packages in the core bundle.  Now that I think of it we should probably mark those methods as @noreference..

In addition, I'm concerned with your plan to implement IObservableList directly since the interface is tagged @noimplement and directs implementers to subclass one of the classes in the framework.  This is so we can evolve the interfaces as needed--e.g. we could not have added IObservable.isDisposed() or IObservableList.move() without this provision.

I think if we look at the problem together we can come up with an agreeable solution that doesn't require introducing these fields as API.  Can you help me understand what's missing or doesn't fit well with the existing ObservableList or AbstractObservableList classes?

Also, have you considered implementing a NotifyingListProperty instead of an observable?

Comment 11 Matthew Hall 2009-02-16 19:00:23 EST

WONTFIX.  Implementers should extend ObservableList, AbstractObservableList or DecoratingObservableList, which already implement the add/remove listener methods.