XDoclet 操作
圖 1 顯示了 XDoclet 要求的輸入和生成的輸出。
圖 1. XDoclet 黑盒子
您可以看到，包含嵌入式 XDoclet 標簽的 Java 源代碼是系統的輸入。在 Apache Ant 的驅動下，XDoclet 處理輸入的代碼，生成的輸出文本文件可以是 Java 源代碼、HTML 頁面、XML 文件等。為了處理輸入，XDoclet 需要使用模板（保存在 .xdt 文件中）和標簽處理器（用 Java 編碼）。XDoclet 把模板和標簽處理器打包成“模塊”，不同的“模塊”處理不同的問題域。
XDoclet 生成的結構模型
XDoclet 對包含嵌入式 XDoclet 標簽的輸入 Java 源代碼進行解析，并為代碼建立非常詳細的結構模型。結構模型中的每個元素都代表源代碼中的一個 Java 結構。圖 2 顯示的結構模型，揭示了 XDoclet 跟蹤的代碼構造和關系。
圖 2. XDoclet 的解析的 Java 源代碼的內部結構模型
圖 2 中的結構模型跟蹤類、接口、方法之類的代碼構造（模型元素）。該模型還跟蹤元素之間的關系，例如繼承和接口實現。以內聯注釋的形式嵌入在源代碼中的 XDoclet 標簽被解析為模型元素的屬性，并被跟蹤
深入 XDoclet
圖 3 顯示了 XDoclet 的內部結構，揭示了使其運行的功能塊。
圖 3. XDoclet 內部的功能塊
如圖 3 所示，Apache Ant 在運行的時候控制著 XDoclet 的配置和操作。XDoclet 解析輸入的 Java 源代碼，并在內存中生成結構模型。模板引擎通過處理一組模板和標簽處理器，生成輸出文件。模板和標簽處理器可以是內置的，也可以是定制的。在代碼生成期間，模板和標簽處理器擁有對結構模型的完全訪問。
XDoclet 虛假的復雜性
XDoclet 實質上就是一個通用的 Javadoc 引擎（請參閱側欄，通用的 Javadoc 引擎）。那么，是什么讓它看起來這么復雜呢？答案在于：XDoclet 幾乎從未被單獨討論過，而總是藏在其他許多復雜的技術中。圖 4 顯示了了圍繞在 XDoclet 周圍的復雜性迷霧（請參閱側欄為什么 XDoclet 看起來比實際的要復雜得多）。
|
為什么 XDoclet 看起來比實際的要復雜得多
Apache Ant 自動進行 Java 軟件的生成過程。構建管理過程通常是生產項目中更復雜過程中的一部分。構建管理的術語和概念被集成到 Apache Ant 中，而且是理解其操作的先決條件。成熟的 Ant 腳本可能會非常復雜。Ant 的每個新版本，都會引入一些新的特性集，從而進一步增加了復雜性。這形成了 XDoclet 表面的復雜性，因為 XDoclet 需要 Ant 才能執行。
XDoclet 處理的問題領域是復雜性的另一個來源。在發布 XDoclet 的時候，XDoclet 已經可以為 EJB 組件集成、J2EE Web 容器集成、Hibernate 持久性層、Struts 框架、Java 管理擴展（JMX）等生成代碼。這些問題領域中的每一個領域都有一大套該領域專用的行話和概念。從這些復雜的問題領域出來的問題，經常主導著 XDoclet 的討論，這也提高了 XDoclet 表面的復雜性。可能是“只見森林，不見樹木”。
|
圖 4. XDoclet 的復雜耦合
在圖 4 中，您可以看到 XDoclet 與以下內容是緊密相關的：
- Apache Ant，它控制著 XDoclet 的操作。XDoclet 是作為一組 Ant 任務存在的，沒有 Ant 則不能執行。
- 與生成文件關聯的具體問題領域的一些細節。
posted on 2006-11-05 08:29
xzc 閱讀(529)
評論(0) 編輯 收藏 所屬分類:
Xdoclet