Translation: Template engines in PHP - debriefing
Translation of a Fabien Potencier blog post discussion discussion on PHP templating and Twig.
My post about template engines in PHP (approx. Translation ) received more than 70 comments at the moment. It can be noted that many of them are well thought out and reasoned. Thanks to everyone who spent their time taking part in a constructive discussion. I’m really proud that the PHP community (at least the part of it that reads my blog) is able to discuss this risky topic without starting a flame war! I am also impressed by the number of people who want to promote their own template engines;)
Before starting to answer some questions, I would like to remind you that I like templates in pure PHP. And remember, symfony uses pure PHP templates from the beginning. In fact, I defended the use of pure PHP for templates from my first PHP project and never used any third-party template system. So, I do not mind PHP for templates; I just realized that the limitations of PHP, as a template engine, became more and more annoying to me.
As Eli pointed out, “I [Fabien] present PHP templates in this form because I want to promote the template engine that I created”
')
I also liked the comment from Tchalvak: “The question of whether PHP is better or a template engine is not the most important one is much more important (and which is easier to answer) is to use templates or not. Templates — and presentation highlighting — are necessary. And in what form it is presented, it is not so important. "He perfectly summed up the issue of discussion.
I understand all the points raised in the comments, and, in a simple way, I agree with most of them. Now I want to answer a few interesting comments.
I started searching for template engine a few months ago. People who know me know that I don’t like to reinvent the wheel. Therefore, I did not want to create my new library from scratch.
I searched for good template engines, tried some of them, and eventually found Twig. And as soon as I started using it, I realized that this is the diamond I was looking for (for its functionality and simple, beautiful architecture). And, since Twig was not an independent project, I began to rewrite it. After some improvements, such as the sandbox mode, I decided to contact Armin (Armin) and talk about the future of Twig.
Even if you don't believe in my arguments, that's fine. I do not want to make Twig a universal template engine for PHP. I really think that Twig is not alone in the template engine, but I am the first to decide that it will not be used in all new PHP projects!
If you are looking for a templating engine on PHP cheat and having a built-in ability to inherit templates, blocks, auxiliary functions (helpers) and other things, the good news is that a few weeks ago I introduced the component of symfony templates . This is a completely independent (standalone) component that does not depend on anything, and I’m sure that many who want to use PHP in their templates will love this project.
And even better - you can use Twig and the symfony templating component to get the best results. Use the component for all your templates, and Twig if you need a sandbox mode.
A lot of comments on the topic of syntax , and PHP syntax problems that I raised. Speech is not the beauty of syntax, and if you think that my arguments are a discussion of “the color of bicycle sheds” (note the Russian version ), think again.
The key point of my argument is that templatelers should strive for a middle sweet spot (?? sweet spot). Template engines must find a compromise in the availability of opportunities - enough, but not too much. As I said in the previous post, the template language is related to the presentation logic . And, of course, simple conditions and cycles are part of the presentation logic. But do you want to use the
Also in the templates a lot of HTML code with a small PHP content. And this piece of code is completely unacceptable for me:
Many seem to like the short PHP tags. The first is mathematics. If you compare the
In addition to problems with XML support and the fact that the configuration parameter
Pear and Zend are quite serious projects, so they had reasons to ban short tags, didn't they?
But as Eli mentioned in his post, I would also be glad to know that PHP dealt with this problem: "... there are a number of people (including me [Eli]) who are thinking about offering a new feature to the
(comment. the original web-designers will be translated here and further as a coder)
The debate is not whether designers should understand PHP or not. And, of course, not that the designers are not smart enough. Of course, they can can learn a little PHP ... until they know too much and start writing code that is not related to their templates (for example, select records directly from the database). Well, of course, they would not make such a mistake if they knew about the MVC pattern. But, stop, they are no longer layout designers - they are programmers.
Finding a balance is to provide a tool that will help layout designers not to step on a rake. And, I think everyone will agree with me that PHP did its job poorly in setting these limits.
Some comments advocate that the shielding should be performed in controllers. It will not work. As John Campbell wrote: “The problem is that the controllers do not know what will be displayed, and they also don’t know exactly how to escape”
The problem itself is not an easy one. On the one hand, programmers should be engaged in screening, but cannot do it in controllers. On the other hand, coders should not care about screening, but only in templates it can be done with enough information. Therefore, automatic shielding is the best compromise for me, plus the fact that the default application is “almost” safe is also an advantage.
Speaking of automatic screening, I can say that I know enough about it, because this has been a possibility in symfony since 2006. I can tell you that the costs of the speed of this functionality are very large. In Twig, this is all compiled, and therefore there are no costs.
Sandbox mode is not designed for web designers. Basically, this refers to situations where people “from the outside” can change templates (think of webmasters who customize their CMS templates or blog platforms from a management system).
The development of security Dwoo and Smarty is the right step in this direction, but not as powerful as the full sandbox mode. As far as I understand, all this is mainly about allowing PHP code in templates or not, as well as limiting the available PHP functions (correct me if I am mistaken).
Sandbox mode controls everything — from valid tags, to allowed object methods (Twig documentation explains the concept and how it works)
Most template engines compile templates into PHP code. Therefore, the speed of lexing (lexing), parsing (parsing) and compilation does not play a big role, what is the speed of execution. Below is the compiled version of the
You can find it incredibly verbose than the PHP version, and, of course, the PHP version will be incredibly simpler:
But pay attention to the generated code of most template engines and you will see that Twig generates the cleanest and shortest version.
At the request of many, I rewrote the tests, aligning the compilation and rendering phases. As I expected, it didn’t change the numbers much. Compiling such simple templates is not important by the time they are rendered 10,000 times.
I also tested the templates in pure PHP. Below is the updated table:
As expected, PHP is faster than Twig for simple templates. But the harder they are, the smaller the difference will be, thanks to the purity of the code that Twig generates.
Tests you can download here: fabien.potencier.org/benchmarks.tgz
This section is for those interested in implementing Twig in symfony.
Obviously, Twig will not be part of symfony 1.3, because at the end of next week, feature-freeze deadline is suitable, and also because symfony 1.3 is an evolution of symfony 1.2, not a revolution.
At the moment, nothing concrete has been decided about Symfony 2, but Twig will not be the default templating engine. I think Twig will be available as an optional plugin, well integrated with the kernel. For example, it can be used to generate a backend (admin-generator) - to simplify its configuration (customization).
And thanks to the symfony templating component, developers will be able to use Twig and pure PHP together, depending on the needs.
So, if you do not want to get involved with template engines, use pure PHP; but if you want to win using Twig you can use it (it will be built in). And, of course, if you have other plugins, they will not be a problem.
I hope that this post answered some questions raised in the comments.
-----------------------------------------------------------------------My post about template engines in PHP (approx. Translation ) received more than 70 comments at the moment. It can be noted that many of them are well thought out and reasoned. Thanks to everyone who spent their time taking part in a constructive discussion. I’m really proud that the PHP community (at least the part of it that reads my blog) is able to discuss this risky topic without starting a flame war! I am also impressed by the number of people who want to promote their own template engines;)
Before starting to answer some questions, I would like to remind you that I like templates in pure PHP. And remember, symfony uses pure PHP templates from the beginning. In fact, I defended the use of pure PHP for templates from my first PHP project and never used any third-party template system. So, I do not mind PHP for templates; I just realized that the limitations of PHP, as a template engine, became more and more annoying to me.
As Eli pointed out, “I [Fabien] present PHP templates in this form because I want to promote the template engine that I created”
')
I also liked the comment from Tchalvak: “The question of whether PHP is better or a template engine is not the most important one is much more important (and which is easier to answer) is to use templates or not. Templates — and presentation highlighting — are necessary. And in what form it is presented, it is not so important. "He perfectly summed up the issue of discussion.
I understand all the points raised in the comments, and, in a simple way, I agree with most of them. Now I want to answer a few interesting comments.
Twig. Cause.
I started searching for template engine a few months ago. People who know me know that I don’t like to reinvent the wheel. Therefore, I did not want to create my new library from scratch.
I searched for good template engines, tried some of them, and eventually found Twig. And as soon as I started using it, I realized that this is the diamond I was looking for (for its functionality and simple, beautiful architecture). And, since Twig was not an independent project, I began to rewrite it. After some improvements, such as the sandbox mode, I decided to contact Armin (Armin) and talk about the future of Twig.
Those. you are not for sale ... still?
Even if you don't believe in my arguments, that's fine. I do not want to make Twig a universal template engine for PHP. I really think that Twig is not alone in the template engine, but I am the first to decide that it will not be used in all new PHP projects!
If you are looking for a templating engine on PHP cheat and having a built-in ability to inherit templates, blocks, auxiliary functions (helpers) and other things, the good news is that a few weeks ago I introduced the component of symfony templates . This is a completely independent (standalone) component that does not depend on anything, and I’m sure that many who want to use PHP in their templates will love this project.
And even better - you can use Twig and the symfony templating component to get the best results. Use the component for all your templates, and Twig if you need a sandbox mode.
About syntax
A lot of comments on the topic of syntax , and PHP syntax problems that I raised. Speech is not the beauty of syntax, and if you think that my arguments are a discussion of “the color of bicycle sheds” (note the Russian version ), think again.
The key point of my argument is that templatelers should strive for a middle sweet spot (?? sweet spot). Template engines must find a compromise in the availability of opportunities - enough, but not too much. As I said in the previous post, the template language is related to the presentation logic . And, of course, simple conditions and cycles are part of the presentation logic. But do you want to use the
array_chunk() function in templates? Probably not. This must be implemented in the controller or model, depending on what you want to do.Also in the templates a lot of HTML code with a small PHP content. And this piece of code is completely unacceptable for me:
<? php
if ($ items) {
foreach ($ items as $ item) {
echo "* {$ item} \ n";
}
} else {
echo "No item has been found. \ n";
}
?> Many seem to like the short PHP tags. The first is mathematics. If you compare the
<?= $var ?> Entry with the <?php echo $var ?> Entry, you will see a difference of 7 characters, not 2. But this is not the main problem.In addition to problems with XML support and the fact that the configuration parameter
short_open_tag differs among hosting providers, it is also a matter of code standardization:- PEAR : “Always use
<?php ?>To separate PHP code, not a short version<? ?><? ?>. This is mandatory by PEAR agreement and is also the most flexible way to use PHP code on different operating systems and different configurations. ”
"Always use<?php ?>To delimit PHP code, not the<? ?><? ?>shorthand. This is the most portable way to include PHP code on differing operating systems and setups. ” - Zend : “Short tags are by no means allowed.”
"Short tags are never allowed."
Pear and Zend are quite serious projects, so they had reasons to ban short tags, didn't they?
But as Eli mentioned in his post, I would also be glad to know that PHP dealt with this problem: "... there are a number of people (including me [Eli]) who are thinking about offering a new feature to the
short_tags directive in PHP, which makes it possible not only to include and turn it off. But adding the third option - which will allow <?= ?> , prohibiting <? ?> "About layout designers
(comment. the original web-designers will be translated here and further as a coder)
The debate is not whether designers should understand PHP or not. And, of course, not that the designers are not smart enough. Of course, they can can learn a little PHP ... until they know too much and start writing code that is not related to their templates (for example, select records directly from the database). Well, of course, they would not make such a mistake if they knew about the MVC pattern. But, stop, they are no longer layout designers - they are programmers.
Finding a balance is to provide a tool that will help layout designers not to step on a rake. And, I think everyone will agree with me that PHP did its job poorly in setting these limits.
Screening
Some comments advocate that the shielding should be performed in controllers. It will not work. As John Campbell wrote: “The problem is that the controllers do not know what will be displayed, and they also don’t know exactly how to escape”
The problem itself is not an easy one. On the one hand, programmers should be engaged in screening, but cannot do it in controllers. On the other hand, coders should not care about screening, but only in templates it can be done with enough information. Therefore, automatic shielding is the best compromise for me, plus the fact that the default application is “almost” safe is also an advantage.
Speaking of automatic screening, I can say that I know enough about it, because this has been a possibility in symfony since 2006. I can tell you that the costs of the speed of this functionality are very large. In Twig, this is all compiled, and therefore there are no costs.
About the sandbox
Sandbox mode is not designed for web designers. Basically, this refers to situations where people “from the outside” can change templates (think of webmasters who customize their CMS templates or blog platforms from a management system).
The development of security Dwoo and Smarty is the right step in this direction, but not as powerful as the full sandbox mode. As far as I understand, all this is mainly about allowing PHP code in templates or not, as well as limiting the available PHP functions (correct me if I am mistaken).
Sandbox mode controls everything — from valid tags, to allowed object methods (Twig documentation explains the concept and how it works)
About speed
Most template engines compile templates into PHP code. Therefore, the speed of lexing (lexing), parsing (parsing) and compilation does not play a big role, what is the speed of execution. Below is the compiled version of the
Hello {{ name }} template Hello {{ name }} : / * Hello {{name}} * /
class __TwigTemplate_1121b6f109fe93ebe8c6e22e3712bceb extends Twig_Template
{
public function display ($ context)
{
$ this-> env-> initRuntime ();
// line 1
echo "Hello";
echo (isset ($ context ['name'])? $ context ['name']: null);
}
} Many are worried about debugging. As you can see, the generated code is very clean, contains the name and lines of the original template. This should be more than enough to easily debug all problems.
You can find it incredibly verbose than the PHP version, and, of course, the PHP version will be incredibly simpler:
Hello <? Php echo $ name?>
But pay attention to the generated code of most template engines and you will see that Twig generates the cleanest and shortest version.
At the request of many, I rewrote the tests, aligning the compilation and rendering phases. As I expected, it didn’t change the numbers much. Compiling such simple templates is not important by the time they are rendered 10,000 times.
I also tested the templates in pure PHP. Below is the updated table:
| Library | Time (sec) | Memory (kb) |
|---|---|---|
| Pure php | 2.4 | 114 |
| Twig | 3 | 383 |
| Phptal | 3.8 | 598 |
| Dwoo | 6.9 | 1,645 |
| Smarty 2 | 12.9 | 610 * |
| Smarty 3 | 14.9 | 799 * |
| Calypso | 34.3 | 614 |
| eZ Templates | 53 | 2,783 |
Notice that the amount of memory used by Smarty is much less than in my previous test, because I wrapped the whole loop in ob_start()/ob_end_clean() which was unfair to other template engines. This has now been fixed.As expected, PHP is faster than Twig for simple templates. But the harder they are, the smaller the difference will be, thanks to the purity of the code that Twig generates.
Test scripts were run from the command line without PHP accelerators, which in this case would still not help, because the entire test takes place in one PHP process.
Tests you can download here: fabien.potencier.org/benchmarks.tgz
Twig and symfony
This section is for those interested in implementing Twig in symfony.
Symfony 1.3 / 1.4
Obviously, Twig will not be part of symfony 1.3, because at the end of next week, feature-freeze deadline is suitable, and also because symfony 1.3 is an evolution of symfony 1.2, not a revolution.
If someone wants to make Twig a plug-in for symfony 1.3, start a discussion on the symfony developer mailing list, and I will help you get started.
Symfony 2.0
At the moment, nothing concrete has been decided about Symfony 2, but Twig will not be the default templating engine. I think Twig will be available as an optional plugin, well integrated with the kernel. For example, it can be used to generate a backend (admin-generator) - to simplify its configuration (customization).
And thanks to the symfony templating component, developers will be able to use Twig and pure PHP together, depending on the needs.
So, if you do not want to get involved with template engines, use pure PHP; but if you want to win using Twig you can use it (it will be built in). And, of course, if you have other plugins, they will not be a problem.
Total
I hope that this post answered some questions raised in the comments.
Source: https://habr.com/ru/post/76021/
All Articles