Question

为什么我要在PHP中使用模板系统？

我的问题背后的原因是：PHP本身是功能丰富的模板系统，我为什么要安装另一个模板引擎？

到目前为止我找到的唯一两位职业选手是：

更清晰的语法（有时）
模板引擎通常不够强大，无法实现业务逻辑，因此它会强制您分离关注点。使用PHP进行模板化可以引诱您绕过模板原理并再次开始编写代码汤。

......与缺点相比，两者都可以忽略不计。

小例子：

PHP

<h1><?=$title?></h1>
<ul>
  <? foreach ($items as $item) {?>
  <li><?=$item?></li>
  <? } ?>
</ul>

Smarty的

<h1>{$title}</h1>
<ul>
  {foreach item=item from=$items}
  <li>{$item}</li>
  {/foreach}
</ul>

我真的没有看到任何差异。

Answer 1

是的，正如你所说，如果你不强迫自己在PHP（模板引擎）中使用模板引擎，那么就很容易滑倒并停止分离问题。

然而，那些在分离问题时遇到问题的人最终会生成HTML并将其提供给Smarty，或者在Smarty中执行PHP代码，因此Smarty很难解决您关注的问题。

另见：

Answer 2

人们使用模板系统的主要原因是将逻辑与表示分开。这有几个好处。

首先，您可以将模板交给网页设计师，他们可以随意移动内容，而无需担心保持代码流。他们不需要理解PHP，只是为了知道单独留下特殊标签。他们可能需要为一些标签学习一些简单的语义，但这比学习整个语言简单得多。

此外，通过将页面拆分为单独的文件，程序员和设计人员可以同时处理同一个“页面”，在需要时检入源代码控制，而不会发生冲突。设计人员可以针对稳定版本的代码测试他们的模板视觉效果，而程序员正在针对他们自己的副本进行其他可能的重大更改。但是，如果这些人都在编辑同一个文件并且必须合并不同的更改，那么您可能会遇到问题。

它还强制执行良好的编程实践，使业务逻辑远离表示逻辑。如果您将业务逻辑与演示文稿混合在一起，那么如果您需要稍后以不同方式呈现它，则更难以提取它。如今，Web应用程序中不同的呈现模式越来越受欢迎：RSS / ATOM提要，JSON或AJAX响应，手持设备的WML等。使用模板系统，这些通常可以完全使用模板完成，不需要或几乎不做任何改动其他

然而，并非所有人都需要或欣赏这些好处。 PHP相对于Java / Python / Ruby /等的优势在于，您可以快速破解其中包含一些逻辑的网页，这一切都很好。

Answer 3

以分离逻辑为借口使用非PHP模板是无稽之谈。如果开发人员不了解业务视图逻辑分离是什么以及应该如何完成，那么必须适当地解决问题。否则，您最终会在业务逻辑中使用HTML或在模板中使用业务逻辑 - 没有模板引擎会为您节省开支。你必须向开发人员讲授基础知识。

如果开发人员明白这一点，那么模板系统只是一个限制。它不会将任何值添加到开发过程中，只会增加学习新语法，使另一个库保持最新以及执行速度较慢的开销。虽然后者可以通过缓存和诸如此类的方法来解决，但这只能解决原本不存在的问题。因此，模板系统没有任何价值，也没有任何优势。

但有一个例外，我认为使用非PHP模板系统是合理的：当视图逻辑程序员必须具有对模板的有限访问权限时。例如，如果您是博客托管系统的提供商，并且您希望允许您的用户对其模板进行个性化和编码，而不允许他们执行任意代码。但是，这个论点不适用于设计师愿意学习一些代码来帮助编程UI的情况。如果他可以学习Smarty，他可以肯定学习PHP。

Answer 4

模板系统仍然有充分的理由使用，但不是Smarty，而是PHPTAL。 PHPTAL模板是有效的XML（以及XHTML）文件。您可以在PHPTAL中进一步使用虚拟内容，从而获得具有最终外观的有效XHTML文件，可以使用标准工具进行处理和测试。这是一个小例子：

