HTML template engines.
This week quite a lot was written about template engines, mainly Smarty and XSLT. At the same time, your humble servant thought hard about what template to use on his projects, and came to the disappointing conclusion that he did not like anything. Next, we will consider the main methods of writing templates, it is painted that they are bad and offered their own view of the problem.
So, templates, as you know, are designed to separate the code and the presentation, and accordingly to separate the work of the layout designer and the programmer. From this amazing newness of information, we can conclude that the ideal template should consist of pure html, as the coder should work only with html and css (which is already a feat with the existing zoo of browsers), and the programmer, as he is lazy and expensive in the content, it is necessary to engage in business logic.
In addition, as a rule, the maker-up’s task is to make code that looks identical to the layout in the browser, so it’s desirable that the template can be viewed in the browser or in the visual editor — typeset in a notebook, of course kosher, but the dreamviewer developers also no wonder bread is eaten.
So consider the following common template engines.
')
The most common template engine, flexible, tasty and powerful, allows you to do everything that you can think of. But on the other hand, it is necessary to program, and the syntax, because of its power is redundant, for its use in the template. In order to simply display a variable in php or jsp, you need to make too many gestures. In addition, this requires the maker of the language and this pattern is not ported between languages ​​(I do not know how relevant it is, for projects less than Yandex).
http://www.smarty.net/
One of the most popular template engines, so for example, consider it. It allows you to use functions, cycles, conditions, but in the end we have the same programming language, only simpler, which, however, does not obviate the need to teach it. Again, when viewing a template in the browser, various unpleasant rudiments of condition cycles, etc., come out. In addition, to perform any trivial tasks, such as displaying pictures in a table of three in a row, you need to “program”, which, in my opinion, is too much for such a children's task. You can, of course, write a function, but there you have to stuff pieces of html code, and this is still a perversion.
The greatest, after the wheel, invention of mankind, as we managed to make sure this week. But the main catch is that XSLT is an ideal means to overtake one document for robots to another equally non-readable document (that is, XML can of course be read by humans, but the pleasure is dubious).
Accordingly, the template is a jumble of tags that requires additional scrutiny. Our spherical coder, I remind you, should know HTML well, and self-improve in your free time.
In addition, as a rule, at first the page is made up from the layout, it looks in browsers (shown to the customer), and then it will have to be overtaken in XSLT, i.e. do the same job twice.
And, as I wrote above, XSLT is a tool for translating one or more XML files into another, and it should still be used for its intended purpose.
http://alexeyrybak.com/blitz/blitz_en.html
The template engine is wonderful for everyone, but now the logic of the template is left to the programmer. Instead of forming the data and sending it to the template and forgetting, now our controller (and as a result, the programmer) will have to turn the cycles and work on other uninteresting tasks.
It is used in asp.net, and allows, by specifying an element, the attribute “execute on server” to change its properties and contents from the backend, similar to windows forms. The method is interesting, but from the point of view of performance it is doubtful, although of course everything is cached and optimized. Besides the implementation of this approach anywhere except asp.net, I have not met (although I was mostly occupied with php), HTML_MetaForm Koterova, after all, is a bit from another opera.
In addition, the programmer again has to do various little interesting things, such as changing the src attributes of images.
Actually, it is even more likely not a template engine, but a preprocessor for templates. The logic of patterns does not shine with a variety, by and large this condition, a cycle and some routine operations with forms. Thus, we just need to specify which piece of html is responsible for what, and this can be done with the help of html comments, which are actually invented for this.
Thus, the task considered earlier with the output of pictures three per row (I know that this can be done with divs, but this is not so visual), boil down to the arrangement of comments:
It looks somewhat redundant, but in a real situation, the html code will be much more, and you still need to comment on the layout.
Each instruction is processed by a separate class (in this case, optemplate_tag_each), which has access to the subnodes and attributes, and on the basis of these forms the final code (php, jsp, smarty — which one is more convenient for you).
At the same time, there is also a magic node “by default” which is not limited to any “subtags”, which in simple cases allows reducing the number of instructions. Those. Record can be and so:
<p As a result, as soon as you have a new routine task for displaying something, you simply write a new class, which, for example, can work with forms, substituting values ​​and id in the input. In this case, you do not depend on the CMS as you can rewrite the tag, depending on how the data is transferred to the template.
Thus, we have an extensible template engine that allows everyone to do their work, and, in theory, has the ability to use third-party tags.
There is an implementation, but rather a miserable one — made rather to check the convenience of the approach; in particular, nested tags of the same type are not supported. If the approach arouses interest and in practice the method proves convenient — I will write a normal version, it’s not tricky.
So, templates, as you know, are designed to separate the code and the presentation, and accordingly to separate the work of the layout designer and the programmer. From this amazing newness of information, we can conclude that the ideal template should consist of pure html, as the coder should work only with html and css (which is already a feat with the existing zoo of browsers), and the programmer, as he is lazy and expensive in the content, it is necessary to engage in business logic.
In addition, as a rule, the maker-up’s task is to make code that looks identical to the layout in the browser, so it’s desirable that the template can be viewed in the browser or in the visual editor — typeset in a notebook, of course kosher, but the dreamviewer developers also no wonder bread is eaten.
So consider the following common template engines.
Programming language
')
The most common template engine, flexible, tasty and powerful, allows you to do everything that you can think of. But on the other hand, it is necessary to program, and the syntax, because of its power is redundant, for its use in the template. In order to simply display a variable in php or jsp, you need to make too many gestures. In addition, this requires the maker of the language and this pattern is not ported between languages ​​(I do not know how relevant it is, for projects less than Yandex).
Smarty
http://www.smarty.net/
One of the most popular template engines, so for example, consider it. It allows you to use functions, cycles, conditions, but in the end we have the same programming language, only simpler, which, however, does not obviate the need to teach it. Again, when viewing a template in the browser, various unpleasant rudiments of condition cycles, etc., come out. In addition, to perform any trivial tasks, such as displaying pictures in a table of three in a row, you need to “program”, which, in my opinion, is too much for such a children's task. You can, of course, write a function, but there you have to stuff pieces of html code, and this is still a perversion.
Xslt
The greatest, after the wheel, invention of mankind, as we managed to make sure this week. But the main catch is that XSLT is an ideal means to overtake one document for robots to another equally non-readable document (that is, XML can of course be read by humans, but the pleasure is dubious).
Accordingly, the template is a jumble of tags that requires additional scrutiny. Our spherical coder, I remind you, should know HTML well, and self-improve in your free time.
In addition, as a rule, at first the page is made up from the layout, it looks in browsers (shown to the customer), and then it will have to be overtaken in XSLT, i.e. do the same job twice.
And, as I wrote above, XSLT is a tool for translating one or more XML files into another, and it should still be used for its intended purpose.
Blitz templates
http://alexeyrybak.com/blitz/blitz_en.html
The template engine is wonderful for everyone, but now the logic of the template is left to the programmer. Instead of forming the data and sending it to the template and forgetting, now our controller (and as a result, the programmer) will have to turn the cycles and work on other uninteresting tasks.
Form like template engine.
It is used in asp.net, and allows, by specifying an element, the attribute “execute on server” to change its properties and contents from the backend, similar to windows forms. The method is interesting, but from the point of view of performance it is doubtful, although of course everything is cached and optimized. Besides the implementation of this approach anywhere except asp.net, I have not met (although I was mostly occupied with php), HTML_MetaForm Koterova, after all, is a bit from another opera.
In addition, the programmer again has to do various little interesting things, such as changing the src attributes of images.
Author's bike
Actually, it is even more likely not a template engine, but a preprocessor for templates. The logic of patterns does not shine with a variety, by and large this condition, a cycle and some routine operations with forms. Thus, we just need to specify which piece of html is responsible for what, and this can be done with the help of html comments, which are actually invented for this.
Thus, the task considered earlier with the output of pictures three per row (I know that this can be done with divs, but this is not so visual), boil down to the arrangement of comments:
<code>
<! - op: each src = "$ images" split = "3" ->
<! - each: header ->
<table>
<! - / each: header ->
<! - each: splittop ->
<tr>
<! - / each: splittop ->
<! - each: row ->
<td> <a href="{link}"> <img src = "{$ src}" alt = "{$ title}" width = "100" height = "100" /> </a> </ td >
<! - / each: row ->
<! - each: splitbot ->
</ tr>
<! - / each: splitbot ->
<! - each: footer ->
</ table>
<! - each: footer ->
<! - each: else ->
There is nothing :(
<! - / each: else ->
<! - / op: each ->
</ code> It looks somewhat redundant, but in a real situation, the html code will be much more, and you still need to comment on the layout.
Each instruction is processed by a separate class (in this case, optemplate_tag_each), which has access to the subnodes and attributes, and on the basis of these forms the final code (php, jsp, smarty — which one is more convenient for you).
At the same time, there is also a magic node “by default” which is not limited to any “subtags”, which in simple cases allows reducing the number of instructions. Those. Record can be and so:
<code>
<! - op: each src = "$ folders" ->
<h3> {$ Title} </ h3>
<div> {$ Text} </ div>
<! - / op: each ->
</ code> <p As a result, as soon as you have a new routine task for displaying something, you simply write a new class, which, for example, can work with forms, substituting values ​​and id in the input. In this case, you do not depend on the CMS as you can rewrite the tag, depending on how the data is transferred to the template.
Thus, we have an extensible template engine that allows everyone to do their work, and, in theory, has the ability to use third-party tags.
Implementation
There is an implementation, but rather a miserable one — made rather to check the convenience of the approach; in particular, nested tags of the same type are not supported. If the approach arouses interest and in practice the method proves convenient — I will write a normal version, it’s not tricky.
Source: https://habr.com/ru/post/22445/
All Articles