eclipseRCP深入淺出（學習總結）2015.08.08

5.4.2 Content Providers Overview

TreeViewer需要ContentProvider實現ITreeContentProvider接口，這樣Treeviewer纔可以遍歷input進去的對象的樹形結構：

public interface ITreeContentProvider extends IStructuredContentProvider { public Object[] getChildren(Object parentElement); public Object getParent(Object element); public boolean hasChildren(Object element);
}方法中的參數就是treeviewer中要顯示的元素，ContactsView創建後會調用TreeView.setInput(Object)方法，這時候反過來ITreeContentProvider會調用getChildren()方法遍歷setInput進來的對象，它首先它的第一層元素，但是第一層元素是不用來顯示的，它作爲一個出發點，用來創建其他可視的樹節點。

ContentProvider和input的模型對象該如何交互有如下四種可能的技術：

1、模型對象實現ITreeContentProvider接口；實現接口即給ContactsEntry和ContactsGroup模型添加了它的方法，getChildren()、getParents()等等，這雖然直接但是暴露了底層模型的內在結構，這種方式的缺點就是把模型和UI層耦合在一起，這兩層最好還是實現解耦。

2、用一個實現了ITreeContentProvider接口的對象包裝模型對象；這樣做擺脫了第一種方式的限制，但是卻產生了另外一種開銷，一個模型對象還有一個對應實現了ITreeContentProvider接口的對象，說白了就是，一個抽象模型對應了兩個對象。這樣做給每個模型對象的身份鑑定帶來了難度，當想鑑定兩個抽象模型是否相同時，不僅要比較他們的對象模型，還要比較那個包裝對象。一個抽象模型由兩個對象唯一標識。

3、自己寫一個自定義的ContentProvider；TreeViewer可以自定義，而且我們也可以寫自己的ContentProvider,我們只需實現ITreeContentProvider接口，這個接口就可以訪問模型對象，遍歷它的樹形結構。這種方法必須控制所有的provider，而且也不可擴展，因爲我們必須提前知道所有可操作對象的類型。

4、給模型對象添加ContentProvider所必須的功能函數；這種方法使用了Eclipse的適配器機制，來繼承模型對象的方法，WorkBench定義了標準的ContentProvider叫做BaseWorkBenchContentProvider,它知道如何遍歷IWorkBenchAdaptable類型：

public interface IWorkbenchAdapter {
public Object[] getChildren(Object o);
public ImageDescriptor getImageDescriptor(Object object);
public String getLabel(Object o);
public Object getParent(Object o);
}
官方對這個接口的解釋是：這個接口爲workbench elements提供了可視化描述和層級結構，讓這些元素可以在UI組件中顯示，而不用知道這些元素的具體實現。