<table>
  <thead>
    <tr>
      <th>First Name</th>
      <th>Last Name</th>
      <th>Age</th>
    </tr>
  </thead>
  <tbody>
    <tr tal:repeat="users user">
      <td tal:content="user/first_name">Max</td>
      <td tal:content="user/last_name">Mustermann</td>
      <td tal:content="user/age">29</td>
    </tr>
  </tbody>
</table>

PHPTAL模板引擎将自动插入来自users数组的所有值并替换我们的虚拟值。尽管如此，该表已经是有效的XHTML，可以在您选择的浏览器中显示。

Answer 5

对我来说，模板引擎的一大特色就是缓存层对你来说是透明的。我很久以前就一直在使用smarty，缓存的东西让生活更轻松。智能设计也允许您使用自己的缓存功能。在我的情况下，我选择是否某些页面应该使用memcache或磁盘来存储模板输出。

另一方面，如果你的网站流量很大而且你不知道如何管理聪明并调整它，那么任何模板引擎都可能成为网站杀手。但即使不使用smarty，您的网站也会死亡。

flickr目前正在使用smarty。它不应该太糟糕，不是吗？

Answer 6

PHP 几乎是一个模板系统。关键是强迫自己将逻辑与演示分开。使用Smarty或类似的东西只会使混合逻辑和表示稍微不方便。如果你不能让自己独立，使用模板系统是没有用的。它所要做的只是消耗额外的处理能力。

关键是不要改变演示代码中的任何值。要做到这一点，我认为如果你使用if / endif语法，PHP本身就像Smarty一样有效：

<?php if($some_test): ?>
   <em>Some text!</em>
<?php endif; ?>

Answer 7

大多数情况下，我认为要避免在模板中应用任何“不安全”的后端逻辑。由于大多数时候模板都交给了设计师，我们只想给他们一套封闭的东西。

Answer 8

我喜欢从任何PHP文件中轻松显示任何模板的能力（并包含彼此之间的模板片段，用于常用元素，如导航栏）。例如，假设您有一个页面，如果您已登录，通常会打印一些信息，如果您没有，则会出现错误。使用PHP，您可以编写如下内容：

if (loggedIn)
{
    // print lots of HTML here
}
else
{
    // print error message
}

在Smarty中，它可能是这样的（原谅我可能错误的语法，已经有一段时间了）：

if (loggedIn)
{
    $smarty->bind("info", someObject);
    $smarty->display("info.template");
}
else
    $smarty->display("error.template");

如果你真的很聪明，你甚至可以显示登录页面模板而不是错误模板，可选择显示一条消息，解释用户为什么会在那里结束。如果你按照我写的技术去了，然后决定你想切换到显示登录框，那么它只需要改变一行！对我来说，这不仅仅是保持视图和逻辑的分离，而是关于从许多地方重用视图的常见元素的能力。

Answer 9

我很高兴使用像代码点火器这样的MVC框架。我发现在'views'中我倾向于坚持只与值的显示方式相关的php代码。我有一个格式化函数库，我可以在视图中使用该效果。代码点火器的一个前提是避免使用模板语言，因为它可以限制你的速度和减速。

我发现设计师学习一些PHP会更好，这样他们就可以实现他们需要做的事情，例如。交替的班级名称。它还将使它们在长期内更有用，并且从一种语法到另一种语法并不是一个巨大的飞跃。

Answer 10

你忘记了htmlspecialchars()两次。这就是你需要模板系统的原因。

Smarty很穷。不要根据它来判断模板系统。

Answer 11

当您为其他人编写代码时。例如，我曾经参与创建一个严格的Web应用程序框架，该框架应该可以为我们的客户定制。一个重要的要求是客户可以聘请设计师修改模板，而必须能够编程。更重要的是，他可能不会授权来更改代码。

例如，Smarty允许对模板可能执行的操作实施非常严格的限制。基本上，我们的应用程序禁用了除最基本的代码构造和一组选定的修饰函数之外的所有代码。因此，模板引擎有两个目标：简单和安全。

Answer 12

