Standards syntax standards

Have you stopped hearing the question from newbies: “which template should I choose?”. I do not think.
The only thing that can be said with certainty is that periodically some solutions become popular in certain circles, but for the most part they are limited in their scope, this is a programming language. Enumerate the benefits of the existence of any standards is not necessary. Everyone understands that "it will be good for everyone." To invent, consolidate, apply them - this is a task that is far from trivial, but it can be solved.

Let's start moving to this.

Of course, the idea of ​​introducing a single pattern syntax is not new. As you can see by the variety of existing template engines, syntaxes depend on the programming language.
It can be concluded that it is necessary to work out something that fits all. We clearly understand that cumbersome syntaxes do not take root (hello, xslt). But the manifestation of minimalism is not good. We can follow the path when we have a short and complete record for operators, and make the assumption that the full form of recording works for everyone, a short one for a narrower circle of parsers. That is, we want to get a bun in the form of a short syntax, but we are ready to pay a coin in the form of refusal of direct support for patterns in the “xxx” language. At the same time for this range of languages, such templates should not be a hindrance. Well, if we wanted to transfer the templates to the YaP “xxx”, we should be able to quickly go through all the templates and replace the short syntax with the full one.

To generate a template, you need to feed the data in a specific format. The blessing at us here more or less everything settled down: JSON and XML. But, it is also necessary to take into account that it is not always advisable to prepare data before starting to generate a template. There are cases when you need to generate data in the process of executing the template code. Plus, today, some template engines offer the ability to process and format data before inserting it into a template. This is also not worth refusing.
')
Template engines must be distinguished from frameworks that allow you to fully process a user request, from reception to issuing content. Such binding (reception, processing, issuance) for the development of a template engine is redundant. But this does not mean that it should not be, and you need to put a spoke in the wheels of the developers of them. On the contrary, you need to provide the simplest interface to use the template. Here I want to make the same note that not only the server part needs templateing. Applying this approach will be correct on the client side.

The template parser should give us a native code for our PL at the output. It is not necessary that with each reference to the template we have to parse it. Everyone copes with this task in different ways. Someone ignores and goes head-on, parsit on every call, someone generates a code (eval-style), in some PLs there is an opportunity to add a method on the fly, someone compiles the templates once, and then uses them, and probably there are many interesting ways. They vary between ease of development and performance. And we want it to be good for those who use the ability to keep the request handler running, and only use the resulting template code from the request to request, and someone starts the processor for each request, and for them the issue of how to get the executable code is sensitive. In situations where we compile the template, sometimes it is too lazy to make another edit to run the compiler. We need a mechanism that allows us to use preview for our template. here of course everything is complicated by the substitution of test data, but this is all solvable.

Incredibly many conditions.

Practice shows that universal solutions often lose highly specialized. Yes it is. It only remains to find out how much this loss will be in our case? The result of the development of the standard I want to get examples of implementation for each PL So I do not think that everything will be sad.

Here are small examples of the implementation of statements / tags in different template engines:

Django:
{% if today_is_weekend %}
< p > Welcome to the weekend! </ p >
{% else %}
< p > Get back to work. </ p >
{% endif %}

{% for athlete in athlete_list %}
< li > {{ athlete.name }} </ li >
{% endfor %}

XSLT:
< xsl:choose >
< xsl:when test ="/some/node = 1" >
One
</ xsl:when >
< xsl:otherwise >
More.
</ xsl:otherwise >
</ xsl:choose >

< xsl:for-each select ="/nodes/*" >
Name: {./name}
</ xsl:for-each >

HTML::Template:
< TMPL_IF BOOL >
Some text that is included only if BOOL is true
< TMPL_ELSE >
Some text that is included only if BOOL is false
</ TMPL_IF >

< TMPL_LOOP NAME = EMPLOYEE_INFO >
Name: < TMPL_VAR NAME = NAME > < br >
Job: < TMPL_VAR NAME = JOB > < p >
</ TMPL_LOOP >

Smarty
{if $name eq 'Fred'}
Welcome Sir.
{else}
Welcome, whatever you are.
{/if}

{foreach key=key item=item from=$contact}
{$key}: {$item} < br >
{$key}: {$item} < br />
{/foreach}

EJS — Embedded Javascript
<% if (question) { %>
< h2 > <% = author %> : <% = question %> </ h2 >
<% } else { %>
< h2 > , ! </ h2 >
<% } %>

<% for ( var i=0; i<supplies.length; i++) { %>
< li > <% = supplies[i] %> </ li >
<% } %>

* This source code was highlighted with Source Code Highlighter .

Enchanting, is not it? Of course, people using some kind of templates have already become accustomed to their features, and do not particularly see the expediency of changing something in life . I do not want to prove anything, to persuade anyone. I will not say that just like this, the fuse is enough just to take it all and do it. I want to find people who are interested. When work will go in a group of people - it will be good to motivate the participants.

You can say that it will be an endless process, or fuck nobody needed work. I think it is not. First of all, a person understanding a little in the matter can, within a year or two, implement his decision that will meet most of his requirements. Secondly, as the number of self-written template engines grows in proportion to the number of people mastering web programming, the situation does not change drastically.

Someone will say that it is more practical today to solve any problem using the available tools. Do not say that I do not like everything. No, there are quite worthy copies, but this does not cancel the problem of not having a set of any rules. Today, the developers of your template maker will say: “wouldn’t we fundamentally change the approach ?!”, they will come up with something incompatible with old handicrafts. We are all people, sooner or later “retire”, and there is not always someone to continue our business. Here, I probably strongly swung, because the trends on the Internet are changing faster than we are aging, but this does not cancel what was said.

Yes, by and large this is still a stick on the water . There is no structure for organizing teamwork on this task, but this whole thing is gainable.

Briefly about the main thing:
To form a group of interested, versed in the subject, able to discuss and then implement certain processing algorithms in different programming languages.

The desire is there?

PS needless to say that nothing will work, unnecessarily unjustified criticism, there’s nothing to it, do not be nervous.