PHP vs 模板引擎

Question

我目前正在讨论在PHP作为模板引擎与在PHP之上使用另一种模板引擎之间的选择。

您的选择是什么，为什么？

我的观点是，既然PHP本身就是一种模板引擎，那么为什么还要使用另一种模板引擎呢。

- Ikke

---

提供的链接错误（页面未找到）。 - nowox

模板引擎编译成本地的 PHP，因此使用模板引擎没有任何损失，而有很多收益。如果您查看任何现代模板引擎，如 Smarty 或 Twig，您将看到它们将模板编译为源 PHP，因此输出与手动在 PHP 中制作页面相同。但是，模板引擎知道如何更好地编译 PHP 页面，因为模板引擎由数千人维护。 - Patrick W. McMahon

如果您习惯使用模板引擎，那么使用纯PHP构建模板/视图将会很繁琐，并且难以阅读。然而，正确的答案是完全跳过php模板引擎，直接使用KnockoutJS或AngularJS来创建模板，并为所有内容使用AJAX。祝玩得愉快！ - Andrew

Answer 1

对于模板引擎：

1. 增加了终端用户自定义的安全性。使用纯PHP的主题有可能会对用户及其安装造成伤害，因此良好的模板引擎可以消除这种风险。
2. 易于非编程人员使用，例如图形艺术家或网页设计师。

对于纯PHP：

1. 纯PHP的速度是任何基于其构建的模板引擎所无法匹敌的。
2. 完整的 PHP 功能可用于输出，而不仅仅是解释或筛选的一部分。

如果可能，我更喜欢使用 PHP 本身。大多数人不想通过制作自定义主题来入侵你的软件，因此很容易进行初步阅读并调查其安全性。话虽如此，我是一个“过渡”人员，既做模板设计又从事编程，甚至还涉及一些平面艺术；我的技能与严格的程序员和艺术/设计人员不同。

- Robert K

Answer 2

我发现当我引入Smarty时，很容易让网页设计师使用smarty变量来生成HTML。现在编程团队的人们更专注于后端工作，也就是生产Smarty变量的内容。

这缩短了开发周期，使工作可以分配给更多人，最终导致更好的设计。

- stuart

---

谢谢您提供明智并着眼于 Smarty 真正的好处的回答。这不仅仅是更多或更好的功能，它还有助于促进良好的实践！ - Nicole

好的应用程序架构和良好的设计实践是无可匹敌的。模板引擎提供较慢的输出，并需要学习另一种“语言”。我们不应该让任何数据作为无效数据传递给视图，在将数据传递给视图之前，应该对所有数据进行准备。我真的不明白这些引擎上的大惊小怪是什么。它只是又一个包装器，会减慢输出速度。模板引擎语法和 PHP 语法之间没有太大区别。此外，UI 开发人员也将处理 JavaScript 代码，因此我不明白为什么 UI 开发人员应该远离 PHP。这只是控制反转。 - Tudor

@NickC，模板化的缺点在于您需要先通过所有业务逻辑然后再做输出。没有办法即时输出。 - Pacerier

@Pacerier 我不清楚那是一个什么样的劣势。我很难想象实时输出有任何好处。 - Nicole

@NickC，有很多情况下这是个好主意。例如当你正在显示日志或者展示页面加载和数据检索的状态时。 - Pacerier

@Pacerier，我几乎总是通过预先创建业务逻辑函数并在模板系统中创建钩子来调用所需的函数。 - Nicole

Answer 3

嗯，这只是我的个人观点，但模板引擎很烂。你必须首先了解模板引擎的实现方式，然后再学习如何使用它。这似乎只是浪费时间，因为单独使用PHP可以更好地完成它，并提供更多的灵活性。

- rogeriopvl

---

你仍然有这种感觉吗？五年后还是一样吗？我需要做出一些决定。唯一不喜欢使用 PHP 的事情是有时很难正确使用大括号。 - johnny

@约翰尼，耗费你时间的不是学习语言本身，而是学习它的全部细节，包括各种陷阱、边缘案例等等。如果你不花时间将其完全掌握，最终仍会因为修复漏洞和安全问题而浪费时间。 - Pacerier

@johnny，和你一样，我也遇到了大括号匹配的问题（尽管其中有些原因是因为视力不好）。为了帮助解决这个问题，我使用了替代语法。这对我帮助很大。http://php.net/manual/zh/control-structures.alternative-syntax.php - Wranorn

我最终使用了普通的旧版PHP，至今没有发现不使用它的理由。只要是用于呈现页面，那么使用什么语言有何关系呢？ - johnny

@johnny 只需使用一个集成开发环境。 - Mārtiņš Briedis

Answer 4

以下原因适用于使用引擎将您的应用程序分离成模板:

• 使用引擎将应用程序分离成模板可以使您的应用程序更少容易受到停止代码错误的影响。
• 使用模板可以在未来重构时提供更大的灵活性，因为命名空间不会直接构建到应用程序中。
• 使用模板鼓励（强制）开发人员将业务逻辑和代码从表示层中移出。
• 使用模板更容易模拟数据集并将其传递给模板引擎，并获得具有数据的站点预览。

- cgp

---

是的，理想情况下程序员不需要关心他们有一个简化的模板，对吧？我的意思是，我们完全理解 PHP，为什么还需要一个仅对非编码人员有用的精简部分呢？ --- 实际上，当您需要处理 SQL、PHP、HTML、CSS 和 JS 栈时，在您的 PHP 中具有 HTML 的冗长和复杂性是一个主要劣势，让您减慢速度，并且也允许显示逻辑的非分离。最终，使用模板几乎总是正确的选择。 - Kzqai