有些人可能认为Smarty已经完成了PHP可以做的事情：将表示与业务逻辑分开。 PHP编程语言非常适合代码开发，但是当与HTML混合使用时，PHP语句的语法可能很难管理。 Smarty通过使用更简单的基于标签的语法将PHP与演示文稿隔离来弥补这一点。标签显示应用程序内容，强制与PHP（应用程序）代码完全分离。管理Smarty模板不需要PHP知识。

这种分离的重要性是情境性的。对于Web设计人员而言，这通常比PHP开发人员更重要。因此，当开发人员和设计人员的角色分离时，Smarty通常是一个很好的选择。没有正确或错误的答案：每个开发团队都有自己的管理代码和模板的首选项。除了基于标签的干净语法之外，Smarty还提供了各种管理演示文稿的工具：粒度数据缓存，模板继承和功能沙盒等等。业务需求和Smarty正在使用的PHP代码将在确定Smarty是否适合的过程中发挥重要作用。

Answer 13

让我们不要忘记未来。网站几乎在发布时就已经过时了。您需要在某些时候更新外观。如果你经常保持分离，那么设计师就可以在后端用相同的编程完成一个全新的网站。这样可以实现更快，更便宜的重新设计，如果需要新功能，只允许程序员参与。

Answer 14

您想使用包含PHP代码的文件作为模板吗？细。
您想在所述模板中使用您的变量吗？细。

请记住将逻辑和最终输出（表示）分开。使用模板框架可以更好地完成此操作。但你不必学习像Smarty这样的东西。

如果你使用Zend_View或类似的东西，你可以一直使用PHP代码。

这里的很多人都有正确的答复。 Smarty在PHP中没有模板化。离得很远。 Smarty主要面向那些必须使用设计师（即非程序员）来编辑和设置页面显示的人。如果每个要改变页面布局的人都可以编程，那么你可以选择更加面向PHP代码的模板系统。但是你真的应该准备好所有输出数据并将其发送到模板。如果你让每个页面获取，处理和显示内容，你必须尽快重构它。

Answer 15

我认为更清晰的语法是一个很大的胜利。虽然它可能看起来只有几个字符，但是当你每天都这样做时，每个字符都会开始计算。

而且{$myvar|escape}恕我直言的时间比<?php echo htmlspecialchars($myvar); ?>短得多。（请记住<?=$foo?>语法仅在PHP conf中特别启用时才可用。）

Answer 16

我没有看到的一个模板引擎优势是动态html元素的可能性 - 类似于asp.net控件。例如，使用PEAR的HTML Template Flexy，您可以拥有自动维护状态的动态表单元素。可以填充常规html选择元素，并在代码中设置所选项目，而不在模板中使用循环或条件。

Answer 17

我认为你不应该使用模板引擎。相反，你应该使用类似Zend_View的东西来鼓励你从演示中做单独的逻辑，但允许你用PHP构建你的表示层。

Answer 18

您的分析是合理的。我想：

模板设计师和后端程序员可能不是同一个，因此它促进了分离。
它可以保护你自己，因为你不能在你的模板中真正做“太多”的PHP。
在某些情况下，优化/预编译模板可能更容易吗？（这是推测）

就个人而言，我认为他们比他们的价值更麻烦。特别是如果你想交手，它们就不起作用了 “设计师”的模板，因为WYSIWYG工具不知道如何处理它们。

Answer 19

我敢打赌，如果一个PHP模板语言如此强制以至于迫使你使用它，你根本就不会使用它。在遇到麻烦时“跳出”并按照自己的方式行事的能力是PHP的吸引力之一。

我不是说这是一件好事，也不是说代码是可维护的，只是在最初的考虑中，我不会选择一种完全阻止我的模板语言。

否则，我同意模板系统可以帮助您在编码和设计之间划分工作，并可能让设计师为我们设计和编码。

Answer 20

我个人总是在php，python或其他任何地方使用模板引擎。

其他人已经提到的第一个显而易见的原因：

它迫使您不在模板中使用任何业务逻辑。

是的，当你拥有它时，纪律会很好。

但这只是只是你使用模板引擎的一小部分。无论你喜欢与否，它们中的大多数都不仅仅是一个引擎，而且可以被认为是模板框架。

