为什么我应该在PHP中使用模板系统？
为什么我应该在PHP中使用模板系统？
我的问题背后的原因是：PHP本身是function丰富的模板系统，为什么我应该安装另一个模板引擎？
到目前为止，我发现的唯一两个专业人员是：
- 有点干净的语法（有时）
- 模板引擎通常不够强大，无法实现业务逻辑，因此迫使您将问题分离出来。 使用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>
我真的没有看到任何区别。
是的，正如你所说的，如果你不强迫自己在PHP（模板引擎）中使用模板引擎，就很容易滑倒和停止分离问题。
然而 ，分离问题的同样的人最终会产生HTML并将其提供给smarty，或者在Smarty中执行PHP代码，所以Smarty几乎不能解决您关心的分离问题。
也可以看看：
- PHP作为模板语言或其他模板脚本
- 什么是通过PHP插入HTML的最佳方式
人们使用模板系统的主要原因是将逻辑与表示分开。 这有几个好处。
首先，您可以将一个模板交给一个网页devise师，他们可以根据需要移动它们，而不用担心保持代码的stream动。 他们不需要了解PHP，只需要知道离开特殊的标签。 他们可能不得不为几个标签学习一些简单的语义，但这比学习整个语言要简单得多。
另外，通过将页面分割成单独的文件，程序员和devise者可以同时在同一个“页面”上工作，根据需要签入源代码控制，而不会发生冲突。 devise人员可以在程序员对自己的副本进行其他潜在的破坏性更改的情况下，对照稳定版本的代码testing其模板视觉效果。 但是，如果这些人都在编辑同一个文件，并且需要在不同的变化中进行合并，则可能会遇到问题。
它还执行良好的编程实践，使业务逻辑远离表示逻辑。 如果您将业务逻辑与演示文稿混合在一起，那么如果稍后需要以不同的方式呈现，那么解压缩该文件将会更加困难。 Web应用程序中的不同表示方式越来越受欢迎：RSS / ATOM提要，JSON或AJAX响应，手持设备的WML等。对于模板系统，这些模板通常可以完全用模板完成，对任何内容都没有或几乎没有变化其他。
不是每个人都需要或欣赏这些好处。 PHP比Java / Python / Ruby /等更具优势，你可以用一些逻辑来快速破解网页，这一切都很好。
以分离逻辑为借口使用非PHP模板是无稽之谈。 如果开发人员不了解业务逻辑分离是什么以及如何完成，那么这个问题必须得到适当的解决。 否则，最终将在模板中使用业务逻辑或业务逻辑中的HTML – 模板引擎不会为您节省。 你必须教导开发者的基本知识。
如果开发者明白，模板系统只是一个限制。 它不会为开发过程增加任何价值 ，只会学习新的语法，保持另一个库保持最新，以及执行速度较慢。 虽然后者可以通过caching来解决，但这只能解决一个不存在的问题。 所以，模板系统没有价值，根本没有优势。
但是，有一个例外，我认为使用非PHP模板系统是合理的：当视图逻辑程序员必须对模板进行有限的访问时。 例如，如果您是博客托pipe系统的提供者，并且希望允许用户对其模板进行个性化和编码，而不允许他们执行任意代码。 然而，这个论点并不适用于devise者愿意学习一些代码来帮助编程UI的情况。 如果他可以学习Smarty，他肯定可以学习PHP。
模板系统还有一个很好的理由，但不是Smarty，而是PHPTAL 。 PHPTAL模板是有效的XML（因此是XHTML）文件。 您可以进一步在PHPTAL中使用虚拟内容，因此可以获得最终外观的有效XHTML文件，这些文件可以使用标准工具进行处理和testing。 这是一个小例子：
<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模板引擎会自动插入用户数组中的所有值并replace我们的虚拟值。 尽pipe如此，该表已经是有效的XHTML，可以在您select的浏览器中显示。
对我来说，模板引擎的一大特色就是caching层对你来说是透明的。 我很久以前一直在使用smarty，而caching的东西让生活更轻松。 也聪明的devise允许你使用你自己的cachingfunction。 在我的情况下，我select如果某个页面应该使用memcache或磁盘来存储模板输出。
另一方面，如果你的网站stream量大，你不知道如何pipe理聪明和调整好这个任何模板引擎可能是一个网站杀手。 但即使不使用smarty您的网站也可能死亡。
flickr目前正在使用smarty。 它不应该太糟糕，不是吗？
PHP几乎是一个模板系统。 关键是强制自己将逻辑与演示分开。 使用Smarty或类似的东西，只会使混合逻辑和表示稍微不方便。 如果你不能自己把它们分开，那么使用模板系统是不会有帮助的。 它所要做的就是吃掉额外的处理能力。
关键是不要更改演示文稿代码中的任何值。 为了做到这一点，我认为如果你使用if / endif语法，PHP本身就和Smarty一样有效：
<?php if($some_test): ?> <em>Some text!</em> <?php endif; ?>
大多数情况下，我认为要避免在模板中应用任何“不安全”的后端逻辑。 由于大部分时间模板都交给devise师，所以我们只想给他们一套封闭的事情。
我喜欢从任何PHP文件中简单地显示任何模板的能力（并且包含模板的片段，对于像导航栏这样的常见元素）。 例如，假设您有一个页面，如果您已经login，通常会打印一些信息，如果不是，则会显示错误。 用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");
如果你真的很聪明，你甚至可以显示login页面模板而不是错误模板，也可以select显示一条消息，解释用户为什么会在这里结束。 如果你按照我写的技术去做，然后决定要切换到显示login框，这只是一个单一的行改变！ 对我来说，不仅仅是保持观点和逻辑的分离，而是关于从许多地方重用视图的常见元素的能力。
我很高兴使用像代码点火器的MVC框架。 我发现，在“观点”中，我倾向于坚持只涉及值如何显示的PHP代码。 我有一个格式函数库，我可以在视图中使用该效果。 代码点火器的一个前提是避免使用模板语言，因为它可以限制你的速度和减慢速度。
我发现devise者学习一些PHP更好，这样他们就可以实现他们需要做的事情。 交替的类名称。 这也将使它们在长期内更加有用，从语法到另一个语法并不是一个巨大的飞跃。
你忘了htmlspecialchars()两次。 这就是为什么你需要模板系统。
Smarty很穷。 不要根据这个来判断模板系统。
你的分析是合理的。 我想：
- 模板devise人员和后端程序员可能并不相同，所以它促进了分离。
- 它在某种程度上保护了你自己，因为你不能在你的模板中做太多的PHP。
- 在某些情况下优化/预编译模板可能更容易？ （这是猜测）
我个人认为他们比他们的价值更麻烦。 特别是他们不工作，如果你想把模板交给“devise师”，因为所见即所得的工具不知道如何处理他们。
我没有看到的一个模板引擎优势是dynamichtml元素的可能性 – 类似于asp.net控件。 例如，使用PEAR的HTML模板Flexy，您可以拥有自动维护状态的dynamic表单元素。 可以填充常规html select元素，并在代码后面设置所选项目，而不在模板中使用循环或条件。
我认为清晰的语法是一个很大的胜利。 虽然看起来只有几个字，但是当你每天都这样做的时候，每个angular色开始计数。
和{$myvar|escape}是比较短的<?php echo htmlspecialchars($myvar); ?> <?php echo htmlspecialchars($myvar); ?> 。 （请记住， <?=$foo?>语法只有在PHP conf中特别启用时才可用。
我不认为你应该使用模板引擎。 相反，你应该使用像Zend_View这样的东西鼓励你从演示文稿中做单独的逻辑，但是允许你用PHP构build你的表示层。
- 你想使用PHP代码的文件作为模板？ 精细。
- 你想在你的模板中使用你的variables？ 精细。
只记得分开逻辑和最终输出（演示文稿）。 使用模板框架可以更好地完成此操作。 但是你不必学习像Smarty这样的东西。
- 如果你使用Zend_View或类似的，你可以使用PHP代码。
这里有很多人有正确的答复。 Smarty在PHP中不是模板。 离得很远。 对于那些不得不使用devise人员（即非程序员）编辑和设置页面显示的人来说，Smarty大多是那里的。 如果每个人都想改变页面的布局，那么可以使用更多的PHP代码导向的模板系统。 但是你真的应该把所有的输出数据准备好并发送给模板。 如果你让每个页面获取，处理和显示内容，你将不得不在稍后重构它。
当你为别人写代码的时候。 例如，我曾经参与创build一个僵化的Web应用程序框架，应该为我们的客户定制。 一个重要的要求是，客户可以聘请devise师修改模板， 而不必编程。 更重要的是，他可能没有被授权更改代码。
例如，Smarty允许对模板可以做的事情实施相当严格的限制。 基本上，我们的应用程序禁用了除最基本的代码结构和一组选定的修改器function。 所以我们有两个目标，通过模板引擎得到很好的体现： 简单性和安全性 。
让我们不要忘记未来。 网站几乎是他们发布的时间。 您需要在某个时候更新外观。 如果你经常保持分离，那么devise师可以在后端用相同的编程完成一个全新的网站。 这允许更快速和更便宜的重新devise，只有在需要新function的情况下才允许程序员参与。
有人可能会争辩说，Smarty已经做了PHP可以做的事情：将演示文稿与业务逻辑分开。 PHP编程语言非常适合代码开发，但是当与HTML混合使用时，PHP语句的语法会变得很糟糕。 Smarty通过用简单得多的基于标签的语法来隔离PHP中的PHP来弥补这一点。 这些标签显示应用程序内容，强制从PHP（应用程序）代码执行干净的分离。 pipe理Smarty模板不需要PHP知识。
这种分离的重要性是情境的。 对于网页devise师来说，这通常比对PHP开发者更重要。 因此，当开发人员和devise师的angular色分离时，Smarty通常是非常合适的。 没有正确或错误的答案：每个开发团队都有自己的代码和模板pipe理select。 除了干净的基于标签的语法之外，Smarty还提供了多种工具来pipe理表示：粒度数据caching，模板inheritance和function沙箱等等。 业务要求和Smarty正在使用的PHP代码将在确定Smarty是否合适时起到重要作用。
我敢打赌，如果一个PHP模板语言如此强制性地强迫你使用它，你根本就不会使用它。 在遇到麻烦时，“跳出来”并按照自己的方式进行操作的能力是PHP的吸引力之一。
我不是说这是一件好事，也不是代码可以维护，只是在最初的考虑中，我不会select一种完全阻止我的模板语言。
否则，我同意模板系统帮助您在编码和devise之间划分工作，并可能让devise人员devise和编码给我们。
我个人总是使用模板引擎在PHP，Python或其他。
其他人已经提到的第一个明显的原因是：
这迫使您不要在模板中使用任何业务逻辑。
是的，当你拥有纪律的时候，纪律就会好起来。
但是这仅仅是为什么你会使用模板引擎的一个小方面 。 他们中的大多数不仅仅是一个引擎，可以被视为模板框架，无论你喜欢与否。
例如，Smarty也具有高级cachingfunction，如部分caching。 真正有用的东西，当你只使用PHP作为模板语言时，你可以自己动手做所有的事情。
请不要忘记所有这些真正有用的帮助function，只需在文档中快速search即可。 他们大多也提供了一个简单的方法来插入你自己的function和/或工具包。
所以是的，这是一个select的问题。 当需要真正简单的模板时，考虑显示一些纪律，使你的逻辑不在你的模板中。 但是，当你期望你的应用程序增长时，你最终将需要模板框架的function。 到那时，你希望不要通过编码来重新发明轮子。
最后但并非最不重要的是，对于我来说，在一些模板框架中有一个杀手级的function。
模板的inheritance
我从Django知道它，现在我正在最新的Smarty 3中使用它。 来自Symphony框架的人也有Twig ，你可以考虑使用Django语法的端口。
起初看起来有点奇怪，但是非常强大。 你build立你的骨架，并定义各种块。 您可以扩展这些框架，并用您的内容填充（覆盖）块。
对我来说，这是一个守门员！
模板pipe理系统，我们可以单独pipe理模板文件。 系统执行时间将比正常的PHP项目更快。 所以这里的PHP文件和模板文件是分开维护的。
一旦运行这些文件，代码将被保存为template_c。 所以不多次编译。
我多次使用tinybutstrong ，它有一个非常简洁的语法。 在html模板中没有循环或伪代码。
从他们的主页：
TinyButStrong是一个库，使您能够dynamic创build基于文本源的XML / HTML页面和任何其他文件。 这是PHP语言的模板引擎。 它使您能够轻松显示来自数据库的信息，而且还可以严格协调和简化您的PHP编程。
TinyButStrong面向HTML但不专门用于HTML。 这意味着它可以与文本文件，XML，RSS，RTF，WML，Excel（xml）等一起使用。OpenTBS插件使您能够合并OpenOffice和Ms文档。
那些将大量使用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）？ 所以为什么聪明是必要的？
我喜欢使用模板的原因有两个：
1）它清理了PHP代码的可读性。 当打印（“”）语句带有大块HTML的地方时，我的PHP文件变得臃肿和不稳定。 此外，问题就像你如何将variables传递给HTML文本一样？ 你到处使用标签吗？ 你使用print（“”）并且转义你的HTML引号并且连接你的variables吗？ 您是否使用print（“”）并在HTML中使用单引号，违背标准并直接插入variables？
2）它清理HTML代码的表示。 如果将生成的HTML剪切并切割成多个文件，可能会很难保持好看。 例如，您的缩进可以取消。
3）它允许你创build多个模板，然后login的用户可以select浏览你的网站时他想要显示的模板/皮肤，而且如果你是这样的话，你也可以快速，毫不费力地将默认模板更改为其他的模板斜。
总的来说，这只是组织一切的一个更好的方法。 在学习和input模板类命令，打开多个文件等方面有一点点权衡。但在我看来，我认为这是值得的，因为代码的可读性和组织性上升。
