自定义 Java Tapestry @IncludeStylesheet 注解
使用 Tapestry 5，我正在寻找一种（如果可能的话）优雅的方式来自定义 @IncludeStylesheet 注释，以便自动将版本号添加到样式表文件名中。
例如，
@IncludeStylesheet("context:/css/decoration.css")
将自动生成带有 v 版本号的 CSS 包含
<link href="/css/decoration.css?v=12345" rel="stylesheet" type="text/css">
添加新注释，例如 @IncludeStylesheetVersion 是我最初的想法。
看看 Tapestry 代码，我似乎领先于一些代码复制/重构，以及 RenderSupport 和 DocumentLinker （等等）的新实现。
是否有更简单的方法可以继续？
Using Tapestry 5, I'm looking at a (if possible) elegant way to customize the @IncludeStylesheet annotation in order to automatically add a version number to the style sheet file name.
For instance
@IncludeStylesheet("context:/css/decoration.css")
would generate automatically the CSS inclusion with a version number
<link href="/css/decoration.css?v=12345" rel="stylesheet" type="text/css">
Adding a new annotation, like @IncludeStylesheetVersion was my initial idea.
Looking at the Tapestry code, it looks like I'm ahead of some code copy / refactoring, with new implementations of RenderSupport and DocumentLinker (among others).
Would there be a simpler way to proceed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可能根本不必这样做：资产版本控制内置于 Tapestry 中。根据文档，默认行为：
如果您只需要确保客户端在更新后看到更改后的样式表并且您不会一直重新启动应用程序，那么默认行为（随机十六进制数）应该就可以了。
根据评论进行编辑：5.1 中也提供< /a>:
只需检查 Tapestry 为您的 CSS 文件生成的 URL，它们应该如下所示：
http://myserver.com/assets/ctx/942f15f778dca26c/css/styles.cssYou may not have to do that at all: Asset versioning is built into Tapestry. The default behaviour, according to the docs:
If you just need to make sure clients will see changed stylesheets after an update and you don't restart your app all the time, the default behavior (random hex number) should do just fine.
Edit based on comment: This is also available in 5.1:
Just check the URLs Tapestry generates for your CSS files, they should look like this:
http://myserver.com/assets/ctx/942f15f778dca26c/css/styles.css总体而言，您在升级到 5.3 上投入的精力可能比尝试创建注释来模仿当前版本的内置功能更划算。我认为您会发现升级过程非常轻松——特别是如果您有良好的集成测试。
Overall, the effort you'd put into upgrading to 5.3 will probably be better spent than trying to create an annotation to mimic the built in functionality of current versions. I think you'll find the upgrade process pretty painless--particularly if you have good integration testing in place.