本週，Juergen 宣佈了 Spring Framework 4.1 釋出候選版本。現在是時候測試這些新功能，看看它們如何讓您的應用程式變得更好！

其中一個新特性是靜態 Web 資源的靈活解析和轉換。Spring 框架已經允許您使用 ResourceHttpRequestHandlers 提供靜態資源。此功能為您提供了更多能力和新的可能性。

ResourceResolvers 和 ResourceTransformers

ResourceResolvers 和 ResourceTransformers 是此新功能的核心。

ResourceResolvers 可以根據 URL 路徑解析資源。它們還可以根據內部資源路徑解析供客戶端使用的對外公開 URL 路徑。ResourceTransformers 可以修改已解析資源的內容。

這是一個圖示，說明使用 ResourceHttpRequestHandlers 提供靜態資源時會發生什麼。

  Request for Resource
      |
      | HTTP request
      v
  Resolvers chain: FirstResolver, SecondResolver, ThirdResolver
  (each resolver can return the resource or delegate to the next one)
      |
      | Resolved Resource
      v
  Transformers chain: FirstTransformer, SecondTransformer
  (each transformer can transform the resource or just pass it along without modification)
      |
      | Transformed Resource
      v
  HTTP Response with Resource content

這是另一個圖示，顯示 ResourceResolvers 鏈如何更新資源連結供 HTTP 客戶端使用。

  Resource link in a template source file
      |
      | Resource path (like "/css/main.css")
      v 
  Resolvers chain: FirstResolver, SecondResolver, ThirdResolver
  (each resolver can modify the resource path or delegate to the next one)
      |
      | Updated resource path (like "/css/main-0e37f12.css")
      v 
  Resource link in a rendered template 

現在，讓我們來看看 ResourceResolvers 實現提供了什麼。

解析器名稱	目標
PathResourceResolver	在配置的位置（類路徑、檔案系統等）下查詢與請求路徑匹配的資源
CachingResourceResolver	從 Cache 例項解析資源或委託給鏈中的下一個解析器
GzipResourceResolver	當 HTTP 客戶端支援 gzip 壓縮時，查詢帶有“.gz”副檔名的資源變體
VersionResourceResolver	解析包含版本字串的請求路徑，即有關所請求資源的版本資訊。此解析器可用於透過在資源更新時更改其 URL 來設定 HTTP 快取策略。

現在，來看看 ResourceTransformers

轉換器名稱	目標
CssLinkResourceTransformer	修改 CSS 檔案中的連結，使其與應向客戶端公開的公共 URL 路徑匹配
CachingResourceTransformer	在 Cache 中快取轉換結果或委託給鏈中的下一個轉換器
AppCacheManifestTransfomer	幫助處理 HTML5 離線應用程式的 HTML5 AppCache manifest 中的資源

這些新增到 ResourceHttpRequestHandlers 中的新功能的主要目標是便於最佳化靜態資源並使用已最佳化的靜態資源來提升前端效能。

又是另一個資產管道？

許多庫和框架透過完整整合的資產管道來解決這些問題，這些管道通常對要使用的程式語言、技術和專案結構提供強有力且有主見的解決方案。這些資產管道在建立可部署應用程式時和/或應用程式執行時負責資源的最佳化。

在 Spring Framework 4.1 中，我們選擇了一條道路，即在構建時使用現有最適合您的應用程式的工具最佳化資源，並在執行時利用 Resolvers 和 Transformers。對於 JavaScript 應用程式，我們希望利用 JavaScript 開發人員使用的相同工具鏈，如 grunt 和 gulp，在構建時最佳化資源。Dart 和 TypeScript 也是如此——原生工具總是提供最佳體驗。

這些生態系統非常豐富（實際上比 Java 中可用的選項豐富得多），並且不斷發展。我們相信依賴這些生態系統以及框架中的靈活解決方案是這裡最好的方法。

因此，您的應用程式應該找到正確的平衡並利用

• 在構建時使用客戶端應用程式的原生工具進行轉譯、精簡、合併等任務
• 框架提供的解析器和轉換器（您也可以建立自己的！）

著眼於即將到來的標準，例如 HTTP/2 和 ECMAScript 6，這變得更有意義了——未來幾年內，這個領域將發生決定性的變化。

資源版本控制

靜態 Web 資源的版本控制是將 Web 應用程式推送到生產環境時的核心問題，並且在很大程度上是一個伺服器端問題。Spring Framework 4.1 旨在透過各種策略提供一流的支援，包括基於內容的雜湊（如 Git 中，也稱為指紋識別）以及適用於整套檔案的版本（例如，與JavaScript 模組載入器一起工作時所需的）。

所有這些背後的思想是“快取失效”，即資源以激進的 HTTP 快取指令（例如，快取一年）提供，並在必要時依賴 URL 中與版本相關的更改來“打破”快取。這可以是內容雜湊版本，它在檔案內容更改時發生變化，也可以是透過其他方式確定的版本（例如，簡單屬性、git commit sha 等）。

原始碼佈局

另一個非常重要的問題是您的原始碼位於何處以及您的應用程式如何組織——作為 Java 開發人員，我們習慣於在 src/main/webapp 中找到它們。但這真的是最好的位置嗎？

如今，大多數 Web 應用程式由在瀏覽器中執行的客戶端應用程式和伺服器應用程式組成，兩者透過 HTTP 或 websockets 進行通訊。每個應用程式都可以有自己的依賴項、測試、構建工具等。那麼，為什麼我們不能將它們解耦並在我們的程式碼庫中體現這種關注點分離呢？

將您的 Web 應用程式分解為模組——一個客戶端模組和一個伺服器模組——可以顯著改善您的開發體驗，並賦予您的應用程式所需的自由度。

我們在 Project Sagan 中使用了相同的佈局，我在之前的一個截圖影片《Project Sagan: 客戶端架構》中詳細討論了這背後的原理。

這裡是一個專案佈局示例

spring-app/
|- build.gradle
|- client/
|  |- src/
|  |  |- css/
|  |  |- js/
|  |     |- main.js
|  |- test/
|  |- build.gradle
|  |- gulpfile.js
|- server/
|  |- src/main/java/
|  |– build.gradle

Resolvers/Transformers 和構建工具都可以提供圍繞資源處理的類似功能。那麼我們應該使用哪一個呢？

Spring Resource Handling 演示應用程式

在Spring Resource Handling 演示應用程式中，我們展示了一些關鍵特性

• 在 HTML 響應、CSS 檔案和 HTML5 appcache manifests 中使靜態資源快取失效
• 如前所述的新的專案佈局
• 模板引擎整合，例如Groovy markup templates 和 Handlebars
• 使用 LESS 作為 CSS 替代品，在開發時使用客戶端預處理器，生產時使用構建處理器
• 一套完整的構建工具鏈，使用 Gradle 和 gulp；未來的示例可以使用 grunt、maven 等展示相同的功能

注意，這種新的專案佈局有兩個關鍵優勢

1. 更好的開發者體驗，因為在開發時資源未最佳化，直接從磁碟提供

2. 生產中的最佳效能，因為靜態資源由構建最佳化並打包在 webJAR 中——因此它們最終在生產中從類路徑提供

我們期待您的反饋

Spring Resource Handling 演示應用程式仍在進行中，我們正在準備增強功能以簡化配置（請參閱 SPR-11982）；當然，社群的反饋將非常有幫助。

欲瞭解更多，不要錯過在得克薩斯州達拉斯舉行的SpringOne 2GX 2014——Rossen 和我將在一個專題會議中介紹這個主題。