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

Why would I use a templating engine? jsp include and jstl vs tiles, freemarker, velocity, sitemesh

提问by Bozho

I'm about to choose to way to organize my view (with spring-mvc, but that shouldn't matter much)

我即将选择组织我的视图的方式（使用 spring-mvc，但这应该无关紧要）

There are 6 options as far as I see (though they are not mutually exclusive):

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

• Tiles
• Sitemesh
• Freemarker
• Velocity
• <jsp:include>
• <%@ include file="..">

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

Tilesand Sitemeshcan be grouped; so can Freemarkerand Velocity. Which one within each group to use is not a matter of this discussion, there are enough questions and discussions about it.

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

This is an interesting read, but can't quite convince me to use tiles.

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

My question is - what do these frameworks give that can't be properly done with<@ include file="..">and JSTL. Main points (some taken from the article):

我的问题是 -这些框架提供了什么，<@ include file="..">而 JSTL无法正确完成。主要观点（部分摘自文章）：

1. Including parts of pages, like header and footer- there isn't a difference between:

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

   and

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

2. Defining parameters in the header- like title, meta tags, etc. This is very important, especially from SEO point of view. With the templating options you can simply define a placeholder which each page should define. But so you can in jsp with JSTL, using <c:set>(in the including page) and <c:out>(in the included page)

3. Layout reorganization- if you want to move the breadcrumb above the menu, or the login box above another side-panel. If page inclusions (with jsp) is not well organized, you might need to change every single page in such cases. But if your layout is not overly complex, and you put the common things in header/footer, there is nothing to worry about.

4. Coupling between the common components and the specific content- I don't find an issue with this. If you want to reuse some fragment, move it to a page that doesn't include any header/footer, and include it wherever needed.

5. Efficiency- <%@ include file="file.jsp" %>is more efficient than anything else, because it is compiled once. All other options are parsed/executed many times.

6. Complexity- all non-jsp solutions require additional xml files, additional includes, pre-processor configurations, etc. This is both a learning curve and introducing more potential points of failure. Also, it makes support and changing more tedious - you have to check a number of files/configurations in order to understand what's happening.

7. Placeholders- do velocity/freemarker give anything more than JSTL? In JSTL you put placeholder, and use the model (placed in request or session scope, by controllers) to fill these placeholders.

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 中放置占位符，并使用模型（放置在请求或会话范围内，由控制器）来填充这些占位符。

So, convince me that I should use any of the above frameworks instead of/in addition to plain JSP.

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

回答by Thorbj?rn Ravn Andersen

One of the best arguments for facelets (not in your list, but I'll just mention it) opposed to using JSP is that the compilation is integrated with the interpreter instead of being delegated to the JSP compiler. This means that one of the most annoying things I had with JSF 1.1 - having to change the id-attribute on a surrounding JSF-tag when saving a change in order for the runtime engine to discover the change - went away, giving the save-in-editor, reload-in-browser cycle back, along with much better error messages.

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

回答by matt b

A few arguments for Velocity (I haven't used Freemarker):

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

• Potential to re-use templates outside of a web context, such as in sending emails
• Velocity's template language syntax is farsimpler than JSP EL or tag libraries
• Strict separation of view logic from any other sort of logic - no possible option to drop down to using scriptlet tags and doing nasty things in your templates.

• 在 Web 上下文之外重用模板的潜力，例如在发送电子邮件时
• Velocity的模板语言的语法是远远高于JSP EL或标签库简单
• 将视图逻辑与任何其他类型的逻辑严格分离 - 无法选择下拉到使用 scriptlet 标签并在模板中做讨厌的事情。

Placeholders - do velocity/freemaker give anything more than JSTL? In JSTL you put placeholder, and use the model (placed in request or session scope, by controllers) to fill these placeholders.

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

Yes, referencesare really the core of VTL:

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

<b>Hello $username!</b>

or

或者

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

Efficiency - <%@ include file="file.jsp" %>is more efficient than anything else, because it is compiled once. All other options are parsed/executed many times.

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

Not so sure I agree with or understand this point. Velocity has an option to cache templates, meaning the abstract syntax tree they are parsed into will be cached rather than read from disk each time. Either way (and I don't have solid numbers for this), Velocity has always just felt fastfor me.

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

Layout reorganization - if you want to move the breadcrumb above the menu, or the login box above another side-panel. If page inclusions (with jsp) is not well organized, you might need to change every single page in such cases. But if your layout is not overly complex, and you put the common things in header/footer, there is nothing to worry about.

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

The difference is, with a JSP approach, wouldn't you be re-organzing this layout in every JSP file that uses the same header/footer? Tiles and SiteMesh allow you to specify a base layout page (JSP, Velocity template, etc - both are JSP frameworks at their heart) where you can specify whatever you want and then just delegate to a "content" fragment/template for the main content. This means there would be just one file to move the header in.

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

回答by mooreds

The choice between jsp:includeand Tiles/Sitemesh/etcis the choice between simplicity and powerthat developers face all the time. Sure, if you only have a few files or don't expect your layout to change very often, then just use jstland jsp:include.

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

But applications have a way of growing incrementally, and it can be hard to justify the "stop new development and retrofit tiles (or some other solution) so we can fix future problems more easily", which is required if you don't use a complex solution in at the start.

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

If your sure your application will always remain simple, or you can set some benchmark of application complexity after which you will integrate one of the more complex solutions, then I'd recommend not using tiles/etc. Otherwise, use it from the get-go.

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

回答by Ibrahim

A good view technology eliminates most and most anoying if/switch/conditional statements, simple include does not. Using a 'complex' view technology results in a 'simple' application.

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

回答by Singagirl

You didn't provide information about specific of your applications. For example I do not use JSP just for few reasons:

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

It is hard to avoid using Java code in JSP templates so your break concept of pure View, and as result you will have difficulties to maintain code in several places as view and controller

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

JSP automatically creates JSP context which establishes a session. I may want to avoid it, however if your applications always use session it can be not a problem for you

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

JSP requires compilation and if target system doesn't have Java compiler, any minor tweaking will require to use other system and then redeploy

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

Minimal JSP engine is about 500k of bytecode plus JSTL, so it can be not suitable for embedded systems

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

Template engine can generate different content type of the same model, let say JSON payload, webpage, e-mail body, CSV and so on.

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

Non Java programmer may have difficulties to work with JSP templates, when non technical people never had difficulties to modify regular templates.

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

I was asking same question long time ago and ended by writing my framework (surely template engine based) which was free from all disadvantages I saw in other solutions. Needless to say it is about 100k of byte code.

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

回答by Mikkel L?kke

I realize that this comes off as a smart ass answer, but the truth of it is, if you don't see any advantage to using templating over code in your current project, it's probably because in your current project, there isn't one.

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

Part of it is about scale. You might think that includes are every bit as powerful as let's say sitemesh, and that's certainly true, at least for a small number of pages (I'd say probably about 100), but if you have several thousands it starts becoming unmanageable. (So for eBay it's not necessary, for Salesforce it probably is)

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

Also, as has been mentioned before, freemarker and velocity are not servlet specific. you can use them for anything (mail templates, offline documentation, etc.). You do not need a Servlet container to use freemarker or velocity.

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

Lastly your point 5 is only partially true. It is compiled every time it is accessed if it has not been so already. This mean that whenever you change something you need to remember to delete your servlet containers "work" directory, so that it recompiles the JSP. This is unnecessary with a templating engine.

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

TL;DRTemplaing engines were written to address some (perceived or real) shortcomings of JSP + JSTL. Whether you should use them or not depends entirely on your requirements and the scale of your project.

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

回答by Bart

I'm not going to convince you to use other technologies. For all I know everyone should just stick to JSP if it works for them.

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

I work mainly with Spring MVC and I find JSP 2+ in combination with SiteMeshthe perfect match.

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

SiteMesh 2/3

站点网格 2/3

Provide decorators to be applied to the views mostly like inheritance works in other templating engines. Such feature is unthinkable to work without nowadays.

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

JSP 2+

JSP 2+

People claiming that JSP will make it hard to avoid Java code in templates is bogus. You just shouldn't do it and with this version it's unnecessary to do so. Version 2 supports calling methods using EL which is a big advantage compared to previous versions.

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

With JSTLtags your code will still look like HTML so it's less awkward. Spring packs a lot of support for JSP through taglibs which is very powerful.

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

The taglibs are also easy to extend so customizing your own environment is a breeze.

taglibs 也很容易扩展，所以定制你自己的环境是轻而易举的。