Why (not)use a template engine?
The actual subject. I often get into conflict situations about this, which often end in copulation with the mother of someone else.
Many people "choose" template engines because of the fact that php is separate, html is separate... But what's wrong with this option:
PHP:
$title = "Some Title";
$text = "Some Text";
$images = array(
0 => "img1",
1 => "img2",
2 => "img3"
);
require "template.html";
HTML:
<p><?=$title?></p>
<p><?=$text?></p>
<?foreach($images as $img):?>
<img src="<?=$img?>">
<?endforeach?>
In fact, the template engine is php, written in php... Or am I missing something?
To refer to the popularity of Smarty among layout designers is not rolls
Ala's answer this de facto standard doesn't suit me either
9 answers
There is no clear answer here.
The most important questions:
How do you feel more comfortable with or without it?
Do you do it for yourself or for people?
I'm more comfortable working with Smarty.
<?=$aaa?>
{$aaa}
<?foreach($images as $img):?>
<img src="<?=$img?>">
<?endforeach?>
{foreach $images AS $img}
<img src="{$img}">
{/foreach}
Just do not forget that in addition to the stupid transfer of something to the template, the template engine has a lot of other useful features.
If you do it for yourself, then do it as it is more convenient. If for others, then perhaps the template engine will be more convenient.
-
The very use of the style of writing code in the form of
<? ?>, that is, without explicitly specifying PHP (<?php ?>) is not always successful. On some servers, this recording option is prohibited. Read more about this here " short-open-tag -
A meaningless closing PHP tag leads to unfortunate and unforeseen consequences throughout the project, which will later take a lot of time to find the problem. If we do not say that the whole project will have to you can really rewrite it in MVC using a template engine.
-
Convenience, time. One of the factors why you should use the template engine in practice is to quickly change or rewrite the template without touching the software part. Why you should use a template engine, read " here
-
Which of the template engines is better in performance?
I also do not like to use template engines, because it is easier and faster for me to use the analogy of your example. Maybe I don't know something, but I think template engines still give a certain load. What is their plus-probably a little more cute html document in notepad, when you develop something, although who knows how. Perhaps it is still created for users who do not know php code, but only the basics of html and that they are not afraid of long codes, they use variables as tags.
Because the blocker is not only the output of variables, it is also a number of very useful mechanisms, for example, the most important one is template inheritance http://twig.sensiolabs.org/doc/templates.html#template-inheritance
In my opinion, the template engine is needed for security Since templates can be written by different people, it is necessary to prohibit them from inserting code into the template
The templator is essentially used as an intermediate language that makes it easier to compose templates in PHP, because eventually the template code is simply compiled into PHP code. PHP as a language was also originally conceived as a template language for adding dynamics to the HTML code on the server side. By the way, different template engines contain different sets of useful functions (for example, caching fragments of HTML code calculated based on data from the database), which in the case of working with pure PHP you will have to implement it yourself. Template engines have their advantages. They are not written in vain. XSLT is not exactly correct to compare with Smarty. The first is intended for processing XML data, the second-arrays and PHP objects.
From what I know, one of the most popular PHP template engines right now is Twig, simply because it is actively used in Symfony.
I've been programming in pearl for a long time, ever since CGI was king. I've been used to separating the template since those days. And for me, the best template engine is my own.
We set in the template the place of output of the variable, for example [var1], the place of inclusions [incl#file.ext], the module - [mod#LineNav], the conditions - {if logged=['superadmin','admin']}{/if} - then simple processing with regulars and full control (you need conditions-easily, pass the parameter to the module-please).
The template engine simplifies the life of layout designers. And this is enough, ( I understand that this is the only reason it was made ).
It's funny, because pyh was originally conceived as a template engine, but in the end, it turned out to be a very bad template engine:
- Redundant syntax
- When trying to output complex data structures, the template on the native pshp turns into a hell of if-s, isset (), and similar tests. Yes, you can jam it everyone and everything with the help of a dog (@), but we automatically, we lose dramatically in performance.
Yes, minusators, you just haven't tasted anything sweeter than radish) And by difficulties nothing more complicated than personal blozhekov did not do)
Initially, the PHP template engine was written in perl, but its creator decided to rewrite it in c, because the performance of perl was not enough. Let it be known to you that initially PHP should have been understood as Personal Home Page Tools, well, from the name it is already clear that this is a set of utilities for creating simple personal business card pages. Then PHP was called Personal Home Page/Form Interpreter (PHP/FI). Well, and then the dudes from Israel we found a fatal flaw in this creation, and if you believe the wiki, completely. we have rewritten the code of our personal home pages. Since then, PHP should have been understood as PHP: Hypertext Preprocessor, and it was overgrown with additional functionality, and it became possible to fill the global kernel namespace with all the new functionality.
In this way, the template engine began to be able to connect to the database, understand all sorts of xml, and be able to expand.
And all-would be nothing, but the problems that I the above described negate the simplicity of this template engine as a template engine. Of course, you can configure this template engine so that it does not throw notifications when accessing non-existent variables, or object attributes when printing, but this happens to the right cool programmers who strongly believe that any kind of errors and messages should not be ignored, but processed. Actually, in this way, templates grow in heaps of if-s.
Next, more literate the guys realized that it was impossible to continue living like this, and the template engine should work exactly as a template engine, i.e., stupidly output data sets using templates, but since php was becoming more and more popular by that time, they decided to file their own versions of template engines in php. So here is the paradox of what template engines write on template engines.
It's funny, but there is no such problem in other Ya. P.) For example, python is used purely for writing application logic, while time, as for the output of data results, specially written template engines are used for this purpose(jinja2, mako, etc...). Moreover, the templates are very simple and understandable. They do not have this hell inherent in php templates.