擴展Eclipse的Java開發工具(三)

2019-11-18 13:03:09

字體：大中小

來源：轉載

供稿：網友

　　如何擴展 JDT 的特定元素的用戶界面（象 Outline 視圖中的成員）？擴展視圖還是它們的底層模型？
　　簡單的“Hello, World”示例顯示了添加菜單選項只需要在插件清單文件中添加幾行 xml（）以及一個處理實際操作的類（com.ibm.lab.helloworld.SampleAction）。向視圖的下拉菜單、公共編輯器的工具欄以及彈出菜單添加操作基本上很簡單。所提供的彈出菜單歸結為兩類：一類只與視圖相關而與所選的對象無關（也就是，對視圖的“空白處”單擊鼠標右鍵通常會顯示的“缺省”彈出菜單），另一類則更常見，它們與應用于所選對象的選項相關。在我們的例子中，我們希望目標只是具體選擇的對象，所以通過在插件清單文件中定義一個擴展，我們將提供的操作對象提供給這些對象的彈出菜單（對下面幾個標識符進行了縮寫，以獲得更佳的格式；用‘…’表示），如清單 8 所示。
　　
　　清單 8. 修飾符操作
　　
　　<extension point="org.eclipse.ui.popupMenus">
　　　<objectContribution
　　　　　objectClass="org.ecl　　　　　id="...imember">
　　　　　
　　　　<menu
　　　　　　label="Soln: Modifiers"
　　　　　　path="group.reorganize"
　　　　　　id="...imember.modifiers">
　　　　　<separator name="group1"/>
　　　　　<separator name="group2"/>
　　　　</menu>
　　　　
　　　　<action
　　　　　label="　　　　　menubarPath="...imember.modifiers/group1"
　　　　　class="...jdt.excerpt.MakeIMemberPrivateAction"
　　　　　id="...imember.makeprivate">
　　　　</action>
　　　　
　　　　<action
　　　　　label="Protected"
　　　　　menubarPath="...imember.modifiers/group1"
　　　　　class="...jdt.excerpt.MakeIMemberProtectedAction"
　　　　　id="...imember.makeprotected">
　　　　</action>
　　　　
　　　　...all menu choices not shown...
　　　　
　　　</objectContribution>
　　</extension>
　　
　　擴展點命名為 org.eclipse.ui.popupMenus，顧名思義，它定義了向出現在工作臺中的彈出菜單提供的對象。這個非凡示例只提供給明確選擇的對象，即實現 IMember 接口的對象（請回憶一下 java 語言規范中的定義，成員包含方法和字段）。我們的研究沒有白費；我們得到了當前問題的答案，我們差不多預備好回答下一個問題了。
　　
　　在這樣做之前，此時請注重，我們找到的用于簡單“Hello, World”操作示例的模式將對所提供的其它菜單操作進行重復。即，將把選擇更改告知 class 屬性中指定的類（通過其 selectionChanged 方法），并還將告知它用戶何時選擇菜單選項（通過其 run 方法）。我們“旅行”的用戶界面部分快要結束了；更困難的部分，也是影響我們所期望更改的部分還在前面。正如下一個問題所說的那樣，在繼續之前只要做一兩次觀察。
　　
　　Package EXPlorer 中顯示的元素和其它視圖（如 Outline 視圖）中顯示的相同元素之間有什么關系？我們的擴展是否需要知道它們之間的任何區別？
　　
　　您可能已經注重到，當您在 Outline 視圖和 Hierarchy 視圖中選擇了一個方法時，所選對象的類并非總是相同的。例如，假如您在 Package Explorer 中展開一個庫（JAR 文件）的內容，隨后選擇了一個類（或方法），那么它也不會是 Java 編輯器的 Outline 視圖中同一選擇的那個類。到底怎么回事？
　　
　　這里，我們正在觀察 JDT 的 Java 模型中“可編輯的”部分和始終為只讀的部分之間的差別。這兩部分 Java 模型都實現了公共接口（象 IMember），但是它們擁有用來理解底層限制的實現類是不同的。另一個示例是，有一個表示 Java 編譯單元的實現類，它派生自 Package Explorer 所顯示的 JAR 文件的 .class 文件，還有另一個類表示直接派生自 .java 文件的編譯單元。后一個實現將答應進行一些前者所不答應的修改，而它們 API 的共享部分是由接口 ICompilationUnit 表示的。
　　
　　您以前在編輯 Java 源代碼時，一定會觀察到：在您輸入方法特征符時 Outline 視圖進行了更新（假如您沒有注重到，那就試一下！）。這個示例說明了 JDT 如何在不同的區域暫放其“未提交的更改”，這與處理那些已保存、編譯和集成到 Java 模型中的更改不同。有些視圖（象 Java 編輯器的 Outline 視圖）知道未提交的更改和已提交的更改，而其它象 Navigator 這樣的視圖只關心已保存到文件系統的已提交更改。
　　
　　隨后，我們所提供的用來修改 Java 成員的操作必須（至少在某種程度上）知道在什么上下文中調用它。即，它必須識別出某些所選成員是可修改的（那些位于 Java 編輯器的 Outline 視圖中的成員），而另一些成員是不可以修改的（存儲在 JAR 文件中以及顯示在 Package Explorer 中的 .class 文件中的成員）。記住這一點，讓我們繼續下一個問題。
　　
　　如何通過編程更改 JDT 模型？
　　假如您在前面的“旅行”中稍作了研究，那么可能已經注重到 IMember、IJavaElement 以及我們的操作所看到的由所選的與 Java 相關的項實現的作為大部分接口的那部分都沒有 setXXX 方法。那么如何修改這些接口呢？
　　
　　您將發現這出奇地簡單，不過可能在直覺上不那么明顯。JDT 的 Java 模型在大多數實踐情況下都是“只讀”的。通過與 Java 編譯器的集成協作，給定元素的底層 Java 源代碼進行的更改就與 Java 模型的其余部分的更改同步了。實際上，您要做的就是更新 Java 源代碼，而對模型所作的其余必要更改就傳送給任何依靠它們的元素中。例如，每當 Java 源代碼／Java 模型發生更改時，JDT 的索引會自動更新，所以仍然可以快速執行搜索，重新編譯從屬類（按照項目特性中指定的 Java 構建路徑所指示的），等等。
　　
　　可以大松一口氣了！以下就是 Java 模型是插件集成之要害的原因所在：Java 模型提供了整個 Java 環境的常見的內存中共享的模型，它的范圍從一個項目，一直到其所有被引用的庫，所有這些都不要您費心去操作文件系統中的 .java 文件、.class 文件以及 .jar 文件。您可以將精力集中于高級模型，而讓 JDT 處理這其中的許多雜亂細節。
　　
　　還不能確信它很輕易？清單 9 包含了這個解決方案的核心代碼的一小部分，它是從提供操作的 run 方法上抽取出的，并出于可讀性考慮，稍作了簡化：
　　
　　清單 9. selectionChanged 方法，小型解決方案
　　
　　public void selectionChanged(IAction action, ISelection selection) {
　　　IMember member = (IMember)
　　　　　((IStrUCturedSelection) selection).getFirstElement();
　　　ICompilationUnit cu = member.getCompilationUnit();
　　
　　　if (cu.isWorkingCopy()) {
　　　　IBuffer buffer = cu.getBuffer();
　　　　buffer.replace(...);
　　　　cu.reconcile();
　　　}
　　}
　　
　　似乎有點虎頭蛇尾，不是嗎？對您提供的操作提供了選中的成員，向它請求其父容器（Java .class 或 .java 文件的模型，用 JDT 的說法，全都稱為編譯單元），因為其父容器治理底層源代碼，驗證該成員是否屬于“未提交的” Java 模型（換句話說，它目前在編輯器中是打開的），然后修改作為緩沖器返回的源代碼。IBuffer 接口類似于 StringBuffer，其原理不同之處在于，更改與編譯單元相關的緩沖區更新了 Java 模型的對應元素。對 reconcile 的最終調用告知 JDT 去通知其它相關各方（象 Package Explorer 視圖）：您的模型更新已預備好作為公共消費品。
　　
　　您一定注重到上述代碼中的省略號。在那里，您必須分析源代碼本身以進行修改。同樣，JDT 會提供幫助，正如我們將在下一個問題中看到的。

上一篇：擴展Eclipse的Java開發工具(一)

下一篇：Step-by-Step 使用 SWT 開發 GUI