java web 应用程序装饰/包含问题
背景：我们有一个系统是在 2002-2003 年期间用基于 Java 的旧 CMS 编写的。 我们希望使用 tomcat、stripes 和 sitemesh 继续推进我们的新功能。 我们有导航、布局、“pods”、js、css 等，我们从旧的 CMS 中取出这些内容并将其放入一些新应用程序中，以便我们拥有一致的外观和感觉。
我们现在需要某种解决方案来消除所有正在发生的代码重复。 我们的应用程序目前在同一个虚拟机上运行，但这可能会改变。 我们需要一种方法让所有的 tomcat 实例访问一些通用元素（这些元素可能/可能不需要做一些服务器端的事情）。
到目前为止，我们想到的最好的方法是制作一个相当标准的 sitemesh 装饰器，它使用 c:import 来获取所需的内容，并将其正确插入。此解决方案有一些网络开销，可能会使其陷入困境并导致失败观点。 我们已经查看了 <%@ include file="/something.jsp" %> 也是如此，但这似乎只是相对于上下文的。 我们可以使用 c:import 并将其指向 localhost，这似乎是迄今为止最好的解决方案。
是否有其他模板/装饰框架（Tiles？）可以使这变得更简单？ 我们缺少什么？
Background: we have a system that was written in an older CMS based on Java back during the 2002-2003 days. We want to keep moving forward with our new stuff, using tomcat, stripes, and sitemesh. We have navigation, layouts, "pods", js, css, etc, that we've taken out of the old CMS and into a few of our new apps so we have consistent look and feel.
We now need some sort of solution to get rid of all the code duplication going on. Our apps are running on the same VM at the moment, but that might change. We need a way for all of our tomcat instances to access some common elements (and those elements may/may not need to do some server side stuff).
The best we've come up with so far is making a fairly standard sitemesh decorator, that uses c:import to get what it needs, and plugs it right in. This solution has some network overhead which could bog it down and introduce a fail point. We've looked at <%@ include file="/something.jsp" %> as well but that seems to be only context relative. We could use c:import and point it at localhost, which seems to be the best solution so far.
Are there other templating/decorating frameworks out there (Tiles?) that could make this simpler? What are we missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不太确定你想在这里做什么。 我的解释是：您有许多资源想要在多个应用程序中重用。 您不希望在所有应用程序中重复这些文件，因为这将很难保持应用程序之间的一致性。
如果这是您的问题，我建议您将公共资源保存在 jar 文件中。 这为您带来了几个优势：
示例 2：将常用页面布局保存在 page-layouts-1.x.jar 中。 您继续对页面布局进行小版本发布，这不会影响使用它的应用程序 - 它们是直接替代品。 有一天，您决定完全重新设计您的应用程序并发布 page-layouts-2.0.jar。 这需要对使用它的应用程序进行一些重写。 现在，如果应用程序捆绑页面布局，而不是将它们保存在服务器上的共享类加载器中，那么迁移到 2.0 布局就不是一件全有或全无的事情。 您可以一次迁移一个应用程序以使用 2.0 布局，而其他应用程序仍使用 1.x 布局。
我们使用 JSF 和 Facelets 非常成功地做到了这一点。
您可能想查看 Weblet。 我不知道 SiteMesh 或 Tiles 是否获得了从类路径提供资源的直接支持，但我认为您可以调整它们来做到这一点。
希望能帮助到你
I'm not quite sure what you're trying to do here. My interpretation is this: You have a number of resources that you want to reuse in a number of apps. You don't want to have these files duplicated in all apps, as it would make it hard to maintain consistency across the apps.
If this is your question, I would suggest that you keep your common resources in jar files. This gives you several advantages:
An example of nr 2: You keep your common page layouts in page-layouts-1.x.jar. You keep on making minor releases of the page layouts that doesn't affect the apps using it - they are drop-in replacements. One day, you decide to redesign your apps completely and release page-layouts-2.0.jar. This require some rewrites to the apps using it. Now, if the apps bundles the page layouts, as opposed to keeping them in a shared class loader on the server, migrating to the 2.0 layout isn't an all or nothing affair. You can migrate one app at a time to use the 2.0 layout, while the others still use the 1.x layout.
We are doing this very successfully, using JSF and Facelets.
You might want to have a look at Weblets. I have no idea whether SiteMesh or Tiles got any direct support for serving up resources from the class path, but I assume you can tweak them to do this.
Hope it helps
我们使用 Sitemesh 已有多年，我对此有着复杂的感受。
我更喜欢编写标准 JSP 标记文件（.tag 或 .tagx）而不是使用 applydecorator。 我认为 applydecorator 标签随着标签文件的出现而有效地被淘汰，但太多的 Sitemesh 用户没有注意到。
我们几乎所有的 Sitemesh 用法都是这样的。 我们有一些常见的页面模板，我们的 JSP 页面将它们显式地称为布局。 “使用标准布局，这是导航菜单，这是页面正文。” 标记文件是此功能的精确副本，但它们是标准化的，受任何 J2EE Web 工具支持，并且内置于容器而不是其他依赖项中。
为了真正装饰一个页面，JSP 页面本身根本没有引用 Sitemesh，我认为这在高层上是有意义的，但我仍然不喜欢再次解析整个页面。
第二个问题实际上并不是 Sitemesh 的错；而是由 Sitemesh 造成的。 考虑到它必须使用 Servlet API，我不知道它还能做什么。 但这确实让我想知道基于 DOM 的替代基于流的 Servlet API 是否有价值。 换句话说，不是让 servlet 将其输出写入流，而是将节点添加到树中会怎样？ 这将强制执行格式良好的输出，并使像 Sitemesh 那样进行结构转换或将输出编码为不同格式（例如 XHTML、HTML 或 JSON）的成本变得更便宜。
We have used Sitemesh for years and I have mixed feelings about it.
I far prefer writing standard JSP tag files (.tag or .tagx) to use of applydecorator. I think the applydecorator tag effectively obsoleted with the advent of tag files, but too many Sitemesh users didn't notice.
Almost all of our Sitemesh usage was of this kind. We'd have a few common page templates, that our JSP pages would refer to explicitly as a layout. "Use the standard layout, here's the navigation menu and here's the body of the page." Tag files are an exact duplicate of this functionality, but they are standardized, supported by any J2EE web tool, and built-in to the container rather than another dependency.
For truly decorating a page, where the JSP page itself makes no reference at all to Sitemesh, I think it makes sense at a high-level, but I still don't like that the whole page is parsed again.
This second problem isn't Sitemesh's fault really; given the Servlet API it has to work with, I don't know what else it could do. But it does make me wonder if a DOM-based alternative to the stream-based Servlet API could be valuable. In other words, rather than having servlets write their output to a stream, what if they added nodes to a tree? This would enforce well-formed output, and make it cheaper to do structural transformations like Sitemesh does, or encode output to different formats like XHTML, HTML, or JSON on the fly.