95

我即将选择组织我的视图的方式（使用spring-mvc，但这并不重要）

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

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

可以对Tiles和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. 占位符——velocity/freemarker 提供的不仅仅是 JSTL 吗？在 JSTL 中放置占位符，并使用模型（由控制器放置在请求或会话范围内）来填充这些占位符。

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

4

7 回答 7

17

Velocity 的一些论据（我没有使用过 Freemarker）：

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

占位符——velocity/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 框架的核心），您可以在其中指定任何您想要的内容，然后只需委托给主要内容的“内容”片段/模板. 这意味着只有一个文件可以将标题移入。

于 2010-07-02T20:18:41.477 回答
12

Tiles/Sitemesh/etc之间jsp:include的选择是开发者一直面临的简单和强大之间的选择。当然，如果您只有几个文件或不希望您的布局经常更改，那么只需使用and 。jstljsp:include

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

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

于 2011-05-12T19:26:44.320 回答
5

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

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

站点网格 2/3

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

JSP 2+

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

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

标签库也很容易扩展，因此自定义您自己的环境是一件轻而易举的事。

于 2014-04-08T22:12:20.320 回答
2

一个好的视图技术可以消除大多数最烦人的 if/switch/条件语句，而简单的 include 则不能。使用“复杂”视图技术会产生“简单”应用程序。

于 2011-08-16T12:34:32.347 回答
2

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

于 2010-07-02T20:05:01.753 回答
1

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

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

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

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

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

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

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

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

于 2014-02-13T08:36:26.230 回答
0

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

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

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

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

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

于 2014-02-13T08:58:36.403 回答