Template Syntax Standards

    Have you stopped hearing from beginners the question: “which template to choose?”. I don’t think so.
    The only thing that can be said with certainty is that from time to time some solutions become popular in certain circles, but for the most part they are a limitation of their scope, this is a programming language. It is not necessary to list the advantages of the existence of any standards. Everyone understands, “from this everything will be good.” To invent, fix, apply them - this is a task that is far from trivial, but it can be solved.

    Let's get started on this one.

    The idea of ​​introducing a single template syntax is not new. As you can see now by the variety of existing template engines, the syntax is dependent on the programming language.
    We can conclude that it is necessary to work out something that suits everyone. We clearly understand that bulky syntaxes do not take root (hello, xslt). But the manifestation of minimalism is not good. You can go the way when we have a short and complete form of recording for operators, and make the assumption that the full form of writing 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 brief syntax, but we are ready to pay a coin in the form of a refusal of direct support for templates in the "xxx" language. Moreover, for this circle of languages, such patterns should not be a hindrance. Well, if you wanted to transfer the templates to the YP “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 engine, you need to feed data in a specific format. Fortunately, here everything is more or less settled down: JSON and XML. But, you also need to consider that it is not always advisable to prepare data before starting template generation. 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, format data before inserting into a template. This also should not be abandoned.

    Template engines should be distinguished from frameworks that allow the user request to be fully processed, from receiving to issuing content. Such a binding (receiving, processing, issuing) for the development of a template engine is redundant. But, this does not mean that it should not be, and it is necessary to insert sticks into the wheels of the developers of these. On the contrary, you need to provide the simplest interface to using the template. Here I want to make the same note that not only the server part needs to be standardized. To apply a similar approach will be correct on the client side.

    The template parser should give us the native code for our code at the output. It is not necessary that we have to parse it every time we access the template. Everyone copes with this task in different ways. Someone ignores and goes forehead, parses with every call, someone generates a code (eval-style), in some languages ​​there is an opportunity to add a method on the fly, someone compiles templates once, and then uses them, and there are probably many more 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 request to request, and someone starts the handler for each request, and for them the question of the time it takes to get the executable code is sensitive. In situations where we compile a template, sometimes it’s too lazy to make the next 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 solved.

    Incredibly many conditions.

    Practice shows that universal solutions often lose to highly specialized ones. Yes it is. It remains only to find out how much this loss will be in our case? As a result of developing the standard, I want to get implementation examples for each PL. So I don’t think that everything will be sad.

    Here are some examples of operator / tag implementations in different template engines:
    Django:
    {% if today_is_weekend %}
      

    Welcome to the weekend!


    {% else %}
      

    Get back to work.


    {% endif %}

    {% for athlete in athlete_list %}
      
  • {{ athlete.name }}

  • {% endfor %}

    XSLT:

      
        One
      

      
        More.
      




      Name: {./name}


    HTML::Template:

      Some text that is included only if BOOL is true

      Some text that is included only if BOOL is false



      Name:

      Job:  




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

    {foreach key=key item=item from=$contact}
      {$key}: {$item}

      {$key}: {$item}

    {/foreach}

    EJS — Embedded Javascript
    <% if(question) { %>
      

    <%= author %>: <%= question %>


    <% } else { %>
      

    Нет вопросов, на которые можно ответить!


    <% } %>

    <% for(var i=0; i
     
  • <%= supplies[i] %>

  • <% } %>

    * This source code was highlighted with Source Code Highlighter.


    Enchanting, isn't it? Of course, people using some templates are already used to their features, and they don’t really see the desirability of changing something in life . I don’t want to prove anything, to persuade anyone. I won’t say that just like that there is enough fuse just to take everything and do it. I want to find people who are interested. When the work will go in a group of people - it will motivate the participants well.

    We can say that this will be an endless process, or fuck no one needs work. I think this is not so. Firstly, a person who knows little of the issue in a matter of a year or two can implement his decision, which will meet most of hisrequirements. Secondly, while the number of self-written template engines is growing in proportion to the number of people who master web programming, the situation does not change radically.

    Someone will say that it’s more practical today to solve any problem using the available tools. Not to say that I do not like everything. No, there are quite worthy instances, but this does not cancel the problem of the absence of a set of rules. Today, the developers of your template engine will say: “But can we fundamentally change the approach ?!”, they’ll come up with something incompatible with old crafts. We are all human beings, sooner or later “retire”, and there is by no means always anyone to continue our business. Here I probably swung a lot, because the trends on the Internet are changing faster than we are getting older, but this does not cancel out the above.

    Yes, by and large this is all for nowstick on water . There is no structure for organizing the work of the team on this task, but this is all a matter of gain.

    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.

    Is there a desire?

    PS it is unnecessary to say that nothing will work, unnecessarily unreasonable criticism, there is nothing to it, do not be nervous.

    Also popular now: