为什么我要使用模板引擎？ jsp include 和 jstl 与tiles、freemarker、velocity、sitemesh
我即将选择组织视图的方式（使用 spring-mvc，但这应该不重要）
据我所知，有 6 个选项（尽管它们并不相互排斥）：
- Tiles
- Sitemesh
- Freemarker
- Velocity
<%@ include file=" ..">
Tiles 和 Sitemesh 可以分组； Freemarker 和 Velocity 也可以。每个组中使用哪一个不是本次讨论的问题，已经有足够多的问题和讨论了。
这是一本有趣的读物，但可以'不太说服我使用瓷砖。
我的问题是 - 这些框架提供了什么无法使用 <@ include file=".."> 和 JSTL 正确完成的功能。要点（一些摘自文章）：
包括页面的部分内容，例如页眉和页脚 - 之间没有区别：
<%@ include file="header.jsp" %>和
在页眉中定义参数 -像标题、元标签等。这非常重要，尤其是从 SEO 的角度来看。使用模板选项，您可以简单地定义每个页面应定义的占位符。但是，您可以在 jsp 中使用 JSTL，使用
布局重组 - 如果您想将面包屑移动到菜单上方，或将登录框移动到另一个侧面板上方。如果页面包含（使用 jsp）组织得不好，在这种情况下您可能需要更改每个页面。但如果你的布局不是太复杂，并且你把常用的东西放在页眉/页脚中，就没有什么可担心的。
公共组件和特定内容之间的耦合 - 我没有发现这方面的问题。如果您想重用某些片段，请将其移动到不包含任何页眉/页脚的页面，并在需要的地方包含它。
效率 -
<%@ include file="file.jsp" %>比其他任何东西都更高效，因为它只编译一次。所有其他选项都会被解析/执行多次。复杂性 - 所有非 jsp 解决方案都需要额外的 xml 文件、额外的包含文件、预处理器配置等。这既是一个学习曲线，也会引入更多潜在的故障点。此外，它使支持和更改变得更加乏味 - 您必须检查许多文件/配置才能了解发生的情况。
占位符 -velocity/freemarker 是否提供比 JSTL 更多的东西？在 JSTL 中，您放置占位符，并使用模型（由控制器放置在请求或会话范围中）来填充这些占位符。
因此，请说服我，我应该使用上述任何框架来代替/除了纯 JSP 之外。
I'm about to choose to way to organize my view (with spring-mvc, but that shouldn't matter much)
There are 6 options as far as I see (though they are not mutually exclusive):
- Tiles
- Sitemesh
- Freemarker
- Velocity
<jsp:include><%@ include file="..">
Tiles and Sitemesh can be grouped; so can Freemarker and Velocity. Which one within each group to use is not a matter of this discussion, there are enough questions and discussions about it.
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):
Including parts of pages, like header and footer - there isn't a difference between:
<%@ include file="header.jsp" %>and
<tiles:insert page="header.jsp" />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)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.
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.
Efficiency -
<%@ include file="file.jsp" %>is more efficient than anything else, because it is compiled once. All other options are parsed/executed many times.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.
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.
So, convince me that I should use any of the above frameworks instead of/in addition to plain JSP.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
Velocity 的一些论点（我没有使用过 Freemarker）：
是的，引用确实是 VTL 的核心：
或者
不太确定我是否同意或理解这一点。 Velocity 有一个缓存模板的选项，这意味着它们解析成的抽象语法树将被缓存，而不是每次都从磁盘读取。不管怎样（我没有可靠的数字），Velocity 对我来说总是感觉快。
不同之处在于，使用 JSP 方法，您不会在使用相同页眉/页脚的每个 JSP 文件中重新组织此布局吗？ Tiles 和 SiteMesh 允许您指定一个基本布局页面（JSP、Velocity 模板等 - 两者本质上都是 JSP 框架），您可以在其中指定您想要的任何内容，然后将主要内容委托给“内容”片段/模板。这意味着只有一个文件可以将标头移入其中。
A few arguments for Velocity (I haven't used Freemarker):
Yes, references are really the core of VTL:
or
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 fast for me.
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:include和 Tiles/Sitemesh/etc 之间的选择是开发人员始终面临的简单性和强大之间的选择。当然，如果您只有几个文件或者不希望布局经常更改，那么只需使用jstl和jsp:include即可。但应用程序有一种逐步增长的方式，并且很难证明“停止新的开发和改造瓷砖（或其他解决方案）以便我们可以更轻松地解决未来的问题”的合理性，这是必需的如果您一开始就不使用复杂的解决方案。
如果您确定您的应用程序将始终保持简单，或者您可以设置一些应用程序复杂性基准，然后集成更复杂的解决方案之一，那么我建议不要使用图块/等。否则，从一开始就使用它。
The choice between
jsp:includeand Tiles/Sitemesh/etc is the choice between simplicity and power that 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 usejstlandjsp: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.
我不会说服您使用其他技术。据我所知，如果 JSP 对他们有用的话，每个人都应该坚持使用 JSP。
我主要使用 Spring MVC，我发现 JSP 2+ 与 SiteMesh 结合 是完美的搭配。
SiteMesh 2/3
提供应用于视图的装饰器，就像其他模板引擎中的继承工作一样。如今，没有这样的功能是不可想象的。
JSP 2+
人们声称 JSP 将使模板中很难避免 Java 代码是假的。您只是不应该这样做，并且在这个版本中没有必要这样做。版本2支持使用EL调用方法，这与之前的版本相比是一个很大的优势。
使用 JSTL 标签，您的代码看起来仍然像 HTML，因此不会那么尴尬。 Spring通过taglibs封装了很多对JSP的支持，功能非常强大。
标签库也很容易扩展，因此自定义您自己的环境变得轻而易举。
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.
I work mainly with Spring MVC and I find JSP 2+ in combination with SiteMesh the perfect match.
SiteMesh 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+
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.
With JSTL tags 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.
The taglibs are also easy to extend so customizing your own environment is a breeze.
反对使用 JSP 的 Facelets（不在您的列表中，但我只是提一下）的最佳论点之一是编译与解释器集成，而不是委托给 JSP 编译器。这意味着我在 JSF 1.1 中遇到的最烦人的事情之一 - 在保存更改时必须更改周围 JSF 标记上的 id 属性，以便运行时引擎发现更改 - 消失了，给出了保存 -在编辑器中、在浏览器中重新加载循环回来，以及更好的错误消息。
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.
良好的视图技术可以消除大多数最烦人的 if/switch/条件语句，而简单的 include 则不能。使用“复杂”视图技术会产生“简单”应用程序。
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.
您没有提供有关您的具体应用程序的信息。例如，我不使用 JSP 只是出于以下几个原因：
在 JSP 模板中很难避免使用 Java 代码，因此您打破了纯视图的概念，因此您将很难在多个位置自动维护视图和控制器
JSP 代码创建建立会话的 JSP 上下文。我可能想避免它，但是如果您的应用程序总是使用会话，这对您来说可能不是问题
JSP 需要编译，如果目标系统没有 Java 编译器，任何小的调整都需要使用其他系统，然后重新部署
最小 JSP引擎大约有 500k 字节码加上 JSTL，因此它可能不适合嵌入式系统。
模板引擎可以生成同一模型的不同内容类型，例如 JSON 负载、网页、电子邮件正文、CSV 等。
非 Java 程序员在使用 JSP 模板时可能会遇到困难，而非技术人员修改常规模板却从来没有困难。
我很久以前就问过同样的问题，最后编写了我的框架（肯定是基于模板引擎的），它没有我在其他解决方案中看到的所有缺点。不用说，它大约有 100k 字节代码。
You didn't provide information about specific of your applications. For example I do not use JSP just for few reasons:
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 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 requires compilation and if target system doesn't have Java compiler, any minor tweaking will require to use other system and then redeploy
Minimal JSP engine is about 500k of bytecode plus JSTL, so it can be not suitable for embedded systems
Template engine can generate different content type of the same model, let say JSON payload, webpage, e-mail body, CSV and so on.
Non Java programmer may have difficulties to work with JSP templates, when non technical people never had difficulties to modify regular templates.
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.
我意识到这是一个聪明的答案，但事实是，如果您没有看到在当前项目中使用模板相对于代码有任何优势，那可能是因为在您当前的项目中，没有一个。
其中一部分与规模有关。您可能认为 include 与 sitemesh 一样强大，这当然是正确的，至少对于少量页面（我想说可能大约 100 个），但如果您有数千个页面，它就会开始变得难以管理。 （因此对于 eBay 来说没有必要，对于 Salesforce 来说可能是必要的）
此外，正如前面提到的，freemarker 和velocity 不是特定于servlet 的。您可以将它们用于任何用途（邮件模板、离线文档等）。您不需要 Servlet 容器来使用 freemarker 或velocity。
最后，你的第5点只是部分正确。如果尚未编译，则每次访问时都会对其进行编译。这意味着每当您更改某些内容时，您需要记住删除 servlet 容器的“工作”目录，以便它重新编译 JSP。对于模板引擎来说这是不必要的。
TL;DR 模板引擎的编写是为了解决 JSP + JSTL 的一些（感知的或实际的）缺点。是否应该使用它们完全取决于您的要求和项目的规模。
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)
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.
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.
TL;DR Templaing 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.