何时使用PHP模板引擎

Question

何时使用PHP模板引擎

phptemplatestemplate-engine

24

我正在用PHP构建一个包含许多页面的网站，我们是一个由9人组成的团队。因此，我想探讨一下何时应该使用PHP模板引擎以及何时不应该使用。因此，我对使用PHP模板引擎的优缺点感兴趣，这样我就可以决定是否在我的情况下使用它。

- GG.

10个回答

11

对于我来说，是否应该使用单独的模板引擎还是仅使用PHP进行模板设计，这始终归结为以下几点：

何时使用模板引擎

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

何时不使用模板引擎

所有其他情况下都不使用模板引擎。

- webbiedave

2

这正是为什么Smarty在这里有一份兼职工作的原因（唯一的原因）。我们需要考虑安全性和可读性来运行来自数据库的动态内容。我们使用一些小令牌，客户将其复制/粘贴到所见即所得编辑器中，然后由Smarty解析，例如{date}和{article_stub id="34"}。如果有人知道更好的方法，请告诉我。 - Wesley Murch

6

PHP的纯粹主义者会告诉你，PHP本身就是一个模板引擎。在这个问题上，我自认为是个纯粹主义者，建议只使用PHP。它甚至有一种备选语法用于if和loop块，这些块几乎是为了模板风格的可读性而设计的。

然而，有些人仍然喜欢使用模板引擎，比如Smarty。如果您选择这条路，有几个问题需要考虑：

谁将维护模板？ 如果负责维护模板的人已经知道PHP，那么让他们学习一个新的伪PHP模板引擎就没有意义。如果他们不知道PHP，那么这仍然值得怀疑，这取决于他们的背景，因为大多数模板引擎只实现了类似于PHP标记的语法（如<% %>）

您的模板会变得多么复杂？ 有些模板引擎在模板中可以做的事情非常受限制（强制您将所有内容都放在控制器中，某些甚至到了毫无用处或不必要的程度），而其他引擎则与原始PHP一样自由（许多人会认为这是模板引擎的目的所在）。

效率和速度有多重要？ 模板引擎会增加开销。毫无疑问。将自定义标记转换为PHP标记需要资源。它们增加了多少以及它们的重要性取决于许多因素（包括引擎本身）。如果您需要更快速的站点，则我建议将模板引擎列为首要去除的内容之一。

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

- Shauna

2

将自定义标签转换为PHP标签需要资源 - 大多数模板系统都具有（或应该具有）良好的缓存功能。Smarty编译成纯php。 - Wesley Murch

首先，编译模板需要消耗资源，而且当模板更新时也需要重新编译。 - Shauna

3

没问题，但这几乎可以忽略不计，因为每次编辑仅发生一次。然而，查找和读取缓存将增加开销，但不会真正转换标签为php（创建缓存文件）。 - Wesley Murch

好的。现在有一个问题 - 所有模板引擎都会缓存编译的模板吗？人们可能会认为会这样做，但是理论上，理论和实践是一样的... - Shauna

@Wesley Murch，首先：使用缓存会使增加可用的RAM成为必要。其次：如果我们必须学习模板引擎语言才能使用它们，为什么不花时间学习PHP的基础知识呢？理解echo、foreach和if的工作原理并不难。这些构造在模板引擎中也不比在PHP中更难。 - OZ_

@OZ，请注意我在原始评论中引用的部分并阅读我的第二条评论。我并不是说使用模板系统需要更少的资源，只是指出通常你不会即时解析标签。我既不主张使用模板引擎，也不反对它。就语法而言，我同意PHP对于基本用法来说并不难学，但对于大多数人来说，阅读模板代码要干净得多。这取决于情况，我知道当那些不会编程的人看到<?php echo $user->name; ?>时，他们知道不要碰它，但如果他们看到{username}，他们可能不知道它的含义。 - Wesley Murch

3

没有必要使用PHP模板引擎。逻辑和视图的分离是义务，但这并不意味着使用模板引擎。使用模板引擎需要学习与PHP或其他任何东西都无关的东西。每个需要修改smarty或其他模板源代码的人都可能对那些无用且妨碍工作的废话感到恼火。 PHP使您的模板实现所有可能性，并在使用中提供各种优势。遵循一打安全建议足以保障PHP的安全。如果不了解背后的技巧，请勿使用模板引擎来保护自己。Smarty 不能保证可供公开编辑的模板的安全性。寻找设计模式、视图助手和MVC。简单高效地组织代码比任何模板引擎更加智能。

- dbl

2

我建议使用一些良好的分离方法来使你的显示逻辑与其他数据获取处理分离。实施MVC是一个很好的方法，大多数PHP框架提供了MVC框架。

