【问题标题】：When to use PHP template engines [closed]何时使用 PHP 模板引擎 [关闭]
【发布时间】：2011-08-18 18:54:22
【问题描述】：

我正在用 php 构建一个包含很多页面的网站，我们有一个 9 人的团队正在开发它。所以只是想探索一下我们什么时候应该使用 PHP 模板引擎，什么时候不应该。所以我对使用 PHP 模板引擎的优缺点很感兴趣，所以我可以决定是否在我的情况下使用它。

【问题讨论】：

标签： php templates template-engine

【解决方案1】：

PHP 是一种模板语言。

根据我目前使用各种模板系统的经验，结论非常简单：不使用。

相反，按照应该编写的方式编写 PHP！除了echo 和for/foreach 之外，不要在.html 中做任何事情。如果您基于 MVC 之类的设计模式编写代码，这将变得更加明显：只需在内部 echo 和 foreach 并解释前端，它们绝不应该与 <?php 和 ?> 内部的代码混淆。

从那时起它就对我有用。对我来说，解释它们 Smarty 通常比解释永远不要弄乱 php 更难。

模板系统也会增加服务器的重量（有时只是一点点，有时您可能会感觉到）。一开始可能看起来过度优化，但我更喜欢让它尽可能简单。

注意：

例如，Smarty 是更难在 .html 文件中发现的，因为我所知道的唯一 Smarty 语法荧光笔是一个 NetBeans 插件，而且它是非常漂亮的测试版。另一方面，PHP 在任何体面的编辑器中都会突出显示它的语法。前端也更容易发现而不是乱七八糟。

总结

缺点（使用模板系统）

增加服务器负载（更轻或更重，没关系 - 你可以看到）
导致不良做法（逻辑包装在模板语言语法中）
模板语言的语法没有语法高亮显示 - 更难发现（对于编码器和前端）
花时间学习它并将其传授给前端
很难向前端团队解释（我曾多次向前端教授基本的 PHP - 而更多人已经能够编写自己的“初级”PHP；我从未教过一个前端 Smarty，以便他们可以做除{$var} 以外的其他事情）
让您避免真正的问题：逻辑和表示分离！
为您的项目增加额外的重量

优点（使用模板系统）

极度无聊（可能是唯一有效的论点）

模板系统更换

逻辑和表示分离（我建议 MVC 用于此任务以及它为其他开发领域提供的优点：更易于维护、抽象数据库等）
强迫自己在视图中只写echo 和迭代以进行回显：foreach 和for 应该完成 99% 的迭代需求；你也可以使用while 和do while

【讨论】：

我不同意你所说的很多。我不得不说，你似乎有点太偏颇了。我已经使用 Twig 大约一年了，我会推荐它。并不是说你必须使用它，或者它应该在所有情况下都使用，但肯定有好处。就像自动转义以防止 XSS 等。你所说的保持视图简单，限制 PHP 使用，这很好，但肯定意味着模板引擎的专业人士必须只有一组有限的命令/语句可以使用.
使用 Twig/Smarty/xx 没有任何问题，但在它们中所做的任何事情都不能在纯 PHP 中完成，因此使运行时/开发过程更加高效和清洁。依靠你的模板引擎来预防 XSS 只会带来麻烦，这是需要开发人员知识的地方。让我们不要重温magic_quotes...
我完全同意你的帖子。但是，我认为“只有 php echo 和 foreach”是不够的。布尔条件呢？例如，您想根据php数据生成或不生成一些html内容。你是怎样做的？您仍然必须在模板中放置 'php if($bool) { generate html }' 条件。不是吗？
在“专业”部分的“极度无聊”中加 1 ；-)
@Andrew <?php if ($condition): ?>some html<?php else: ?>other html<?php end; ?>

【解决方案2】：

对我来说，在决定是否应该使用单独的模板引擎或只使用 PHP 进行模板时，它总是归结为：

何时使用模板引擎

当您必须限制（沙盒）可以在模板中运行的代码时。

何时不使用模板引擎

所有其他时间。

【讨论】：

这正是Smarty在这里有一份兼职工作的原因（唯一的原因）。我们需要在考虑安全性和可读性的情况下从数据库运行动态内容。我们使用客户端复制/粘贴到 Smarty 解析的 WYSIWYG 的小标记，例如 {date} 和 {article_stub id="34"}。如果有人知道更好的方法，我会全力以赴。

【解决方案3】：

