本周，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 清单中的资源

这些ResourceHttpRequestHandlers的新增功能的关键目标是简化优化和处理优化后的静态资源，以提高前端性能。

另一种资源管道？

许多库和框架通过完整的集成资源管道解决这些问题，这些管道通常提供关于要使用的编程语言、技术和项目结构的强大、有见地的解决方案。这些资源管道在创建可部署应用程序和/或应用程序运行时负责资源优化。

在 Spring Framework 4.1 中，我们选择了一条在构建时使用最合适的工具优化资源，并在运行时利用解析器和转换器的路径。对于 JavaScript 应用程序，我们希望利用 JavaScript 开发人员使用的相同工具链，例如grunt 和 gulp，在构建时优化资源。关于Dart 和 TypeScript 也是如此 - 本机工具始终提供最佳体验。

这些生态系统非常丰富（实际上比 Java 中提供的选项丰富得多）并且不断发展。我们相信，依赖这些生态系统和框架中的灵活解决方案是这里最好的方法。

因此，您的应用程序应该找到合适的平衡点并利用

• 使用客户端应用程序的本机工具在构建时进行转译、压缩、连接等任务
• 框架提供的解析器和转换器（还可以创建您自己的！)

展望即将到来的标准，例如HTTP/2 和 ECMAScript 6，这更有意义 - 定义更改将在未来几年发生在这个领域。

资源版本控制

静态 Web 资源版本控制是在将 Web 应用程序推送到生产环境时的一个核心问题，并且很大程度上是服务器端的问题。Spring Framework 4.1 旨在通过各种策略提供一流的支持，包括基于内容的哈希（如 Git 中的哈希，也称为指纹）以及适用于整个文件集的版本（例如，使用JavaScript 模块加载器时需要）。

所有这些的基础都是“缓存失效”的概念，其中资源使用积极的 HTTP 缓存指令（例如，未来 1 年）提供服务，并依赖于 URL 中与版本相关的更改来在必要时“失效”缓存。这可能是基于内容的哈希版本，该版本在文件内容更改时发生变化，或者通过其他方式确定的版本（例如，简单属性、git 提交 sha 等）。

源代码布局

另一个非常重要的问题是您的源代码位于何处以及您的应用程序是如何组织的 - 作为 Java 开发人员，我们习惯于在src/main/webapp中找到它们。但这真的是最佳位置吗？

如今，大多数 Web 应用程序都由在浏览器中运行的客户端应用程序和服务器应用程序组成，两者通过 HTTP 或 Websocket 通信。每个应用程序都可以有自己的依赖项、测试、构建工具等。那么，为什么我们不能将它们解耦并在我们的代码库中反映这种关注点分离呢？

将您的 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 资源处理展示应用程序中，我们演示了几个关键功能

• 在 HTML 响应、CSS 文件和 HTML5 appcache 清单中缓存失效静态资源
• 如前所述，新的项目布局
• 模板引擎集成，例如Groovy 标记模板 和 Handlebars
• 使用 LESS 作为 CSS 替代方案，在开发过程中使用客户端预处理器，在生产过程中使用构建处理器
• 完整的构建工具链，使用 Gradle 和 gulp；未来的示例可以演示使用 grunt、maven 等相同的功能

请注意，此新的项目布局有两个关键优势

1. 更好的开发者体验，因为资源在开发时直接从磁盘提供服务，未经优化。

2. 生产环境中的最佳性能，因为静态资源由构建进行优化并打包到 webJAR 中 - 因此它们最终在生产环境中从类路径提供服务。

我们期待您的反馈

该Spring 资源处理展示应用仍在开发中，我们正在准备增强功能以简化配置（参见SPR-11982）；当然，社区的反馈在这里将非常有用。

更多内容，别忘了参加2014 年德克萨斯州达拉斯的 SpringOne 2GX - Rossen 和我将在一个专门的会议中介绍此主题。