在新的 JSP 最佳實踐系列的前一篇文章中，您了解了如何使用 JSP include 偽指令將諸如頁眉、頁腳和導航組件之類的靜態內容包含到 Web 頁面中。和服務器端包含一樣，JSP include 偽指令允許某個頁面從另一個頁面提取內容或數據。清單 1 重溫了 include 偽指令。

清單 1. JSP include 偽指令

您需要什么
本系列中的所有最佳實踐都基于 JavaServer Pages 技術。要運行其中的任何最佳實踐，都需要在您的本地機器或測試服務器上安裝符合 JSP 技術的 Web 容器。您還需要使用文本編輯器或 IDE 來對 JSP 頁面編碼。

雖然 include 非常適于將靜態內容并入 Web 頁面，但對于動態內容卻不盡如人意。我們在前一篇文章中在試圖重新裝入高速緩存文件時發現了這一問題。與大多數頁眉文件及頁腳文件不同，動態內容變化頻繁，必須時刻更新。我們將首先扼要地重述一下 include 偽指令的局限性，然后我將向您演示如何用 jsp:include 標記來擴展 JSP 的包含能力。

高速緩存問題
JSP include 偽指令的不足之處有一個是：它會導致 Web 瀏覽器高速緩存所有頁面。在處理諸如頁腳、版權聲明或一組靜態鏈接之類的靜態組件時，這是有意義的。這些文件不會改變，因此沒有理由讓 JSP 解釋器不斷地重新輪詢其中的數據。凡是可能的地方，都應該實現高速緩存，因為它改善了應用程序的性能。

JSP 測試和開發
在構建 Web 應用程序或網站時，可能需要大量更新頁眉、頁腳和導航鏈接。僅僅為了看到對所包含文件所做的更改，而被迫不斷地關閉瀏覽器或清除其高速緩存，這可能是件痛苦的事情。另一方面，為了結束開發周期，而不得不徹底檢查一遍并修改數百個使用了 include 偽指令的頁面，這也是一件痛苦的事情。我的建議是，在測試期間禁用瀏覽器高速緩存。在大多數情形下，這樣做能夠徹底解決問題。也有極少數情形，這樣做并不奏效，這時可以在瀏覽器或服務器上不斷地重新啟動 Web 容器來確保不進行高速緩存。

但是，有時侯，進行高速緩存會得不償失。如果提入的內容來自使用動態數據（如 Weblog 或數據庫驅動的 JSP 文件）的程序，甚至如果所包含的內容是經常變化的 HTML（如時間戳記），那么每當裝入 Web 頁面時，都需要顯示這些文件或程序的最新版本。遺憾的是，JSP include 偽指令并不具備這一功能。在測試和開發周期（請參閱側欄“JSP 測試和開發”）中，在瀏覽器中禁用高速緩存通常能夠解決這一問題。但是，對于實際使用的應用程序而言，性能是任何設計決策過程中的一項重要因素，禁用高速緩存并不是一種可行的長遠之計。更好的解決方案是使用 jsp:include 標記。

jsp:include 標記
jsp:include 只不過是一個不同于 include 的偽指令而已。jsp:include 的優點在于：它總是會檢查所含文件中的變化。過一會兒我們將研究這一新標記的工作方式。但首先看一下兩種 include 各自的代碼，以便能夠看到二者之間的異同。

清單 2 顯示了一個簡單頁面，它使用了原始的 JSP include 偽指令。

清單 2. JSP include 偽指令

清單 3 是同一個頁面，只不過這里轉成使用 jsp:include 標記。

清單 3. 轉成使用 jsp:include

您應該注意這兩種代碼類型之間的兩大區別。首先，jsp:include 元素不使用屬于 include 偽指令的 %@ 語法。實際上，jsp 前綴讓 JSP 編譯器知道：它應該尋找標準 JSP 標記集中的元素。其次，指定要包含的文件的屬性從 file 變成了 page。如果愿意，可以自己測試一下新標記的結果。只需更改上一篇文章（請參閱參考資料）中 included.html 文件的內容，然后重新裝入瀏覽器頁面，就會立即看到新內容。

flush 屬性
您可能已注意到 jsp:include 代碼示例中的 flush 屬性。顧名思義，flush 指示在讀入包含內容之前是否清空任何現有的緩沖區。JSP 1.1 中需要 flush 屬性，因此，如果代碼中不用它，會得到一個錯誤。但是，在 JSP 1.2 中，flush 屬性缺省為 false。由于清空大多數時候不是一個重要的問題，因此，我的建議是：對于 JSP 1.1，將 flush 設置為 true；而對于 JSP 1.2 及更高版本，將其設置為關閉。

jsp:include 是如何工作的
如果您有點愛刨根問底，那么可能十分想知道 jsp:include 標記的行為為什么與 include 偽指令不同。道理其實十分簡單：jsp:include 包含的是所包含 URI 的響應，而不是 URI 本身。這意味著：對所指出的 URI 進行解釋，因而包含的是生成的響應。如果頁面是 HTML，那么將得到一點也沒有變化的 HTML。但是，如果是 Perl 腳本、Java servlet 或者 CGI 程序，那么得到的將是從該程序解釋而得的結果。雖然頁面通常就是 HTML，但實際程序恰好是達到目的的手段。而且，由于每次請求頁面的時候都會進行解釋，因此從來不會象使用 include 偽指令時那樣高速緩存結果。雖然這只是很小的變動，但它卻導致了您所見到的行為中的全部差異。

一種混合搭配的解決方案
include 偽指令在某些網站上有其用武之地。例如，如果站點包含一些（如果有變化，也很少）幾乎沒有變化的頁眉、頁腳和導航文件，那么基本的 include 偽指令是這些組件的最佳選項。由于 include 偽指令采用了高速緩存，因此只需放入包含文件一次，其內容就會被高速緩存，其結果會是極大地提高了站點的性能。

然而，對于現在許多 Web 應用程序或站點而言，地毯式的高速緩存并不能解決問題。雖然頁眉和頁腳可能是靜態的，但是不可能整個站點都是靜態的。例如，從數據庫提取導航鏈接是很常見的，并且許多基于 JSP 技術的站點還從其它站點或應用程序上的動態 JSP 頁面提取內容。如果正在處理動態內容，那么需要采用 jsp:include 來處理該內容。

當然，最好的解決方案是經常把這兩種方法混合搭配使用，將每種構造用到最恰當的地方。清單 4 是混合搭配包含解決方案的一個示例。

清單 4. 混合搭配解決方案

上面的代碼顯示了前一篇文章中的示例索引頁面。導航鏈接和頁腳是靜態內容，一年最多更改一次。對于這些文件，我使用了 include 偽指令。內容窗格包含 Weblog 和“bookshelf”組件，它們是動態生成的。這兩個組件需要一直更新，因此對它們，我使用了 jsp:include 標記。header.jsp 文件有點奇怪。這個組件是從另一個本質上是靜態的 JSP 頁面提取的。但是，正如您將注意到的那樣，它從包含頁提取頁“標語”，然后將它顯示出來。要處理這一共享信息，我們必須向頁眉文件傳入參數。而要處理那些參數，就必須使用 jsp:include 元素。