GEF簡介
歸結一下，可以發現它們在圖形化編輯方面具有以下共同之處：
提供一個編輯區域和一個工具條，用戶在工具條里選擇需要的工具，以拖動或單擊的方式將節點或連線放置在編輯區域；
節點可以包含子節點；
用戶能夠查看和修改某個節點或連線的大部分屬性；
連線端點錨定在節點上；
提供上下文選單和鍵盤命令；
提供圖形的縮放功能；
提供一個大綱視圖，顯示編輯區域的縮略圖，或是樹狀模型結構；
支持撤消/重做功能；
等等。
工作界面
基於GEF的界面設計工具（Visual Editor，VE）的工作界面
GEF最早是Eclipse的一個內部項目，後來逐漸轉變為Eclipse的一個開源工具項目，Eclipse的不少其他子項目都需要它的支持。Eclipse 3.0版本花了很大功夫在從Platform中剝離各種功能部件上，包括GEF和IDE在內的很多曾經只能在Eclipse內部使用的工具成為可以獨立使用的軟體/外掛程式包了。理論上我們是可以脫離Eclipse用GEF包構造自己的應用程式的，但由於它們之間天然的聯繫，而且Eclipse確實是一個很值得支持的開發平台，所以我還是推薦你在Eclipse中使用它。
GEF的優勢是提供了標準的MVC（Model-View-Control）結構，開發人員可以利用GEF來完成以上這些功能，而不需要自己重新設計。與其他一些MVC編輯框架相比，GEF的一個主要設計目標是儘量減少模型和視圖之間的依賴，好處是可以根據需要選擇任意模型和視圖的組合，而不必受開發框架的局限（不過實際上還是很少有脫離Draw2D的實現）。
現在來看看GEF是如何實現MVC框架的吧，在這個帖子裡我們先概括介紹一下它的各個組成部分，以後將結合例子進行更詳細的說明。
GEF結構圖
模型：GEF的模型只與控制器打交道，而不知道任何與視圖有關的東西。為了能讓控制器知道模型的變化，應該把控制器作為事件監聽者註冊在模型中，當模型發生變化時，就觸發相應的事件給控制器，後者負責通知各個視圖進行更新。
典型的模型對象會包含PropertyChangeSupport類型的成員變數，用來維護監聽器成員即控制器；對於與其他對象具有連線關係的模型，要維護連入/連出的連線列表；如果模型對應的節點具有大小和位置信息，還要維護它們。這些變數並不是模型本身必須的信息，維護它們使模型變得不夠清晰，但你可以通過構造一些抽象模型類（例如讓所有具有連線的模型對象繼承Node類）來維持它們的可讀性。
相對來講GEF中模型是MVC中最簡單的一部分。
控制器：我們知道，在MVC結構里控制器是模型與視圖之間的橋樑，也是整個GEF的核心。它不僅要監聽模型的變化，當用戶編輯視圖時，還要把編輯結果反映到模型上。舉個例子來說，用戶在資料庫結構圖上刪除一個表時，控制器應該從模型中刪除這個表對象、表中的欄位對象、以及與這些對象有關的所有連線。當然在GEF中這些操作不是由直接控制器完成的，這個稍後就會說到。
GEF中的控制器是所謂的EditPart對象，更確切的說應該是一組EditPart對象共同組成了GEF的控制器這部分，每一個模型對象都對應一個EditPart對象。你的應用程式中需要有一個EditPartFactory對象負責根據給定模型對象創建對應的EditPart對象，這個工廠類將被視圖利用。
RootEditPart是一種特殊的EditPart，它和你的模型沒有任何關係，它的作用是把EditPartViewer和contents（應用程式的最上層EditPart，一般代表一塊畫布）聯繫起來，可以把它想成是contents的容器。EditPartViewer有一個方法setRootEditPart()專門用來指定視圖對應的RooEditPart。
EditPart對象
用戶的編輯操作被轉換為一系列請求（Request），有很多種類的請求，這些種類在GEF里被稱為角色（Role），GEF里有圖形化和非圖形化這兩大類角色，前者比如Layout Role對應和布局有關的的操作，後者比如Connection Role對應和連線有關的操作等等。角色這個概念是通過編輯策略（EditPolicy）來實現的，EditPolicy的主要功能是根據請求創建相應的命令（Command），而後者會直接操作模型對象。對每一個EditPart，你都可以"安裝"一些EditPolicy，用戶對這個EditPart的特定操作會被交給已安裝的對應EditPolicy處理。這樣做的直接好處是可以在不同EditPart之間共享一些重複操作。
在GEF SDK提供的幫助文檔（GEF開發指南）里有一份詳細的EditPolicy、Role和Request類型列表，這裡就不贅述了。
視圖：前面說過，GEF的視圖可以有很多種，GEF目前提供了圖形（GraphicalViewer）和樹狀（TreeViewer）這兩種，前者利用Draw2D圖形（IFigure）作為表現方式，多用於編輯區域，後者則多用於實現大綱展示。視圖的任務同樣繁重，除了模型的顯示功能以外，還要提供編輯功能、回顯（Feedback）、工具提示（ToolTip）等等。
GEF使用EditPartViewer作為視圖，它的作用和JFace中的Viewer十分類似，而EditPart就相當於是它的ContentProvider和LabelProvider，通過setContents()方法來指定。我們經常使用的Editor是一個GraphicalEditorWithPalette（GEF提供的Editor，是EditorPart的子類，具有圖形化編輯區域和一個工具條），這個Editor使用GraphicalEditViewer和PaletteViewer這兩個視圖類，PaletteViewer也是GraphicalEditViewer的子類。開發人員要在configureGraphicalViewer()和initializeGraphicalViewer()這兩個方法裡對EditPartViewer進行定製，包括指定它的contents和EditPartFactory等等。
EditPartViewer同時也是ISelectionProvider，這樣當用戶在編輯區域做選擇操作時，註冊的SelectionChangeListener就可以收到選擇事件。EditPartViewer會維護各個EditPart的選中狀態，如果沒有被選中的EditPart，則預設選中的是作為contents的EditPart。
初步了解了GEF的MVC實現方式，讓我們看看典型的GEF應用程式是什麼樣子的。大部分GEF應用程式都實現為Eclipse的Editor，也就是說整個編輯區域是放置在一個Editor里的。所以典型的GEF應用程式具有一個圖形編輯區域包含在一個Editor（例如GraphicalEditorWithPalette）里，可能有一個大綱視圖和一個屬性頁，一個用於創建EditPart實例的EditPartFactory，一些表示業務的模型對象，與模型對象對應的一些EditPart，每個EditPart對應一個IFigure的子類對象顯示給用戶，一些EditPolicy對象，以及一些Command對象。
GEF應用程式的工作方式如下： EditPartViewer接受用戶的操作，例如節點的選擇、新增或刪除等等，每個節點都對應一個EditPart對象，這個對象有一組按操作Role分開的EditPolicy，每個EditPolicy會對應一些Command對象，Command最終對模型進行直接修改。用戶的操作轉換為Request分配給適當的EditPolicy，由後者創建適當的Command來修改模型，這些Command會保留在EditDomain（專門用於維護EditPartViewer、Command等信息的對象，一般每個Editor對應唯一一個該對象）的命令堆疊里，用於實現撤消/重做功能。
GEF全球環境基金
Global Environment Facility，全球環境組織，一個致力於環境保護的NGO組織。
全球環境基金（GEF）是關於生物多樣性、氣候變化、持久性有機污染物和土地荒漠化的國際公約的資金機制。GEF通過其業務規劃，支持開發中國家和經濟轉型國家在生物多樣性、氣候變化、國家水域、臭氧層損耗、土地退化和持久性有機污染物的重點領域上開展活動，取得全球效益。
自1991年啟動以來，GEF已通過1000多個項目，向140多個開發中國家和經濟轉型國家提供了大約40億美元贈款，並從各種渠道吸引了120億美元的項目融資。2002年8月，32個捐資國保證，在隨後4年內，向GEF提供近30億美元，用於GEF活動。
