为什么我要使用模板引擎？jsp include and jstl vs tiles， freemarker， velocity， sitemesh

jsp java freemarker velocity tiles

2022-08-31 10:53:40

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

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

瓷砖
网站网格
免费标记
速度
<jsp:include>
<%@ include file="..">

磁贴和站点网格可以分组;Freemarker和Velocity也是如此。每个小组中使用哪一个不是这个讨论的问题，有足够的问题和讨论。

这是一个有趣的阅读，但不能完全说服我使用瓷砖。

我的问题是 - 这些框架给出了什么，不能正确地完成和JSTL。要点（部分摘自文章）：<@ include file="..">

包括页面的某些部分，如页眉和页脚 - 两者之间没有区别：
```
<%@ include file="header.jsp" %>
```
和
```
<tiles:insert page="header.jsp" />
```
在标题中定义参数 - 如标题、元标记等。这是非常重要的，特别是从SEO的角度来看。使用模板选项，您只需定义每个页面应定义的占位符即可。但是，您可以在jsp中使用JSTL，使用（在包含页面中）和（在包含页面中）<c:set><c:out>
布局重组 - 如果要将痕迹导航移动到菜单上方，或将登录框移动到另一个侧面板上方。如果页面包含（使用 jsp）组织得不好，在这种情况下，您可能需要更改每个页面。但是，如果您的布局不是过于复杂，并且您将常见内容放在页眉/页脚中，则无需担心。
常见组件和特定内容之间的耦合 - 我没有发现这个问题。如果要重用某些片段，请将其移动到不包含任何页眉/页脚的页面，并在需要时包含它。
效率 - 比其他任何东西都更有效，因为它被编译一次。所有其他选项被解析/执行多次。<%@ include file="file.jsp" %>
复杂性 - 所有非 jsp 解决方案都需要额外的 xml 文件、附加包含、预处理器配置等。这既是一条学习曲线，也是引入更多潜在的失败点。此外，它使支持和更改更加繁琐 - 您必须检查许多文件/配置才能了解正在发生的事情。
占位符 - 速度/自由标记是否比 JSTL 更能提供任何东西？在 JSTL 中，您放置占位符，并使用模型（由控制器放置在请求或会话作用域中）来填充这些占位符。

所以，说服我应该使用上述任何框架，而不是/除了普通的JSP。

答案 1

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

在 Web 上下文之外重用模板的可能性，例如在发送电子邮件时
Velocity的模板语言语法比JSP EL或标签库简单得多。
视图逻辑与任何其他类型的逻辑严格分离 - 没有可能的选项可以下降到使用 scriptlet 标签并在模板中执行令人讨厌的事情。

占位符 - 速度/自由制造者是否比JSTL提供更多的东西？在 JSTL 中，您放置占位符，并使用模型（由控制器放置在请求或会话作用域中）来填充这些占位符。

是的，引用确实是 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框架），您可以在其中指定所需的任何内容，然后只需委托给主要内容的“内容”片段/模板。这意味着只有一个文件可以移动标头。

答案 2

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

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

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