March 28, 2008 at 10:52Template engines for HTML.
This week quite a lot was written about template engines, mainly Smarty and XSLT. At the same time, your humble servant was thinking hard about what kind of template engine to use on his projects, and came to the disappointing conclusion that he did not like anything. Next, the basic methods of writing patterns will be considered, it is written that they are not good and their views on the problem are proposed.
So, the templates, as you know, are designed to separate the code and the presentation, and accordingly separate the work of the typesetter and programmer. From this amazingly new information, we can conclude that the ideal template should consist of pure html, as the layout designer should work only with html and css (which, with the existing browser zoo, is already a feat), and the programmer, since he is a lazy and expensive creature in content, he has to do business logic.
In addition, as a rule, the layout designer’s task is to create 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 — layout in notepad, of course, is kosher, but dreamviewer developers, too not for nothing eat bread.
So, consider the following common template engines.
The most common template engine, flexible, tasty and powerful, allows you to do everything 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 output the variable in php or jsp, you need to do too many gestures. In addition, this requires the layout designer to know the language and such a template cannot be ported between languages (I don’t know how relevant this is, for projects smaller than Yandex).
http://www.smarty.net/
One of the most popular template engines, so let's consider it as an example. It allows you to use functions, loops, conditions, but in the end we have the same programming language, only easier, which, however, does not eliminate the need to learn it. Again, when viewing a template in the browser, various unpleasant rudiments from condition cycles get out. In addition, to perform any trivial task, such as displaying pictures in a table of three in a row, it is necessary to “program”, which, in my opinion, is too much for such a child’s task. You can, of course, write a function, but there you have to stuff pieces of html code, and this is also a perversion.
The greatest, after the wheel, invention of mankind, as we have seen this week. But the main catch is that XSLT is an ideal tool for transferring one document for robots into another equally unreadable document (that is, XML can of course be read by humans, but this is a dubious pleasure).
Accordingly, the template is a mishmash of tags that requires additional close examination. Our spherical layout designer, I remind you, must know HTML well, and improve yourself in your free time.
In addition, as a rule, first the page is layout from the layout, looks in browsers (shown to the customer), and then it will have to be redirected to 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 you should use it all the same for its intended purpose.
http://alexeyrybak.com/blitz/blitz_ru.html The
template engine is great for everyone, but only now the logic of the template is left to the programmer. Instead of generating data and sending it to a template and forgetting, now our controller (and, as a consequence, the programmer) will have to rotate the cycles and work on other uninteresting tasks.
It is used in asp.net, and allows you to specify the "run on server" attribute to change its properties and contents from the backend, similar to windows forms. The method is interesting, but questionable in terms of performance, although of course everything is cached and optimized. In addition, I have never seen implementations of such an approach anywhere except asp.net (though I was mostly occupied with php), HTML_MetaForm Koterova, after all, is a bit from another opera.
In addition, the programmer again has to deal with various uninteresting things, such as changing the src attributes of images.
Actually, this is even more likely not a template engine, but a preprocessor for templates. The logic of templates does not shine with variety, by and large this condition, cycle and some routine operations with forms. Thus, we just need to indicate which piece of html is responsible for, and this can be done using html comments, which were actually invented for this.
Thus, the problem considered earlier, with the output of pictures three in a row (I know that this can be done with divs, but this is not so obvious), comes down to arranging comments:
It looks a little redundant, but in a real situation, the html of the code will be much larger, but 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 subnodes and attributes, and on their basis generates the final code (php, jsp, smarty — which is more convenient for you).
At the same time, there is a magic node “by default” not limited by any “subtags”, which in simple cases allows reducing the number of instructions. Those. You can write it like this:
Thus, we have an extensible template engine that allows everyone to do their own thing, and, theoretically, has the ability to use third-party tags.
There is an implementation, but rather poor - it was made more likely to check the convenience of the approach, in particular, nested tags of the same type are not supported. If the approach is of interest and in practice the method is convenient — I will write the normal version, it’s not tricky.
So, the templates, as you know, are designed to separate the code and the presentation, and accordingly separate the work of the typesetter and programmer. From this amazingly new information, we can conclude that the ideal template should consist of pure html, as the layout designer should work only with html and css (which, with the existing browser zoo, is already a feat), and the programmer, since he is a lazy and expensive creature in content, he has to do business logic.
In addition, as a rule, the layout designer’s task is to create 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 — layout in notepad, of course, is kosher, but dreamviewer developers, too not for nothing eat bread.
So, consider the following common template engines.
Programming language
The most common template engine, flexible, tasty and powerful, allows you to do everything 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 output the variable in php or jsp, you need to do too many gestures. In addition, this requires the layout designer to know the language and such a template cannot be ported between languages (I don’t know how relevant this is, for projects smaller than Yandex).
Smarty
http://www.smarty.net/
One of the most popular template engines, so let's consider it as an example. It allows you to use functions, loops, conditions, but in the end we have the same programming language, only easier, which, however, does not eliminate the need to learn it. Again, when viewing a template in the browser, various unpleasant rudiments from condition cycles get out. In addition, to perform any trivial task, such as displaying pictures in a table of three in a row, it is necessary to “program”, which, in my opinion, is too much for such a child’s task. You can, of course, write a function, but there you have to stuff pieces of html code, and this is also a perversion.
XSLT
The greatest, after the wheel, invention of mankind, as we have seen this week. But the main catch is that XSLT is an ideal tool for transferring one document for robots into another equally unreadable document (that is, XML can of course be read by humans, but this is a dubious pleasure).
Accordingly, the template is a mishmash of tags that requires additional close examination. Our spherical layout designer, I remind you, must know HTML well, and improve yourself in your free time.
In addition, as a rule, first the page is layout from the layout, looks in browsers (shown to the customer), and then it will have to be redirected to 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 you should use it all the same for its intended purpose.
Blitz templates
http://alexeyrybak.com/blitz/blitz_ru.html The
template engine is great for everyone, but only now the logic of the template is left to the programmer. Instead of generating data and sending it to a template and forgetting, now our controller (and, as a consequence, the programmer) will have to rotate the cycles and work on other uninteresting tasks.
Form like template engine.
It is used in asp.net, and allows you to specify the "run on server" attribute to change its properties and contents from the backend, similar to windows forms. The method is interesting, but questionable in terms of performance, although of course everything is cached and optimized. In addition, I have never seen implementations of such an approach anywhere except asp.net (though I was mostly occupied with php), HTML_MetaForm Koterova, after all, is a bit from another opera.
In addition, the programmer again has to deal with various uninteresting things, such as changing the src attributes of images.
Author's bike
Actually, this is even more likely not a template engine, but a preprocessor for templates. The logic of templates does not shine with variety, by and large this condition, cycle and some routine operations with forms. Thus, we just need to indicate which piece of html is responsible for, and this can be done using html comments, which were actually invented for this.
Thus, the problem considered earlier, with the output of pictures three in a row (I know that this can be done with divs, but this is not so obvious), comes down to arranging comments:
Ничего нет :(
It looks a little redundant, but in a real situation, the html of the code will be much larger, but 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 subnodes and attributes, and on their basis generates the final code (php, jsp, smarty — which is more convenient for you).
At the same time, there is a magic node “by default” not limited by any “subtags”, which in simple cases allows reducing the number of instructions. Those. You can write it like this:
{$Title}
{$Text}Thus, we have an extensible template engine that allows everyone to do their own thing, and, theoretically, has the ability to use third-party tags.
Implementation
There is an implementation, but rather poor - it was made more likely to check the convenience of the approach, in particular, nested tags of the same type are not supported. If the approach is of interest and in practice the method is convenient — I will write the normal version, it’s not tricky.