PHP 纯粹主义者会告诉您，PHP 本身就是一个模板引擎。我认为自己在这件事上是一个纯粹主义者，并建议只使用 PHP。它甚至为 if 和 loop 块提供了另一种语法，几乎是为模板样式的可读性而设计的。

然而，有些人仍然喜欢使用模板引擎，例如 Smarty。如果您确实选择了这条路线，有很多事情需要考虑：

谁来维护模板？如果维护模板的人已经了解 PHP，那么让他们学习新的伪 PHP 模板引擎是没有意义的。如果他们不懂 PHP，那么根据他们的背景，这仍然值得怀疑，因为大多数模板引擎只是实现了与 PHP 标记不同的语法（例如 <% %>）

你的模板会有多复杂？一些模板引擎对你在模板中可以做的事情有极大的限制（迫使你把所有东西都放在控制器中，有些几乎到了无用或不必要的地步hoop-jumping），而其他的则与原始 PHP 一样宽松（许多人认为这违背了模板引擎的目的）。

效率和速度有多重要？模板引擎会增加开销。时期。将自定义标签转换为 PHP 标签需要资源。他们添加多少以及它的重要性取决于许多因素（包括引擎本身）。如果您需要更快的网站速度，那么我会投票给模板引擎作为最先使用的引擎之一。

正如我所说，我还建议使用 PHP 作为您的模板“引擎”，但请注意其中的一些陷阱。主要是，在模板中添加不必要的逻辑非常容易。确保您的规则仅包含 echo、for/foreach 和基本的 if 块（例如 if is_admin() 等），并确保强制执行。

【讨论】：

Converting the custom tags to PHP tags takes resources - 大多数模板系统具有（或应该具有）良好的缓存功能。 Smarty 编译成纯 php。
一开始编译它们以及更新模板时仍然需要资源。
当然，但这可以忽略不计，因为每次编辑只发生一次。然而，查找和读取缓存会增加开销，但不会真正将标签转换为 php（创建缓存文件）。
很公平。现在有一个问题——所有模板引擎都会缓存已编译的模板吗？有人会认为他们会，但从理论上讲，理论和实践是相同的......
@Wesley Murch，首先：使用缓存需要增加可用 RAM。第二：如果我们必须学习模板引擎语言才能使用它们，为什么不花时间学习PHP的基础知识呢？ echo、foreach 和 if 的工作原理并不难理解。并不比模板引擎中的相同结构更难。

【解决方案4】：

绝对没有理由使用 php 模板引擎。逻辑和观点的分离是一种义务。这并不意味着使用模板引擎。使用模板引擎，您必须学习与 php 无关或与其他任何东西无关的东西。每个必须修改 smarty 或其他模板的来源的人都可能会对那些无用和阻碍混乱的废话感到恼火。 PHP 为您的模板提供了强大的功能，并以您使用它的每一种方式为您提供了所有可能性。有了十几个建议，PHP 就足够安全了。在不了解背后技巧的情况下使用模板引擎是不安全的。 Smarty 无法保护公共可编辑模板。

寻找设计模式。查看 Helper 和 MVC。保持您的代码简单且结构良好意味着比 smarty/any-template-engine 更聪明...

【讨论】：

【解决方案5】：

我建议在显示逻辑和其他数据获取操作之间使用一些很好的分离方法。实现 MVC 是一种很好的方式，并且大多数 PHP 框架都提供了 MVC 框架。

这使每个人都可以编写更简洁的代码，并使模板保持简单，以便那些技术含量较低的人（例如前端设计师）能够进入并编辑它们。

【讨论】：

【解决方案6】：

当存在跨多个网页重复的大量演示文稿并且您希望将业务和应用程序编程以及逻辑与演示文稿分开时，应该使用模板引擎。

这种分离的好处是：

更紧凑、更易读且无错误的应用程序逻辑
在不更改核心逻辑文件的情况下更改表示
在运行时动态改变显示

虽然 php 本身是一种模板语言在技术上是正确的，但将其描述为具有内置模板的 Web 编程语言更为准确。另一方面，大多数模板引擎使用带有内置编程指令的模板也是如此。这意味着在 php 中的太多模板和模板中的太多编程之间存在合理的平衡。平衡越好，您的编码就越容易，您的应用程序就越灵活和可扩展。

以 php 代码为例，该代码检索您最近 10 篇博客文章，并在调用该代码时将它们写入您博客上的 DIV 标签。如果复制相同的代码来创建 RSS 提要，您将在两个地方拥有相同的代码，当逻辑发生变化时需要在多个地方维护它。

如果在模板引擎的控制下调用完全相同的代码，那么根据是否提供了 RSS/XML 或 HTML 模板，您可以将相同的代码写入两种不同形式的输出。如果模板引擎写得好，php 代码既不知道也不关心提供给它的模板类型。 php 也可以输出 HTML、XML、SQL、PDF 或文本！

随着时间的推移，我用 Classic ASP 和 PHP 实现了许多网站，我发现一个好的模板引擎可以节省我大量的编程和调试时间，并且因为没有真正的 Classic ASP 模板引擎，所以我编写了 KudzuASP 来解决这个问题。你可以在我的网站上找到相关的项目 KudzuPHP，它是免费的。还有一个基于它的 Wordpress 插件。

【讨论】：

While it is technically true that php is itself a template language it is more accurate to describe it as a web programming language with built in templating. 我认为它在中间的某个地方。它最初的存在是为了解决类似于模板解决的问题。它后来变得健壮。

【解决方案7】：

您应该始终使用某种机制将标记与代码分开，就像您不应该在 HTML 中嵌入 CSS 一样。有太多的选择可以给你一个简单的答案。有像 smarty 或 fasttemplate 这样的模板引擎，然后有带有模板系统的框架（如 cake、code igniter 等）。您应该根据自己的需要单独评估它们

【讨论】：

【解决方案8】：

我只会使用 php 作为您的模板引擎。拥有 smarty 之类的东西不会带来额外的负担。他们只需要了解基本的 php。您可以使用.phtml 文件扩展名来表示模板文件...为什么要使用模板引擎？

需要明确的是，.phtml 模板文件中应该只有echos 和foreachs，不应在其中编写核心代码。

【讨论】：

9 个人处理一堆 .phtml 文件，其中代码和标记混合在一起是灾难的根源。
这与 9 个人在一个 smarty 模板上工作有什么不同？真正的目标是为模板开发一套标准。里面应该有什么，标记的外观等等。如果没有设置和遵守标准，任何东西都可能变成垃圾。
@David - 9 个人在 .phtml 文件中编写代码，相当于 9 个人应该学习逻辑和表示分离。在 .phtml 中，您 echo 并迭代 (foreach) 以便 echo。
@David，我明白你的意思了。我想我的答案有点模糊，要澄清一下。我的意思是您应该只使用 PHP 作为模板引擎并将实际的“模板”标记存储在 .phtml 文件中。我并不是要在模板标记中包含所有代码等。

【解决方案9】：

您尝试过 Stamp 模板引擎吗？

它仍然会增加服务器负载；但是我认为它修复了模板引擎的其他缺点。与 Smarty 和所有其他 PHP 模板引擎不同，StampTE 完全没有逻辑。您只需使用适当的 HTML cmets 标记区域（大多数设计师和前端工程师已经拥有这些标记，只是为了便于阅读）。它依靠这些标记为后端开发人员提供剪切和粘贴功能。后端 PHP 程序员可以从模板中复制和粘贴这些区域（如纸模型），并使用它构建网站和 Web 应用程序 GUI。此外，他们自己也有一个非常友好的 API。例如剪切一个区域：

   <!-- cut:siteMenu -->
       <nav>
          <ul>
            <li>...</li>
          </ul>
       </nav>
   <!-- /cut:siteMenu -->

他们可以使用面向对象的表示法：

$template->getSiteMenu()->setLink( ... ); etc..

我觉得这真的很酷。

http://www.stampte.com

【讨论】：

【解决方案10】：

确实，separation和reuse是这里的关键词。

在团队中开发和划分工作负载的最佳方式是网页设计师（集成商/html-ist 等）没有机会分解编程部分（数据库、文件、会话、语法）错误等等）。

我建议使用FigDice Template Engine，它在逻辑（程序、数据库、文件、算法等）和演示（它们呈现的视图和信息）之间进行了非常巧妙的分离，以确保完全安全。

FigDice 当然支持宏（文件的可重用部分）、包含、迭代和许多其他功能，并且还提供了一种专有的表示/逻辑分离方法，以及对数据提供者的控制反转（视图提取他们需要显示的信息，而不是让控制器将数据推送到模板中，几乎每个模板引擎都是如此）。这使得 HTML 设计师可以真正决定他想要呈现什么以及何时以及如何呈现，而不会有任何破坏代码的风险。

我很乐意得到反馈和 cmets。谢谢

【讨论】：