为什么要使用模板引擎？jsp include和jstl vs tile，freemarker，speed，sitemesh

95

我将选择一种方法来组织我的视图（使用spring-mvc，但这无关紧要）

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

  • 瓷砖
  • Sitemesh
  • 自由标记
  • 速度
  • <jsp:include>
  • <%@ include file="..">

磁贴和Sitemesh可以分组；Freemarker和Velocity也可以。每个小组中使用哪个小组都不是本次讨论的问题，对此有足够的问题和讨论。

这是一本有趣的读物，但不能说服我使用磁贴。

我的问题是- 这些框架提供了哪些使用 <@ 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. 占位符 -速度/ freemarker除了提供JSTL之外还能提供更多功能吗？在JSTL中，您放置了占位符，并使用模型（由控制器放置在请求或会话范围中）填充了这些占位符。

因此，说服我，除了普通的JSP之外，我还应该使用上述任何框架。

java  jsp  velocity  tiles  freemarker 
— 博佐
source
我不知道究竟如何我对它们进行比较，通过我已经使用了条纹布局模板了一会儿，我发现它的很多更好的比普通的JSP。我确实使用了一些jsp：include调用，但是这些通常是相当特殊的情况。布局模板机制是一个非常方便且功能强大的工具。
— 尖尖的
2
是的，我听说所有这些功能都很“方便且强大”，但我还没有看到。我所看到的是不必要的复杂性和大量的配置文件。（我不是在专门讨论条纹，而是总的来说）
— Bozho 2010年
1
— 亚光b
我相信jsp：include是非常有效的-它被编译为从包含servlet到包含的方法调用。与@include相比，它生成的代码更少，由于缓存效应，它甚至可以提高性能。
— 汤姆·安德森
该StringTemplate的开发，使我见过的最好的说法，这是非常相似的最小功率的规则
— 保罗Sweatte

Answers:

17

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

  • 可能在网络环境之外重用模板，例如在发送电子邮件中
  • Velocity的模板语言语法还很远高于JSP EL或标签库简单
  • 严格将视图逻辑与其他任何形式的逻辑分开-无法使用下拉菜单使用scriptlet标签并在模板中执行令人讨厌的事情。

占位符-速度/ freemaker除了提供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框架的核心），您可以在其中指定所需的内容，然后仅委托给主要内容的“内容”片段/模板。这意味着将只有一个文件可移动标题。

— 马特b
source
3
使用JSTL可以轻松完成您给出的速度示例。关于效率点，我的意思是将jsps编译为servlet，并且没有任何内容被解析。但是，缓存模板也是一个不错的解决方案。至于重组-不，我通常以一种方式来构成包含，而我只需要修改包含，而不必修改“包含”。也许在更复杂的情况下这是不可能的。
— 博佐
2
除了在Web上下文之外重用模板之外，Velocity还使您可以轻松地将渲染的网页显示给客户端。当您要使网站以HTML文件形式生成时，此功能很有用。使用JSP-没有简单的解决方案。这是我们从JSP切换到Velocity的主要原因。关于速度-我做了一些基准测试，Velocity渲染页面的速度比JSP快2倍。因此速度不是问题。现在，在Velocity工作了几年之后，我再也不会回到JSP了。它是如此简单，轻便和清洁。
— 塞格2010年
@ serg555您是否在任何地方发布了这些基准测试？我希望看到更多有关此的数据。我很想知道您也是如何执行基准测试的。我认为这对于其他思考相同的“ Velocity vs JSP vs其他引擎”问题的人来说是个好信息。
— 马特b
我没有结果发布。只是我从我们的网站转换了几页，并测量了前后的渲染时间。没什么太科学的:)
— serg
@ serg555什么是jsp的平台/ servlet容器/版本？
— 博佐
12

之间的选择jsp:include和瓷砖/ SiteMesh的/等之间的选择的简单性和功率，开发人员面临的所有时间。当然，如果您只有几个文件，或者不希望布局经常更改，则只需使用jstl和即可jsp:include。

但是应用程序有一种逐渐增长的方式，并且很难证明“停止新开发并翻新tile（或其他解决方案），以便我们可以更轻松地解决未来的问题”，如果您不使用一开始就提供了复杂的解决方案。

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

— 系泊
source
5

我不会说服您使用其他技术。就我所知，如果对他们有用，那么每个人都应该坚持使用JSP。

我主要使用Spring MVC，并且发现将JSP 2+与SiteMesh结合使用完美。

SiteMesh 2/3

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

JSP 2+

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

使用JSTL标签，您的代码仍将看起来像HTML，因此不太麻烦。Spring通过taglibs打包了对JSP的大量支持，这非常强大。

标签库也很容易扩展，因此轻松定制您自己的环境。

— 巴特
source
我认为SiteMesh没有任何好处。Jsp标记提供与SiteMesh相同的修饰功能，但具有更大的灵活性，更不易碎的设置，并且由于不涉及后期处理解析，因此我也推测其效率更高。
— Magnus
2

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

— ThorbjørnRavn安徒生
source
是的，因为JSF facelets是与解释器紧密集成的解决方案，所以它是解决方案。但事实并非如此：)
— 博若
我只是提到了这些功能，以防它们对我来说是决定性的功能。
— 托尔比约恩Ravn的安徒生
2

好的视图技术消除了大多数/大多数烦人的if / switch /条件语句，简单的include则没有。使用“复杂”视图技术将导致“简单”应用程序。

— 易卜拉欣
source
1

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

很难避免在JSP模板中使用Java代码，因此，您打破了纯View的概念，结果，您将难以在多个位置维护视图和控制器中的代码

JSP自动创建建立会话的JSP上下文。我可能想避免这种情况，但是，如果您的应用程序始终使用会话，那么这对您来说就不是问题

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

最小的JSP引擎大约需要500k的字节码加上JSTL，因此它可能不适合嵌入式系统

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

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

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

— 新加坡女孩
source
0

我意识到这是一个明智的选择，但事实是，如果您没有看到在当前项目中使用对代码进行模板化的任何优势，那可能是因为在当前项目中没有。

其中一部分与规模有关。您可能会认为include的功能与sitemesh一样强大，并且至少在少数页面（我想说的大概是100个页面）中确实如此，但是如果您有数千个页面，它就变得难以管理。（因此，对于eBay来说不是必需的，对于Salesforce则可能是必需的）

同样，如前所述，freemarker和speed不是特定于servlet的。您可以将它们用于任何内容（邮件模板，脱机文档等）。您不需要Servlet容器即可使用freemarker或Velocity。

最后，您的观点5仅部分正确。如果尚未访问，则每次访问时都会对其进行编译。这意味着每当您更改某些内容时，都需要记住删除servlet容器的“ work”目录，以便它重新编译JSP。对于模板引擎，这是不必要的。

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

— 米克尔·洛克（MikkelLøkke）
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.