如果您从一开始就正确设计应用程序，就不会存在这些问题。即使您不使用模板引擎，也应该将业务逻辑和展示逻辑分开。基本上，您只需要一个可以将控制器范围内的变量传递到视图范围内的调度程序即可。 - Gladen

Answer 5

PHP并不是一个模板引擎，而是一种可以用来编写模板或模板引擎的语言。模板引擎不仅仅是一种语言，还包括编程API，允许脚本定位、组织模板或将数据从脚本分配给它们。单纯的PHP并没有什么特殊的功能- 它只是一种语言。相反，您应该使用那些库，如Zend Framework中的Zend_View进行比较（基本上，它的工作方式与Smarty完全相同，只是它使用PHP编写模板）。您应该考虑使用PHP或其他模板语言。

说到模板语言本身，普通的循环和条件语句足以编写模板，但这个“足够”并不意味着它易于操作、舒适、高效或灵活。PHP对于模板设计师来说并没有提供任何特别的东西，但是许多“模板语言”（如Smarty）仅提供PHP的有限子集，因此我并不奇怪程序员选择PHP作为模板引擎。至少他们可以编写函数并使用OOP，这对于模板设计可能过于庞大（在我看来），但确实有效并真正有帮助。

关键是自定义模板语言并不受PHP缺点的限制，但其设计者通常无法看到这一点，声称“显示变量和循环就足够了”。模板语言可以更加有效的地方包括：

• 表单显示和渲染（我还没有看到任何使用PHP作为模板语言的框架提供易于定制表单外观的灵活通用系统）。
• 理解HTML/XML文档结构。
• 自动XSS注入过滤器。
• 解决表示层中的各种常见问题（例如：自定义分页系统的外观、在列中显示数据等）。
• 模板可移植性和应用逻辑与实现细节之间的真正分离。

遵循这种方式的模板语言的示例包括上面提到的PHPTAL和Open Power Template 2。一些类似的想法也可以在TinyButStrong中找到，但不幸的是，这个模板引擎非常缓慢。

- Zyx

---

需要防止XSS攻击，对于每个变量都使用<?php echo htmlentities($name, ENT_QUOTES, 'UTF-8');?>虽然很糟糕，但几乎是必要的。即使使用包装函数<?php h($name);?>也不如{{name}}易读和易扫描。 - Kzqai

@Zyx，PHP是一种可以做与模板引擎相同的事情的语言。它是可用作模板引擎的工具，换句话说，它本身就是一个模板引擎。 - Pacerier

Answer 6

如果您有一个非程序员负责模板，使用模板引擎可能会很有帮助。在许多情况下，简化的模板语言比 PHP 本身更容易被非程序员掌握。

尽管如此, 当只有我（或我和其他开发人员）时，我发现自己不再使用模板。

- Mark Biek

Answer 7

作为模板引擎，PHP不会因为混淆HTML语法而抱怨。它允许您忘记关闭标签、错误嵌套等问题。

PHP的输出默认情况下不会转义，所以除非您严格添加htmlspecialchars()，否则您的网站将存在HTML注入（XSS）漏洞。

<p>Hello <?= $name ?></b>
<!-- Simple template full of errors -->

当您尝试生成XHTML properly时，这些问题会变得更加严重。当然，您可以使用普通的PHP来实现，但那需要更多的努力和勤奋。

因此，我的建议是使用PHPTAL。OPT2也可以。

- Kornel

Answer 8

PHP非常适合大多数任务，但模板引擎可以帮助项目更轻松地扩展。

像Smarty或PHPTAL这样的现成工具非常适合那些没有时间自己开发（并且不需要更多功能）的人使用。此外，如果您发现需要更专业化的功能，您也可以相当容易地用自己的实现来替换/修改它们。

我个人对PHPTAL有较好的体验，主要是因为它简单而不会干扰你的其他工作。

- seanhodges

Answer 9

Savant是您所寻找的。它是一个很好的包装类，允许您在模板中使用PHP运算符，而不是在PHP之上解释新的模板语言。

优点： - 不给系统增加额外的工作是有意义的。 - 对于开发人员来说没有学习曲线 - 如果每个人都有纪律性，那么这是可行的。（Savant）

缺点： - 尽管Savant鼓励您正确地分离业务逻辑和开发代码，但它并不强制开发人员这样做。我有一个永远不能被打破的规则。您只能在模板中输出变量、使用条件和循环。绝不能允许开发人员在模板中创建变量。不幸的是，无论您告诉他们多少次，开发人员似乎从未这样做。因此，使用像Smarty这样的引擎变得更有价值，因为开发人员被迫完全将业务和设计分开。

如果我为自己或只有少数开发人员的项目工作，我倾向于使用Savant。如果这是一个比我更大的项目，那么在架构方面我会选择像Smarty这样的东西。

无论您使用Savant还是Smarty，代码中的分离都很重要。我相信还有其他好的选择。

- Derek Organ

Answer 10

以下文章总结了关于PHP模板引擎的不同观点。 做第三类PHP模板 http://www.tinybutstrong.com/article_3rd_kind.html

- Skrol29

---

所见即所得... 真的吗？这是倒退了吗？ - Pacerier

所见即所得已经无处不在，以至于不再被提及。然而，仍有一些设计工具不是所见即所得的。特别是对于HTML页面：50%的开发人员使用可视化设计编辑器（所见即所得），而另外50%的开发人员则更喜欢文本编辑器（非所见即所得）。 - Skrol29