代码之家 › 专栏 › 技术社区 › Bozho

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

freemarker tiles velocity jsp java

Bozho · 技术社区 · 14 年前

我将选择一种方式来组织我的视图(使用spring mvc,但这不重要)

据我所见,有6种选择(尽管它们并不相互排斥):

瓷砖
网站网格
模板引擎
速度
<jsp:include>
<%@ include file="..">

瓷砖和 网站网格 可以分组;也可以 模板引擎 和速度 . 每个小组中使用哪一个不是本次讨论的问题,有足够的问题和讨论。

This is an interesting read ,但不能完全说服我使用瓷砖。

我的问题是- 这些框架提供了哪些不能正确使用的功能 <@ include file=".."> 还有JSTL。要点(有些摘自文章):

包括部分页面,如页眉和页脚 -两者之间没有区别:

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

和

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

在标题中定义参数 -像标题,元标签等。这是非常重要的,特别是从搜索引擎优化的角度。使用模板选项,您可以简单地定义每个页面应该定义的占位符。但是这样您就可以在jsp中使用 JSTL公司 ,使用 <c:set> (在包含页中)和 <c:out> (附页)
布局重组 -如果要将面包屑移到菜单上方,或将登录框移到另一个侧面板上方。如果页面包含(使用jsp)没有很好的组织,在这种情况下可能需要更改每个页面。但是如果你的布局不是太复杂,你把常见的东西放在页眉/页脚,就没有什么好担心的了。
公共组件和特定内容之间的耦合 -我觉得这没什么问题。如果要重用某个片段,请将其移动到不包含任何页眉/页脚的页面,并在需要时将其包括在内。
效率 - <%@ include file="file.jsp" %> 比任何东西都更有效,因为它只编译一次。所有其他选项都会被多次解析/执行。
复杂性 -所有非jsp解决方案都需要额外的xml文件、额外的include、预处理器配置等。这既是一个学习曲线,也会引入更多潜在的故障点。而且,它使支持和更改变得更加乏味-您必须检查许多文件/配置才能了解发生了什么。
占位符 -velocity/freemarker是否提供了比JSTL更多的功能?在JSTL中放置占位符,并使用模型(由控制器放置在请求或会话范围中)来填充这些占位符。

所以,让我相信我应该使用上面的任何框架,而不是/除了普通的JSP之外。

7 回复 | 直到 10 年前

matt b 14 年前

关于速度的几个论点(我没有使用Freemarker):

在web上下文之外重复使用模板的可能性,例如在发送电子邮件时
Velocity的模板语言语法是远的比JSP EL或标记库简单
视图逻辑与任何其他类型的逻辑的严格分离-没有可能选择使用scriptlet标记并在模板中执行讨厌的操作。

占位符-velocity/freemaker是否提供了比JSTL更多的功能?在JSTL中放置占位符,并使用模型(由控制器放置在请求或会话范围中)来填充这些占位符。

对, references 是VTL的核心:

<b>Hello $username!</b>

或

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

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

我不太同意或理解这一点。Velocity有一个缓存模板的选项,这意味着每次将缓存解析模板的抽象语法树,而不是从磁盘读取。不管怎样(我没有确切的数字),速度总是 快速的 为了我。

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

不同的是,使用JSP方法,您不会在每个使用相同页眉/页脚的JSP文件中重新组织这个布局吗?Tiles和SiteMesh允许您指定一个基本的布局页面(JSP、Velocity模板等,它们都是JSP框架的核心),在那里您可以指定您想要的任何内容,然后只委托给主内容的“内容”片段/模板。这意味着只有一个文件可以移动头。

mooreds 10 年前

选择 jsp:include 和 瓷砖/地网/等 是两者之间的选择 简单和强大 开发商一直面临的问题。当然,如果您只有几个文件或者不希望布局经常更改,那么只需使用 jstl 和 jsp:include .

但是应用程序有一种增量增长的方式,很难证明 “停止新的开发和翻新瓷砖(或其他解决方案),以便我们可以更容易地解决未来的问题” ,如果一开始没有在中使用复杂的解决方案,则这是必需的。

如果您确信应用程序将始终保持简单,或者您可以设置一些应用程序复杂性的基准,之后您将集成其中一个更复杂的解决方案,那么我建议不要使用瓦片/等等。否则,从GEGO中使用它。

Bart 11 年前

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

我主要与Spring MVC一起工作,我发现 JSP 2+与SiteMesh的结合 完美的搭配。

站点网格2/3

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

JSP二+

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

与 JSTL公司 标记你的代码仍然看起来像HTML,所以它不那么尴尬。Spring通过非常强大的taglibs打包了对JSP的大量支持。

taglib也很容易扩展,因此定制自己的环境很容易。

Thorbjørn Ravn Andersen 14 年前

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

Ibrahim 13 年前

一个好的视图技术消除了大多数和大多数异常的if/switch/conditional语句,而simple include则没有。使用“复杂”视图技术会产生“简单”应用程序。

Singagirl 11 年前

您没有提供有关特定应用程序的信息。例如,我不使用JSP的原因如下:

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

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

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

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

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

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

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

Mikkel Løkke 11 年前

我知道这是一个聪明的答案,但事实是,如果你认为在当前项目中使用模板而不是代码没有任何优势,那可能是因为在当前项目中,没有模板。

一部分是关于规模。你可能会认为include的功能和sitemesh一样强大,这当然是对的,至少对于一小部分页面(我想大概是100页左右),但是如果你有几千页,它就会变得无法管理。(因此,对于eBay来说,这是不必要的,对于Salesforce来说,这可能是必要的)

另外,如前所述,freemarker和velocity不是特定于servlet的。您可以将它们用于任何事情(邮件模板、脱机文档等)。使用freemarker或velocity不需要Servlet容器。

最后,你的第五点只是部分正确。每次访问时都会编译它,如果还没有这样做的话。这意味着,每当您更改需要记住的内容以删除servlet容器的“工作”目录时,它就会重新编译JSP。这对于模板引擎是不必要的。

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