Templates in the template engine and how Django templates reached PHP (once again)
In anticipation of February 23rd, you may not even notice how the evening of Thursday talks about PHP template engines can smoothly flow into Friday nights.
The article will cover several topics, starting with the topic of the need for template engines in general and PHP in particular, and ending with notes on the process of creating the template dja (porting code from Python to PHP).
')
In those old times, when most of us walked under the table, some Greenlander published PHPT code. Then, it seemed, no one had the idea to apply the principle of segregation of duties in a distributed MVC form to web development, however, it was quite possible to call that “set of scripts” a template engine because of surrogate SSI and working with forms.
PHP has long since grown out of its previous pants, and is trying to go beyond web development with slips, but they are not in a hurry to remove the template label from it. Firstly, because the possibility of implanting PHP-code into the code, say, html is a basic feature of the language, secondly, because of a specific class of tasks that do not require the introduction of an additional layer of abstraction - the template pre-processor.
It is important to understand that the need to use or not use the template engine should be dictated primarily by the task. Yes, this is an ancient mantra - “the instrument is chosen for the task” - and here it also works.
If this is a project of a person (or several) who does not distort from <? in the template code, if he knows what he is doing, for whom, why he does it, and realizes the possible consequences, then this is great. These are people with an iron will, and, often, able to subjugate others to it.
If this is a project of several teams, when the separation of different areas of the product according to different levels of abstraction is vital for maintaining qualitative and quantitative performance indicators, or a project of a perfectionist (for example, one suffering from “brain patterns”), there is no particular choice - sooner or later you will have to start using the template .
And then, when choosing a template engine, you inevitably encounter three basic selection criteria:
* At leisure, you can come up with a few more or shuffle those on priority.
It is important because it affects the threshold of entry and the speed of development of templates (the latter is often leveled when using IDE). The simpler and more logical the syntax, the faster the web designers (the ones about whom they have not heard anywhere else but Russia) will give the result.
The concept of security in templates is closely related to the concept of a permitted level of logic , which in turn is associated with the concept of extensibility .
The allowed level of logic influences what cases the template creator can do. It is clear the desire of the majority to have in the templates exactly as much logic as necessary and what is no longer needed. The only problem is that “how much is needed” is different for everyone - on the one hand there are shouts: “Why elseif template maker should smell like business logic”, on the other: “And we need to be able to start the OS process in the template”. This is where the notion of "extensibility" arises.
Popular template engines provide not only the ability to extend the set of available commands within a template with built-in tools, but also isolate the processes running inside the template from the main application thread.
It is clear that no one needs a templating system that brews coffee in the blink of an eye, but at the same time gives up a page for two seconds. Speed ​​definitely matters. Smart developers have taught their smart template engines to cache template data (at different levels, in different ways and in different forms). Indeed, there is plenty to choose from.
The fact that such a dja can be briefly learned from the announcement ).
You can learn about what and in what manner of porting were done from the description of dja on github , and in this chapter I will tell you how many squats were worth of porting.
First of all, it is worth mentioning that Django is a full-fledged framework for developing web applications in Python, and the templating engine is a considerable part of it. And in order to remove one of the other, it was necessary to trace dependencies and design surrogate caps for parts of the framework that were in direct contact with it. This is how the built-in interfaces appeared - extremely simplified substitutes for the adjacent Django subsystems, which, however, can be replaced by user developments.
In porting to be closer to the source is always good. This allows at any time, after the sample has changed, to quickly navigate and make appropriate adjustments to the port. To solve this problem, a set of functions was defined that imitated Python functions.
It’s no secret that some functions with a similar purpose in Python and PHP differ greatly in signatures, and some may simply not be there. Compare, for example, the parameters str_split () and '' .split (), Reflection * objects and functions of the inspect module, or the types of data returned as match by functions to work in regular expressions.
The existence of such adaptive substitutes implies the cost of their execution, but it is at times extremely difficult to crush the esthete in itself.
To be even closer to the source in PHP was not enough:
Differences in the fields of visibility of variables inside the method and the lack of syntactic sugar in PHP had to be compensated by creating closures (compare: dja , Django ) to create decorators, by and large quite well.
You can extend the functionality of Django by implementing your tags and filters. For simplification of their registration in the library code, decorators are used in full. For dja, we had to come up with an alternative way - anonymous functions came to the rescue.
Compare (lower filter registration):
Thus, anonymous functions can be called a lifesaver, when porting code from Python, which is rich in decorators, to PHP, in particular, dja is a triumph of anonymous functions. No other PHP project, I have not seen them in such numbers.
Django is famous for its set of tests, so shame and disgrace would not import at least part of this treasure of wisdom. I am convinced that at least reading the regressive test code before going to bed will make you spiritually richer (carefully brackets, take care of your eyes!).
In the course of the work on porting, it is not difficult to notice that much of the time is spent on replacing the general design of the code: for PHP it is the drawing of dollars, curly brackets, semicolons. To defeat this routine is probably possible by applying simple regular expressions to the source code, but in fact with dja it turned out that such deception was used only when porting tests - it was there that the level of monotony was incredibly rolls over.
This is probably all I wanted to say.
Thanks for attention. Good luck in porting.
PS: And yes, I was surprised to find that dja is “ gaining momentum ”. This is not true% P
The article will cover several topics, starting with the topic of the need for template engines in general and PHP in particular, and ending with notes on the process of creating the template dja (porting code from Python to PHP).
About template engines
')
In those old times, when most of us walked under the table, some Greenlander published PHPT code. Then, it seemed, no one had the idea to apply the principle of segregation of duties in a distributed MVC form to web development, however, it was quite possible to call that “set of scripts” a template engine because of surrogate SSI and working with forms.
PHP has long since grown out of its previous pants, and is trying to go beyond web development with slips, but they are not in a hurry to remove the template label from it. Firstly, because the possibility of implanting PHP-code into the code, say, html is a basic feature of the language, secondly, because of a specific class of tasks that do not require the introduction of an additional layer of abstraction - the template pre-processor.
It is important to understand that the need to use or not use the template engine should be dictated primarily by the task. Yes, this is an ancient mantra - “the instrument is chosen for the task” - and here it also works.
If this is a project of a person (or several) who does not distort from <? in the template code, if he knows what he is doing, for whom, why he does it, and realizes the possible consequences, then this is great. These are people with an iron will, and, often, able to subjugate others to it.
If this is a project of several teams, when the separation of different areas of the product according to different levels of abstraction is vital for maintaining qualitative and quantitative performance indicators, or a project of a perfectionist (for example, one suffering from “brain patterns”), there is no particular choice - sooner or later you will have to start using the template .
And then, when choosing a template engine, you inevitably encounter three basic selection criteria:
- Syntax
- Security
- Work speed
* At leisure, you can come up with a few more or shuffle those on priority.
Syntax
It is important because it affects the threshold of entry and the speed of development of templates (the latter is often leveled when using IDE). The simpler and more logical the syntax, the faster the web designers (the ones about whom they have not heard anywhere else but Russia) will give the result.
Security
The concept of security in templates is closely related to the concept of a permitted level of logic , which in turn is associated with the concept of extensibility .
The allowed level of logic influences what cases the template creator can do. It is clear the desire of the majority to have in the templates exactly as much logic as necessary and what is no longer needed. The only problem is that “how much is needed” is different for everyone - on the one hand there are shouts: “Why elseif template maker should smell like business logic”, on the other: “And we need to be able to start the OS process in the template”. This is where the notion of "extensibility" arises.
Popular template engines provide not only the ability to extend the set of available commands within a template with built-in tools, but also isolate the processes running inside the template from the main application thread.
Work speed
It is clear that no one needs a templating system that brews coffee in the blink of an eye, but at the same time gives up a page for two seconds. Speed ​​definitely matters. Smart developers have taught their smart template engines to cache template data (at different levels, in different ways and in different forms). Indeed, there is plenty to choose from.
Dja. About porting from Python to PHP
The fact that such a dja can be briefly learned from the announcement ).
You can learn about what and in what manner of porting were done from the description of dja on github , and in this chapter I will tell you how many squats were worth of porting.
Break the frame
First of all, it is worth mentioning that Django is a full-fledged framework for developing web applications in Python, and the templating engine is a considerable part of it. And in order to remove one of the other, it was necessary to trace dependencies and design surrogate caps for parts of the framework that were in direct contact with it. This is how the built-in interfaces appeared - extremely simplified substitutes for the adjacent Django subsystems, which, however, can be replaced by user developments.
Be closer to the source
In porting to be closer to the source is always good. This allows at any time, after the sample has changed, to quickly navigate and make appropriate adjustments to the port. To solve this problem, a set of functions was defined that imitated Python functions.
It’s no secret that some functions with a similar purpose in Python and PHP differ greatly in signatures, and some may simply not be there. Compare, for example, the parameters str_split () and '' .split (), Reflection * objects and functions of the inspect module, or the types of data returned as match by functions to work in regular expressions.
The existence of such adaptive substitutes implies the cost of their execution, but it is at times extremely difficult to crush the esthete in itself.
To be even closer to the source in PHP was not enough:
- Keyword Arguments
- Finally branches in exception handling
- __iter__ descriptor instead of Iterator interface
- Partial binding of arguments of type functools.partial ()
Differences in the fields of visibility of variables inside the method and the lack of syntactic sugar in PHP had to be compensated by creating closures (compare: dja , Django ) to create decorators, by and large quite well.
Simplify the creation of tag libraries and filters
You can extend the functionality of Django by implementing your tags and filters. For simplification of their registration in the library code, decorators are used in full. For dja, we had to come up with an alternative way - anonymous functions came to the rescue.
Compare (lower filter registration):
@register.filter(is_safe=True) def lower(value): return value.lower() $lib->filter('lower', function($value) { return strtolower($value); }, array('is_safe' => True));
Thus, anonymous functions can be called a lifesaver, when porting code from Python, which is rich in decorators, to PHP, in particular, dja is a triumph of anonymous functions. No other PHP project, I have not seen them in such numbers.
Port tests
Django is famous for its set of tests, so shame and disgrace would not import at least part of this treasure of wisdom. I am convinced that at least reading the regressive test code before going to bed will make you spiritually richer (carefully brackets, take care of your eyes!).
Conquer monotony
In the course of the work on porting, it is not difficult to notice that much of the time is spent on replacing the general design of the code: for PHP it is the drawing of dollars, curly brackets, semicolons. To defeat this routine is probably possible by applying simple regular expressions to the source code, but in fact with dja it turned out that such deception was used only when porting tests - it was there that the level of monotony was incredibly rolls over.
This is probably all I wanted to say.
Thanks for attention. Good luck in porting.
PS: And yes, I was surprised to find that dja is “ gaining momentum ”. This is not true% P
Source: https://habr.com/ru/post/170327/
All Articles