Question

我使用PHP仅为视图文件开发我的Web应用程序，我不觉得有任何限制，但我听说有一致的开发人员提倡“外部”模板引擎。那么模板引擎提供的简单PHP缺乏什么呢？

我正在寻找实用的东西，所以我排除了以下内容：

照看糟糕的开发人员（即使用模板引擎，因为它会强迫您不要将代码混合到演示文稿中）
语法简洁（我在Vim中使用<?php echo $stuff; ?>之类的内容进行映射，使用花括号不会有任何区别）
非程序员的语法更简单（我单独开发，这不是问题）

Answer 1

新语法

有些人不会同意，但自从我一直在使用Twig时，“for ... else”感觉很对。它可能不是很多，但它让我的模板更加清晰。

{% for row in articles %}
 Display articles ...
{% else %}
 No articles.
{% endfor %}

自动转义

您可以让模板引擎自动转义任何输出。这很棒，因为你不再需要重复htmlspecialchars ......无处不在。 Twig做得很好。

{% autoescape on %}
  Everything will be automatically escaped in this block
{% endautoescape %}

模板继承

我喜欢的另一个功能是扩展基本模板的能力。这是一个基本的例子

base.html模板

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="en">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  {% block head %}
    <link rel="stylesheet" href="style.css" />
    <title>{% block title %}{% endblock %} - My Webpage</title>
  {% endblock %}
</head>
<body>
  <div id="content">{% block content %}{% endblock %}</div>
  <div id="footer">
    {% block footer %}
      &copy; Copyright 2009 by <a href="http://domain.invalid/">you</a>.
    {% endblock %}
  </div>
</body>

child.html模板

{% extends "base.html" %}

{% block title %}Index{% endblock %}
{% block head %}
  {% parent %}
  <style type="text/css">
    .important { color: #336699; }
  </style>
{% endblock %}
{% block content %}
  <h1>Index</h1>
  <p class="important">
    Welcome on my awesome homepage.
  </p>
{% endblock %}

子模板可以覆盖页面特定样式，内容等的块...您还可以注意到使用{％parent％}来抓取父项内容，这样您就不会在覆盖时丢失所有内容。

我建议您先给Twig。非常有用。

Answer 2

关注点分离。

这种事情在使用MVC / MTV方法时是标准的 - 数据的呈现必须与数据显示分开，但如果您使用的是普通的PHP，则不会。

使用模板引擎可以轻松地将显示内容与显示方式分开。

我想你可能会认为这属于“照顾坏开发者”，因为一个优秀的开发者无论如何都应该这样做，但在我看来，模板引擎也让优秀的开发人员更容易。

Answer 3

在视图之间轻松切换

根据网络的当前状态，我需要以不同的格式提供我的信息：

静态html页面
另一个HTML页面上的动态加载视图
数据的JSON对象
我的Flash部分中使用的数据的XML提要

这些格式的信息可以相同，只有视图不同。使用某种模板引擎，我可以在这些视图之间快速切换。

Answer 4

使用模板，您还可以将演示文稿的可转让性委托给设计人员。设计人员可以创建模板，开发人员可以在逻辑中工作。保持演示文稿的一致性也更容易。

Answer 5

我使用自己的“模板”引擎，非常基本的东西，将value分配给[key]以及排序。
当我第一次寻找模板引擎时，我发现它很聪明，但它有很多安全问题，我最终写下了我自己需要的东西。
你问为什么？因为它有许多功能可以使你的编码更快（你想到的东西和你可以委托给模板系统而不是代码的东西）
大多数编码员选择了模板系统，在团队工作时需要保持标准。

Answer 6

如果您希望开发可以使用许多不同模板和布局进行自定义的应用程序，同时保持设计与逻辑分离，例如：对于不同的客户，您可能需要考虑使用模板系统。

但是如果您的应用程序只需要一个模板并且永远不会更改布局，那么坚持使用对您有用的内容，为什么要更改？：）

Answer 7

一些模板引擎可以编译模板，从而实现高度优化的转换。以.NET中的XslCompiledTransform为例。

Answer 8

你的非答案看起来像真正的答案，但是以非常居高临下的方式表达。例如：

照顾糟糕的开发人员（即使用模板引擎，因为它会强迫您不要将代码混合到演示文稿中）

我称之为Rule of Least Power的应用程序。它使您的模板对所有用户更有用，而不仅仅是“糟糕的开发人员”。

限制是编程语言的原因。 PHP没有内联汇编功能，并不是因为Rasmus认为你们都是“婴儿”。

Answer 9

当我需要沙盒时，我发现自己使用模板引擎。例如，让托管CMS的用户编辑模板。

Answer 10

首先在这里解答答案和一般背景：

人们使用它们的主要原因是它们通常会让事情变得更加简洁。关于这是否总是净利益，这是值得怀疑的。学习一门新语言而不具备手头语言灵活性的增加的组合负担最终会带来比使用模板语言更多的缺点。 Twig特别需要手动导出核心PHP函数。寻求简洁的最好的模板语言会更好，而不是使用标记器来扩展PHP。

自动转义是另一个值得怀疑的功能。对于编码非常差的开发人员来说，自动转义可能更安全，但是否则会削弱安全性，使其无法理解，并表示在任何情况下默认情况下所有内容都是安全的。一个非常安全的模板引擎需要对其上下文有很多了解，有时候这一点无法确定，只有程序员知道某些事情发生了什么。如果您需要安全编程，您需要让开发人员不依赖于自动转义，期限。这也是PHP实际可以做的事情，如果您将PHP文件标记化，您可以将原始文本与PHP分开并将PHP部分包装在输出缓冲区中，然后应用您喜欢的任何过滤器，因此这不是模板语言专用功能。

一些模板引擎可以使预生成更容易和预编译以使它们更快，但这也可以通过原生模板实现。解析模板是必需的，这通常会降低它们的效率，并且使用它们的过程也更加复杂。增加的复杂性模板引入是重要的。这通常可以从你身上抽象出来，但最终会让你受到影响，例如缓存问题（过时的条目），性能问题，调试时更多的颤动和混乱，更多的层和更多的代码被解决的更多可能出错等等。

许多功能，例如扩展模板，您再次不需要使用twig来实现这一目标。类似于htmlspecialchars之类的东西，大多数人会为他们经常使用的所有函数创建简短的辅助函数。

那么你应该在哪里肯定使用像Twig这样的模板语言？

宝宝坐在糟糕的开发人员身上是有效的，虽然我不确定如果你不得不使用像twig这样的东西试图包含它们，他们应该被认为是开发人员。你也会讨好优秀的开发人员，你会想知道他们为什么要通过箍来实现其他简单的事情。
您可能希望为可能希望处理HTML的各方提供模板，但不要公开系统内部等。这可能是您拥有CMS的地方，用户可以编辑模板但与开发人员不一样。这与上述内容有关，但这是一个更为真实的案例，您可能会从中获益并且这可能是合理的。
类似的情况是您可能希望在系统之间使用模板，在这种情况下，模板语言可以是便携式解决方案。这可能不仅仅是您有多个后端的地方，而是您有不寻常的架构要求的地方，例如前向服务器从下游派生的数据渲染视图。更进一步，您可能需要可以渲染前端或后端的模板。如果您只需将数据发送到前端，因为它可以自己呈现视图，这可能会更有效。但是，由于各种原因，您可能还需要回退到后端。
另一种情况是静态分析，包括跨多种语言。大多数语言通过字符串连接有效地模板化，并且无法识别您正在生成的语言。在某些情况下，当您可以完全解析它，语言和HTML时，模板语言可以提供一个好处。实现这一目标的另一种方法是尽可能使用HTML本身进行模板化以表示事物，如使用类等，以及HTML提供的设施，可以让您将行为附加到事物上。即使您无法解析您正在模板化的语言，模板语言也可以比PHP更易于解析。这可以用于优化或具有更容易转换的模板。
您的语言并不适合创建HTML和其他语言。 PHP是一种模板语言，因此在大多数情况下，使用模板语言几乎不会产生很大的阻力。但是，如果您使用的是Java之类的东西，那么您很可能需要一个模板引擎。模板语言是一种DSL，但是如果你已经拥有一台可以做得非常好的DSL，那就是它的YAGNI。
定制模板。您有一定的输出格式和域，可以从定制的模板语言中获益。这取决于您的输出格式。

所有这些情况都是针对具体情况的，并且不够普遍，默认情况下应该使用模板语言。模板语言只能通过不同程度的成功来解决这些问题（例如，许多人不知道HTML）。如果我将Twig中的十分之一评为十分之一，那么每个平均值都不会超过5。

您可以将Twig转换为PHP，但不能将PHP转换为Twig。这有时可能很有用，但由于您失去了PHP的很多灵活性，因此成本很高。

在少量的Twig内部构件中，我所接触到的质量也很差，或者导入了不良标准。例如，当我五年前第一次尝试时，解析器不支持或者至少不支持持久空白。我有一个需要重构的场景，这意味着我需要能够解析Twig，再次修改并输出它来重写数千个模板中的代码，twig不支持它，我不得不通过解析器进行转换自己。

同样，我最近调查了Twig的转义。特别是JS转义脱颖而出支持转义JS字符串和其他奇怪的事情，而不是简单地使用json_encode。很可能，你在框架中逃避的习惯是错误的。它自己通常更可靠和安全（只要你知道如果JSON编码一个包含字符串的字符串会发生什么，并将其模板化为javascript文字而没有足够的转义）。

在大多数情况下，数百甚至数千行神奇模板系统和其他相关系统实现逃生，消毒等等都是可怕的做法，试图猜测你的情景或试图迎合每一个可能的情况，增加更多的范围数据损坏的奇怪错误，增加了更多安全失误的机会等等。通常，您会发现框架中的这类内容可以用一个或两个更安全的线路功能来代替。你还会有其他愚蠢的事情，有时也喜欢一遍又一遍地处理一些事情以防万一，因为框架对于你在做什么感到天真，好像你自己做了一些事情，你确切知道你是什么＆＃39然后再做一些事情，比如一遍又一遍地消毒相同的字符串。

模板引擎比仅使用PHP有什么真正的优势？

10 个答案:

新语法

自动转义

模板继承