[news.eclipse.platform] Re: Does jface databinding support treeviewer?

[Matthew Hall <matthall@xxxxxxxxxxxxxxxxx>]

hao wrote:
> Hi,
>
> I have some questions regarding PersonGroupLabelProvider class 
> implmentations:
>
> 1. For its constructor - PersonGroupLabelProvider(IObservableSet 
> knownElements), what's the input - knownElements and how could I set it 
> up? can it be a null. It looks like the class does not use it at all.

The input is contentProvider.getKnownElements(), just like with 
ObservableMapLabelProvider

> 2. What does the following call of method BeansObservables.observeMaps() 
> do to the argument - personPhoneKnownElements? I am trying to understand 
> why we need to pass a new instance of WritableSet(). I guess it should 
> be some kind of wrapper of the business model object - PersonPhoneGroups 
> clas. Actually, it is not. Why? personPhoneKnownElements = new 
> WritableSet();
> IObservableMap[] maps = BeansObservables.observeMaps(
>    personPhoneKnownElements,
>    PersonPhone.class,
>    new String[] { "name", "email", "phone", "mobilePhone1", 
> "mobilePhone2" } );

personPhoneKnownElements becomes the keySet of the maps in the returned 
IObservableMap array.  In each map, the value associated with each key 
is the value of the named property.

Thus, given a set of users:
{ dave = ["Dave", "dave@xxxxxxxxxxx", "123-456-7890", null, null],
  george = ["George", "george@xxxxxxxxxxxxxxx", "800-555-5555", null, 
null] }

maps[0] == { dave : "Dave", george : "George" }
maps[1] == { dave : "dave@xxxxxxxxxxx", george : "george@xxxxxxxxxxxxxxx" }
etc

Thus, when you add or remove an element from the known elements set, 
this automatically adds/removes the entry with that key from the 
associated IObservableMaps.

The problem in your case is that you have two different types of objects 
in your tree: PersonPhone and PersonPhoneGroup.  However 
BeansObservables.observeMaps(knownElementsSet, PersonPhone.class, 
propertyArray) expects knownElementsSet to only contain instances of 
PersonPhone.  The original known elements set violates this constraint 
by containing both types.

The solution I advocated separates the original known elements set into 
two separate sets: personPhoneKnownElements (for PersonPhone instances) 
and personPhoneGroupKnownElements (for PersonPhoneGroup instances). 
These observable sets only contain instances of the correct types, so 
they can be safely passed to BeansObservables.observeMaps().

The final part of the solution lies in the behavior of 
ListeneingLabelProvider.  ListeningLabelProvider calls the 
addListenerTo(element) method for every element in the set at the time 
of construction.  It also registers an ISetChangeListener on the set, 
and calls addListenerTo(element) and removeListenerFrom(element) 
whenever elements are added to / removed from the set.  We implement 
these methods in PersonGroupLabelProvider and use instanceof to 
determine which observable set the belong to.

> 3. I have already implemented ITableLableProvider. Why do I need to 
> implement PersonGroupLabelProvider instead, just use my original 
> ITableLableProvider?
>
> Using PersonGroupLabelProvider works for this test case. I just try 
> convince myself that's the way I must do.

You need to implement ITableLabelProvider so that the tree viewer will 
recognize that your label provider supports columns.  It should not be 
very involved, you just need to delegate each call to 
personPhoneLabelProvider or personPhoneGroupLabelProvider depending on 
the runtime type of the element.

Hope this helps.

Matthew