这样可以让每个人都能够编写更加整洁的代码，并且保持模板简单，以便那些不太懂技术的人（例如前端设计师）能够进去进行编辑。

- James C

2

当多个网页上存在大量相同的展示内容且您希望将业务逻辑和应用程序编程与展示分离时，应使用模板引擎。

此种分离的好处有：

1. 更紧密、更易读且无错误的应用程序逻辑 2. 可在不更改核心逻辑文件的情况下更改展示 3. 可在运行时动态更改展示

虽然技术上PHP本身就是一种模板语言，但更准确的描述是它是一种带有内置模板的Web编程语言。另一方面，大多数模板引擎会包含编程指令。这意味着在PHP中模板和编程之间需要保持合理的平衡。平衡得越好，编码就越容易，应用程序也就越灵活可扩展。

例如，当PHP代码检索最近10篇博客文章并在博客页面上将它们写入DIV标签时，如果该代码被复制以创建RSS订阅，那么相同的代码将出现在两个地方，并需要在逻辑更改时在多个地方进行维护。

而如果使用模板引擎控制相同的代码，则可以根据提供的RSS / XML或HTML模板将相同的代码写入两种不同的输出形式中。如果模板引擎编写得好，则PHP代码既不知道也不关心提供给它的模板类型。PHP同样可以输出HTML、XML、SQL、PDF或文本！

在多年的Classic ASP和PHP网站开发中，我发现一个好的模板引擎可以节省我很多时间来进行编程和调试。由于Classic ASP没有真正的模板引擎，因此我编写了KudzuASP来解决这个问题。您可以在我的网站上找到相关的项目KudzuPHP，并且它是免费的。还有一个基于它的WordPress插件。

- Andrew

1

虽然技术上来说，php本身就是一种模板语言，但更准确的描述应该是它是一种具有内置模板功能的Web编程语言。我认为这种说法介于两者之间。它最初的存在是为了解决类似于模板所解决的问题，后来变得更加强大。 - Nick Manning

1

对于模板引擎，我建议您只使用php。不需要像smarty这样的额外负担。他们只需要了解基本的php即可。您可以使用.phtml文件扩展名来表示模板文件...为什么要使用模板引擎呢？

明确一点，.phtml模板文件中只应包含echos和foreachs，不应在其中执行任何核心代码。

- Jim

9个人一起处理一堆混合了代码和标记的.phtml文件，这简直是灾难的开始。 - David Fells

2

那跟9个人一起处理Smarty模板有什么不同呢？真正的目标是制定一套模板标准。应该包含什么内容，标记看起来如何等等。如果没有制定和遵守标准，任何东西都可能变成垃圾。 - Jim

@David - 在一个.phtml文件中编写代码的9个人等同于需要学习逻辑和表现分离的9个人。在一个.phtml文件中，您需要使用echo来输出信息并使用foreach来进行迭代以达到输出的目的。 - Bogdan Constantinescu

@David，我明白你的意思了。我想我的回答有点含糊不清，现在我来澄清一下。我的意思是你应该将PHP作为模板引擎，并将实际的“模板”标记存储在.phtml文件中。我并不是指在模板标记中包含所有的代码等内容。 - Jim

1

你应该总是使用一些机制来将标记语言与代码分离，就像你不应该在HTML中嵌入CSS一样。有太多的选项可以给你一个扁平的答案。有像smarty或fasttemplate这样的模板引擎，还有带有模板系统的框架（如cake、code igniter等）。你应该根据自己的需求对它们进行个别评估。

- David Fells

0

事实上，这里的关键词是分离和重用。

在团队中开发和分段工作负载的最佳方式是，当Web设计师（集成器/HTML专家等）没有机会破坏编程部分（数据库、文件、会话、语法错误等）时。

我建议使用FigDice模板引擎，它在逻辑（程序、数据库、文件、算法等）和演示（视图和它们呈现的信息）之间进行非常干净的分离，确保总体安全。

FigDice当然支持宏（文件的可重用部分）、包含、迭代等许多功能，并且还提供了一种独特的演示/逻辑分离方法，通过数据提供者的控制反转（视图拉取它们需要显示的信息，而不是让控制器将数据推入模板中，这通常是几乎所有模板引擎的情况）。

这使得HTML设计师真正能够决定他想要何时以及如何呈现，而不会有任何破坏代码的风险。

我很乐意收到反馈和评论。谢谢

- Gabriel

0

你尝试过Stamp Template Engine吗？

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

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

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

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

我觉得这真的很酷。

http://www.stampte.com

- Gabor de Mooij

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Bogdan Constantinescu · Accepted Answer

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