GEF

GEF

GEF(Graphical Editing Framework)是一個圖形化編輯框架,它允許開發人員以圖形化的方式展示和編輯模型,從而提升用戶體驗。這樣的應用程式有很多,例如:UML類圖編輯器、圖形化XML編輯器、界面設計工具以及圖形化資料庫結構設計工具等等。 GEF(GMP exchange factor)是鳥苷酸交換因子,在受體絡氨酸激酶信號轉導途徑中的Ras蛋白GTP-GDP轉換機制中與Ras蛋白結合促使與Ras蛋白結合的GDP釋放。

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活動。

相關詞條

相關搜尋

熱門詞條

聯絡我們