這週，Juergen 宣布了 Spring Framework 4.1 的候選版本。現在是測試這些新功能，看看它們如何改善您的應用程式的好時機！

其中一項新功能是靜態網頁資源的彈性解析和轉換。Spring Framework 已經允許您使用 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 實現提供了什麼

Resolver 名稱	目標
PathResourceResolver	在已配置的位置（classpath、檔案系統...）下找到與請求路徑匹配的資源
CachingResourceResolver	從 Cache 實例解析資源，或委託給鏈中的下一個 Resolver
GzipResourceResolver	當 HTTP 客戶端支援 gzip 壓縮時，尋找具有 ".gz" 副檔名的資源變體
VersionResourceResolver	解析包含版本字串的請求路徑，即有關所請求資源的版本資訊。此解析器可用於通過更改資源的 URL 在更新時設置 HTTP 緩存策略。

現在，是 ResourceTransformers

Transformer 名稱	目標
CssLinkResourceTransformer	修改 CSS 檔案中的連結以匹配應暴露給客戶端的公開 URL 路徑
CachingResourceTransformer	在 Cache 中緩存轉換的結果，或委託給鏈中的下一個 Transformer
AppCacheManifestTransfomer	協助處理 HTML5 離線應用程式的 HTML5 AppCache 描述檔中的資源

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 緩存指令（例如，未來 1 年）提供資源，並依靠 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

解析器/轉換器和建置工具都可以在資源處理方面提供類似的功能。 那麼我們應該使用哪一個？

Spring 資源處理展示應用程式

在 Spring Resource Handling showcase application 中，我們展示了幾個主要功能

• 在 HTML 回應、CSS 檔案和 HTML5 appcache 描述檔中破壞快取靜態資源
• 如前所述的新的專案佈局
• 樣版引擎整合，例如 Groovy 標記範本 和 Handlebars
• 使用 LESS 作為 CSS 的替代方案，在開發期間使用客戶端預處理器，並使用建置處理器進行生產
• 完整的建置工具鏈，使用 Gradle 和 gulp； 未來的範例可以使用 grunt、maven 等演示相同的功能

請注意，這個新的專案佈局有兩個主要優點

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

2. 在生產中獲得最佳效能，因為靜態資源經過建置最佳化並打包在 webJAR 中 - 因此它們最終在生產中從 classpath 提供

我們正在等待您的回饋

Spring Resource Handling showcase application 仍在開發中，我們正在準備增強功能以簡化配置（請參閱 SPR-11982）； 當然，社群的回饋將在這裡非常有用。

如需更多資訊，請不要忘記 SpringOne 2GX 2014 in Dallas, TX - Rossen 和我將在專題演講中介紹這個主題。