为什么我会使用模板引擎? jsp include和jstl vs tiles,freemarker,velocity,sitemesh

我正要select组织我的观点(用spring-mvc,但这不应该太重要)

据我所知,有6个选项(尽pipe它们不是相互排斥的):

  • 瓷砖
  • SiteMesh的
  • Freemarker的
  • 速度
  • <jsp:include>
  • <%@ include file="..">

瓷砖Sitemesh可以分组; 所以可以Freemarker速度 。 每个组内使用哪一个不是讨论的问题,关于它的问题和讨论已经足够了。

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

我的问题是, 这些框架给出了什么,不能正确使用 <@ include file="..">和JSTL。 要点(一些从文章中提取):

  1. 包括页面的部分,如页眉和页脚 – 之间没有区别:

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

     <tiles:insert page="header.jsp" /> 
  2. 在标题中定义参数 – 如标题,元标记等。这是非常重要的,尤其是从SEO的angular度来看。 使用模板选项,您可以简单地定义每个页面应该定义的占位符。 但是,所以你可以在jsp中使用JSTL ,使用<c:set> (在包含页面)和<c:out> (在包含的页面中)

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

  4. 通用组件和具体内容之间的耦合 – 我不觉得这个问题。 如果你想重用一些片段,把它移动到一个不包含任何页眉/页脚的页面,并将其包含在需要的地方。

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

  6. 复杂性 – 所有非jsp解决scheme都需要额外的xml文件,额外的包含,预处理器configuration等。这既是学习曲线,也是引入更多潜在的失败点。 此外,它使支持和变化更乏味 – 你必须检查一些文件/configuration,以了解发生了什么事情。

  7. 占位符 – 速度/ freemarker给予比JSTL更多的东西吗? 在JSTL中,您将占位符,并使用模型(放置在请求或会话范围内,由控制器)来填充这些占位符。

所以说服我,除了普通的JSP以外,我应该使用上面的任何框架。

Velocity的几个参数(我没有使用Freemarker):

  • 在Web上下文之外重复使用模板的潜力,例如发送电子邮件
  • Velocity的模板语言语法比JSP EL或标签库简单得多
  • 从任何其他types的逻辑严格分离视图逻辑 – 没有可能的选项下降到使用scriptlet标签,并在您的模板做恶心的事情。

占位符 – 速度/ freemaker给予比JSTL更多的东西吗? 在JSTL中,您将占位符,并使用模型(放置在请求或会话范围内,由控制器)来填充这些占位符。

是的, 引用实际上是VTL的核心:

 <b>Hello $username!</b> 

要么

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

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

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

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

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

jsp:includeTiles / Sitemesh / etc之间的select是开发者面临的简单性和权力之间的select。 当然,如果你只有几个文件,或者不希望你的布局经常改变,那么就使用jstljsp:include

但是,应用程序有一种递增的方式,很难说“停止新的开发和改进瓷砖(或其他解决scheme),所以我们可以更容易地解决未来的问题” ,如果你不使用复杂的解决scheme在开始。

如果你确定你的应用程序总是很简单,或者你可以设置一些应用程序复杂性的基准,然后你将集成一个更复杂的解决scheme,那么我build议不要使用tiles / etc。 否则,从一开始就使用它。

我不打算说服你使用其他技术。 对于所有我知道每个人都应该坚持到JSP,如果它适用于他们。

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

SiteMesh 2/3

提供应用于视图的装饰器,大部分类似于其他模板引擎中的inheritance。 这种function在现在工作是不可想象的。

JSP 2+

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

有了JSTL标签,你的代码仍然看起来像HTML,所以它不那么笨拙。 Spring通过很强大的taglibs支持JSP。

taglibs也很容易扩展,所以定制你自己的环境是一件轻而易举的事情。

Facelets的最佳参数之一(不在你的列表中,但我会提到它)反对使用JSP是编译与解释器集成,而不是委派给JSP编译器。 这意味着我使用JSF 1.1时最烦人的事情之一 – 为了让运行时引擎发现变化,必须在更改周围的JSF标签上的id-属性时,才消失,在编辑器中,在浏览器中重新加载,以及更好的错误消息。

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

您没有提供有关您的应用程序的具体信息。 例如,我不使用JSP仅仅是因为几个原因:

很难避免在JSP模板中使用Java代码,因此您的纯视图的中断概念,因此在维护视图和控制器的几个地方会遇到困难

JSP自动创buildbuild立会话的JSP上下文。 我可能想要避免它,但是如果你的应用程序总是使用会话,它可以不是你的问题

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

最小的JSP引擎大约有500k字节码和JSTL,所以它不适合embedded式系统

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

非Java程序员可能难以使用JSP模板,当非技术人员从来没有难以修改常规模板。

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

我意识到这是一个聪明的屁股答案,但事实是,如果你没有看到在当前项目中使用代码模板的好处,这可能是因为在你当前的项目中,没有一个。

其中一部分是关于规模。 你可能会认为这个包含的内容和sitemesh一样强大,至less在less量的页面上(我可能说大概有100个),这确实是真的,但是如果你有几千个,它就会变得难以pipe理。 (所以对于eBay来说,没有必要,对于Salesforce来说可能是这样)

另外,如前所述,freemarker和velocity并不是servlet特有的。 你可以用它来做任何事情(邮件模板,离线文档等)。 你不需要一个Servlet容器来使用freemarker或velocity。

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

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