使用Eclipse的Navigator Link Helper實現導航器與編輯器的關聯

實現 LinkHelper

在上個例子中，plugin.xml 中擴充了各類擴充點後，其實並不用我們寫任何 Java 代碼，就能夠在這個 ID 為 com.example.test 的視圖上完成一些 Project Explorer 已實現的操作： 例如建立項目，檔案夾，檔案等，這些是通過重用 navigatorContent 實現的。

另一個需要注意的地 方是，在我們實現的這個視圖中，IResource 作為與 CNF 的直接介面，同時也扮演著“項目 / 檔案夾 / 文 件”這個業務情境的模型角色。（這也是為什麼在 LinkHelper 中 new StructedSelection(file) 能直接定 位到導航器中該節點的原因）

但是在實際的項目開發過程中，並不是每一種業務模型都像檔案系統這 樣易於展現。例如 Java 中的 Package 概念就需要以多個檔案夾合并成一個樹結點的方式展示（中間以“.” 分隔），jar 包也需要以內部解壓的方式展現其內部樹型結構。

所以通常情況下，業務模型會有單獨 的抽象表示，並作為與 CNF 的直接介面。其優點有：

所有在 Eclipse UI 上對模型的改變，會先傳遞到領域模型本身，然後通過 IResource 持久化到作業系統。 對模型的改變操作和改變的傳遞都更直接。如 圖 6所示。

圖 6. Eclipse 中的資源管理

同一套資源檔，通過不同的角度觀察需要有不同的展現，操作及儲存方式。例如一個 Java 項目在 Package Explorer 以更貼近 Java 開發的方式展現與操作，而在 Resource Explorer 則是以作業系統的視角 來展現，顯示所有的檔案夾及檔案。這裡看待資源的角度，就是構建業務模型所要考慮的事情。

接下來我們會在上一個例子的基礎上，加入自己的業務模型層。雖然在檔案和檔案夾這個情境下，這一層 的存在意義不大，但是能供讀者在解決具體的工作時借鑒。

我們仿照上個例子建立一個 custom.linkwitheditor.sample 的外掛程式項目，但這次將自己實現大部分的功能，並加入特定的業務模型層。

首先將 view id 更改為 custom.linkwitheditor.view.myCustomNavigatorView，並添加表徵圖。

刪除 org.eclipse.ui.navigator.viewer 擴充下的 viewerActionBindin —— 這意味著在這個例子我們 並不擴充任何 action，context menus 等。

刪除 org.eclipse.ui.navigator.viewer 擴充下的 viewerContentBinding —— 一會我們會建立自己實 現的 navigatorContent 與 linkHelper。