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

Question

我即将选择组织我的观点（使用spring-mvc，但这不应该太重要）

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

• 瓷砖
• SiteMesh的
• Freemarker的
• 速度
• <jsp:include>
• <%@ include file="..">

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

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

我的问题是 - 这些框架提供的内容无法通过 <@ include file="..">和JSTL 正确完成 。 要点（一些来自文章）：

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

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

   和

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

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

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

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

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

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

7. 占位符 - 速度/自由标记比JSTL更多吗？ 在JSTL中，您放置占位符，并使用模型（放置在请求或会话范围，由控制器）来填充这些占位符。

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

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

Answer 2

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

但应用程序有一种逐步增长的方式，并且很难证明“停止新开发和改造瓷砖（或其他一些解决方案），以便我们可以更容易地解决未来的问题” ，如果你不使用一开始的复杂解决方案。

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

Answer 3

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

我主要使用Spring MVC，我发现JSP 2+与SiteMesh完美匹配。

SiteMesh 2/3

提供应用于视图的装饰器，主要类似于其他模板引擎中的继承。 如今没有这种功能是不可想象的。

JSP 2+

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

使用JSTL标记，您的代码仍然看起来像HTML，因此它不那么尴尬。 Spring通过taglibs为JSP提供了很多支持，这非常强大。

taglibs也很容易扩展，因此定制您自己的环境是轻而易举的。

Answer 4

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

Answer 5

一个好的视图技术消除了大多数和最烦人的if / switch /条件语句，简单包括没有。 使用“复杂”视图技术可以实现“简单”的应用。

Answer 6

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

很难避免在JSP模板中使用Java代码，因此您的纯视图的破坏概念，因此您将难以在几个地方维护代码作为视图和控制器

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

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

最小的JSP引擎大约有500k的字节码和JSTL，因此它不适合嵌入式系统

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

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

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

Answer 7

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

部分是关于规模。 你可能会认为包含的东西就像让我们说sitemesh一样强大，这肯定是正确的，至少对于少量的页面（我说可能大约100个），但是如果你有几千个它开始变得无法管理。 （所以对于eBay来说，没有必要，对于Salesforce来说可能是这样）

而且，如前所述，freemarker和velocity不是servlet特有的。 您可以将它们用于任何事情（邮件模板，离线文档等）。 您不需要Servlet容器来使用freemarker或velocity。

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

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