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

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

我即将选择组织我的观点(使用spring-mvc，但那不重要)

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

瓷砖

SiteMesh的

Freemarker的

速度

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

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

我的问题是 - 这些框架给出了什么，可以通过和JSTL正确完成。 要点(一些来自文章)：

包括页面的部分内容，如页眉和页脚 - 两者之间没有区别：

和

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

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

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

效率 - 比其他任何方法都更有效，因为它被编译一次。 所有其他选项都被解析/执行多次。

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

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

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

7个解决方案

17 votes

Velocity的一些论点(我还没有使用Freemarker)：

有可能在Web上下文之外重用模板，例如发送电子邮件

Velocity的模板语言语法比JSP EL或标签库简单得多

严格地将视图逻辑与任何其他类型的逻辑分离 - 没有可能选择下拉到使用scriptlet标记并在模板中执行令人讨厌的事情。

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

是的，引用确实是VTL的核心：

Hello $username!

要么

#if($listFromModel.size() > 1)

You have many entries!

#end

效率 - 比其他任何方法都更有效，因为它被编译一次。 所有其他选项都被解析/执行多次。

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

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

不同的是，使用JSP方法，您不会在使用相同页眉/页脚的每个JSP文件中重新组织此布局吗？ Tiles和SiteMesh允许您指定基本布局页面(JSP，Velocity模板等 - 两者都是JSP框架)，您可以在其中指定所需内容，然后委托给内容＆＃34; 片段/模板的主要内容。 这意味着只有一个文件可以移动标题。

matt b answered 2019-08-20T10:05:22Z

11 votes

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

但应用程序有一种逐步增长的方式，并且很难证明停止新开发和改造瓷砖(或其他一些解决方案)的合理性，因此我们可以更轻松地解决未来的问题＆＃34;如果你需要 在开始时不要使用复杂的解决方案。

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

mooreds answered 2019-08-20T10:06:04Z

4 votes

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

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

SiteMesh 2/3

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

JSP 2+

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

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

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

Bart answered 2019-08-20T10:07:20Z

2 votes

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

Thorbjørn Ravn Andersen answered 2019-08-20T10:07:46Z

2 votes

一个好的视图技术消除了大多数和最烦人的if / switch /条件语句，简单包括没有。 使用＆＃39;复杂＆＃39; 查看技术会导致简单的＆＃39; 应用。

Ibrahim answered 2019-08-20T10:08:11Z

1 votes

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

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

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

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

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

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

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

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

Singagirl answered 2019-08-20T10:09:27Z

0 votes

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

部分是关于规模。 您可能会认为包含的内容与使用sitemesh一样强大，并且这确实是正确的，至少对于少量页面(我说可能大约100个)，但是如果 你有几千个它开始变得无法管理。 (所以对于eBay而言，对于Salesforce来说，它可能不是必需的)

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

最后，你的观点5只是部分正确。 每次访问它时都会编译它，如果还没有这样的话。 这意味着每当你改变一些东西时，你需要记住删除你的servlet容器＆＃34; work＆＃34; 目录，以便重新编译JSP。 这对于模板引擎来说是不必要的。

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

Mikkel Løkke answered 2019-08-20T10:10:24Z