例如，Smarty还具有高级缓存功能，如部分缓存。非常有用的东西，当你只使用php作为模板语言时，你会自己做的事情。

请不要忘记所有那些真正有用的帮助函数，只需在文档中快速搜索即可。其中大多数还提供了一种简单的方法来插入自己的功能和/或工具包。

所以是的，这是一个选择问题。当需要非常简单的模板时，请考虑显示一些规则，使您的逻辑远离模板。但是当您希望应用程序增长时，您最终将需要模板框架的功能。到那时，你希望不要通过编码全部来重新发明轮子。

最后但并非最不重要的是，对我来说，在一些模板框架中有一个杀手级功能。

模板继承

我从Django开始了解它，我现在正在最新的Smarty 3中使用它。来自Symphony框架的人员也有Twig，您可以将其视为具有Django语法的端口。

起初看起来有点奇怪，但是非常强大。您构建骨架并定义各种块。您可以扩展此类骨架并使用您的内容填充（覆盖）块。

对我而言，这是一个守门人！

Answer 21

模板管理系统，我们可以单独管理模板文件。系统执行时间将比正常的PHP项目快。所以这里分别维护PHP文件和模板文件。

一旦运行文件，代码将被保存为template_c。所以它不能多次编译。

Answer 22

我好几次使用tinybutstrong，它有一个非常简洁的语法。 html模板中没有循环或伪代码。

从他们的主页：

TinyButStrong是一个可以动态创建的库   XML / HTML页面和基于文本源的任何其他文件。它是   PHP语言的模板引擎。它使您可以轻松显示   来自您的数据库的信息，但也要认真协调和   简化您的PHP编程。

TinyButStrong面向HTML，但不专门针对Html。这个   意味着它可以与文本文件，XML，RSS，RTF，WML，Excel一起使用   （xml），... OpenTBS插件使您能够合并OpenOffice和Ms   办公文件。

Answer 23

大量使用OOP概念的开发人员，如JAVA / Spring / Oracle PL-SQL人员，他们说PHP语言本身用于企业级项目中的表示/视图/显示逻辑。在这些BIG项目中，后端是Oracle，数据库是使用pl-slq / java获取的，演示文稿是php。最好的例子是facebook。http://en.wikipedia.org/wiki/Facebook facebook使用php进行演示，使用java / c ++作为后端界面。

php被用作演示文稿的唯一原因是因为它与HTML密切配合，但java / c ++更多是基于OOP的，不能直接适用于HTML。告诉我一个使用Smarty的CMS（joomla / drupal / wordpress）或框架（zend / symfony / Yii）？那么为什么需要聪明才能？

Answer 24

总结一下，我添加了一些想法。如果可能，我们应该使用模板系统：

缓存和代码压缩
提供一些安全层（如何显示变量）
模板继承和代码html的重新生成（允许避免重复的代码）
编写自己的插件/模块以改善编写视图的能力
“照顾”翻译问题并将此问题转移到视图层（在Smarty中，没有内置模块，但是有很好的社区解决方案）

Answer 25

我喜欢使用模板有几个原因：

1）它清除了PHP代码的可读性。当存在带有大量HTML的print（＆＃34;＆＃34;）语句时，我的PHP文件变得臃肿和不正常。此外，问题就像你如何将变量传递到HTML文本？你到处都用标签吗？您是否使用print（＆＃34;＆＃34;）并转义HTML引号并连接变量？你是否使用print（＆＃34;＆＃34;）并在HTML中使用单引号，违反标准，并直接插入变量？

2）它清理HTML代码的表示。如果生成的HTML在多个文件中被剪切和破解，则很难保持生成的HTML看起来很好。例如，你的缩进可能会消失。

3）它允许您创建多个模板，然后登录用户可以选择在浏览您的网站时要显示的模板/皮肤，并且您还可以快速，轻松地将默认模板更改为其他模板。＃39;如此倾向。

总的来说，它只是组织一切的更好方式。在学习和输入模板类命令，打开多个文件等方面有一些权衡取舍。但在我看来，我觉得这是值得的，因为代码的可读性和组织性都在提高。

我为什么要在PHP中使用模板系统？

25 个答案: