为什么要使用模板引擎？ jsp 包括和 jstl vs tile、freemarker、velocity、sitemesh

Question

我即将选择组织视图的方式（使用 spring-mvc，但这并不重要）

据我所知，有 6 个选项（尽管它们不是相互排斥的）：

• 瓷砖
• 站点网格
• Freemarker
• 速度
• <jsp:include>
• <%@ include file="..">

Tiles和Sitemesh可以分组； Freemarker 和 Velocity 也可以。每个组中使用哪一个不是这个讨论的问题，有足够的问题和讨论。

This is an interesting read，但无法说服我使用磁贴。

我的问题是 - 这些框架提供了哪些无法通过 <@ include file=".."> 和 JSTL 正确完成的功能。要点（部分摘自文章）：

1. 包括部分页面，如页眉和页脚 - 没有区别：

   <%@ include file="header.jsp" %>
   

   和

   <tiles:insert page="header.jsp" />
   

2. 在标题中定义参数 - 如标题、元标记等。这非常重要，尤其是从 SEO 的角度来看。使用模板选项，您可以简单地定义每个页面应定义的占位符。但是，您可以在带有 JSTL 的 jsp 中使用 <c:set>（在包含页面中）和 <c:out>（在包含页面中）

3. 布局重组 - 如果您想将面包屑移动到菜单上方，或者将登录框移动到另一个侧面板上方。如果页面包含（使用 jsp）没有很好地组织，在这种情况下您可能需要更改每个页面。但是如果你的布局不是太复杂，把常用的东西放在页眉/页脚里，那就没什么好担心的了。

4. 通用组件和特定内容之间的耦合 - 我没有发现这个问题。如果您想重复使用某些片段，请将其移动到不包含任何页眉/页脚的页面，并在需要的地方包含它。

5. 效率 - <%@ include file="file.jsp" %> 比其他任何东西都更有效，因为它只编译一次。所有其他选项都被解析/执行了很多次。

6. 复杂性 - 所有非 jsp 解决方案都需要额外的 xml 文件、额外的包含、预处理器配置等。这既是一条学习曲线，又会引入更多潜在的故障点。此外，它使支持和更改变得更加乏味 - 您必须检查许多文件/配置才能了解正在发生的事情。

7. 占位符 - velocity/freemarker 提供的不仅仅是 JSTL 吗？在 JSTL 中放置占位符，并使用模型（由控制器放置在请求或会话范围内）来填充这些占位符。

所以，请说服我应该使用上述任何框架来代替/除了纯 JSP。

Answer 1

Velocity 的一些参数（我没有使用过 Freemarker）：

• 有可能在网络环境之外重复使用模板，例如在发送电子邮件时
• Velocity 的模板语言语法远比 JSP EL 或标记库简单
• 将视图逻辑与任何其他类型的逻辑严格分离 - 无法选择使用 scriptlet 标记和在模板中做讨厌的事情。

占位符——velocity/freemaker 提供的不仅仅是 JSTL 吗？在 JSTL 中放置占位符，并使用模型（由控制器放置在请求或会话范围内）来填充这些占位符。

是的，references 确实是 VTL 的核心：

<b>Hello $username!</b>

或

#if($listFromModel.size() > 1)
    You have many entries!
#end

效率 - <%@ include file="file.jsp" %> 比其他任何东西都更有效，因为它只编译一次。所有其他选项都被多次解析/执行。

不太确定我是否同意或理解这一点。 Velocity 有一个缓存模板的选项，这意味着它们被解析成的抽象语法树将被缓存而不是每次都从磁盘读取。无论哪种方式（我也没有确切的数字），Velocity 对我来说总是快速。

布局重组 - 如果您想将面包屑导航移动到菜单上方，或者将登录框移动到另一个侧面板上方。如果页面包含（使用 jsp）没有很好地组织，在这种情况下您可能需要更改每个页面。但如果你的布局不是太复杂，把常用的东西放在页眉/页脚，那就没什么好担心的了。

不同之处在于，使用 JSP 方法，您不会在每个使用相同页眉/页脚的 JSP 文件中重新组织此布局吗？ Tiles 和 SiteMesh 允许您指定一个基本布局页面（JSP、Velocity 模板等 - 两者都是 JSP 框架的核心），您可以在其中指定任何您想要的内容，然后只需委托给主要内容的“内容”片段/模板.这意味着只有一个文件可以将标题移入。

Answer 2

jsp:include 和 Tiles/Sitemesh/etc 之间的选择是开发人员一直面临的简单性和功能性之间的选择。当然，如果您只有几个文件或不希望您的布局经常更改，那么只需使用 jstl 和 jsp:include。

但是应用程序有一种渐进式增长的方式，并且很难证明“停止新的开发和改造磁贴（或其他一些解决方案）以便我们可以更轻松地解决未来的问题”，如果您一开始不使用复杂的解决方案，这是必需的。

如果您确定您的应用程序将始终保持简单，或者您可以设置一些应用程序复杂性基准，之后您将集成更复杂的解决方案之一，那么我建议您不要使用磁贴/等。否则，从一开始就使用它。

Answer 3

我不会说服您使用其他技术。据我所知，如果 JSP 适合他们，每个人都应该坚持使用它。

我主要使用 Spring MVC，我发现 JSP 2+ 与 SiteMesh 结合是完美的搭配。

SiteMesh 2/3

提供应用于视图的装饰器，主要类似于其他模板引擎中的继承工作。现在没有这样的功能是无法想象的。

JSP 2+

那些声称 JSP 将难以避免模板中的 Java 代码的人是假的。您只是不应该这样做，并且使用此版本没有必要这样做。版本 2 支持使用 EL 调用方法，这与以前的版本相比是一个很大的优势。

使用 JSTL 标签，您的代码仍然看起来像 HTML，因此不那么尴尬。 Spring通过taglibs打包了很多对JSP的支持，非常强大。

标签库也很容易扩展，因此自定义您自己的环境是一件轻而易举的事。

Answer 4

反对使用 JSP 的 facelets（不在您的列表中，但我会提到它）的最佳论点之一是编译与解释器集成，而不是委托给 JSP 编译器。这意味着我在 JSF 1.1 中遇到的最烦人的事情之一——在保存更改以便运行时引擎发现更改时必须更改周围 JSF 标记上的 id 属性——消失了，给出了保存——在编辑器中，在浏览器中重新加载循环，以及更好的错误消息。

Answer 5

一个好的视图技术可以消除大多数和最烦人的 if/switch/条件语句，而简单的 include 则不能。使用“复杂”视图技术会产生“简单”应用程序。

Answer 6

您没有提供有关特定应用程序的信息。例如，我不使用 JSP 有几个原因：

在 JSP 模板中使用 Java 代码是不可避免的，因此你打破了纯视图的概念，结果你将难以在多个地方维护代码作为视图和控制器

JSP 自动创建建立会话的 JSP 上下文。我可能想避免它，但是如果您的应用程序总是使用会话，那对您来说可能不是问题

JSP需要编译，如果目标系统没有Java编译器，任何小的调整都需要使用其他系统然后重新部署

最小的JSP引擎大约是500k字节码加上JSTL，所以可能不适合嵌入式系统

模板引擎可以生成同一模型的不同内容类型，比如 JSON 负载、网页、电子邮件正文、CSV 等。

非 Java 程序员可能难以使用 JSP 模板，而非技术人员在修改常规模板时从未遇到过困难。

我很久以前就问过同样的问题，最后写了我的框架（肯定是基于模板引擎的），它没有我在其他解决方案中看到的所有缺点。不用说它大约是 100k 的字节码。

Answer 7

我意识到这是一个聪明的答案，但事实是，如果您没有看到在当前项目中使用模板而不是代码有任何优势，这可能是因为在您当前的项目中，没有一个也没有。

其中一部分与规模有关。您可能会认为包含与我们说的站点网格一样强大，这当然是正确的，至少对于少数页面（我会说可能大约 100 个），但是如果您有数千个页面，它开始变得难以管理。 （所以对于 eBay 来说没有必要，对于 Salesforce 来说可能是）

此外，正如之前提到的，freemarker 和velocity 不是特定于servlet 的。您可以将它们用于任何事情（邮件模板、离线文档等）。您不需要 Servlet 容器即可使用 freemarker 或 velocity。

最后，您的第 5 点只是部分正确。如果它还没有被访问，它会在每次被访问时被编译。这意味着每当您更改某些内容时，您需要记住删除您的 servlet 容器的“工作”目录，以便它重新编译 JSP。这对于模板引擎来说是不必要的。

TL;DR 编写模板引擎是为了解决 JSP + JSTL 的一些（感知的或实际的）缺点。是否应该使用它们完全取决于您的需求和项目的规模。