Проектирование и разработка шаблонного движка на C# и ANTLR30.05.2017 16:33

Комментарии (20)

  • 30 мая 2017 в 14:07

    0

    ↑

    ↓

    Вообще говоря с Razor-ом можно было подружиться посредством верификации перечня подключенных к сборке типов по белому списку. Есть подозрение, что это было бы более простой задачей.

    • 30 мая 2017 в 14:15

      0

      ↑

      ↓

      Не нашли такой возможности, скиньте ссылку, если под рукой, интересно!

      В любом случае, в разоре прилично всего напрягало, когда обсуждали решения. Во-первых, когда при написании вьюх возникает ошибка, мне иногда приходится ковыряться в исходниках MVC, чтобы понять, что имеется в виду. Во-вторых, если не изменяет память — он рендерил что-то с использованием то ли временного каталога на диске, то ли еще какой-то грязи. В-третьих — он всё-таки для программистов совсем.

      По итогу просто было ощущение, что будем пытаться использовать инструмент для задачи, под которую он не заточен.

      • 30 мая 2017 в 14:22 (комментарий был изменён)

        0

        ↑

        ↓

        Берёте на выбор Mono.Cecil/dnlib/System.Reflection.Metadata и загружаете полученную от Razor-а сборку. Дальше просто анализируете набор импортированых токенов типов и методов, ибо чтобы вызвать хоть что-то, нужно на него сначала сослаться, даже для работы dynamic нужен специальный набор типов и методов, которые можно в белый список не включать.


        Временный каталог Razor-у (старому, который не в ASP .NET Core) нужен для сохранения шарповых исходников, которые тот скармливает csc.exe и полученных на выходе dll-ок. Они-то вам и нужны.

        • 30 мая 2017 в 14:50

          0

          ↑

          ↓

          Я правильно понимаю, что каждому шаблону соответствует отдельная dll?


          В принципе, звучит работоспособно, но:


          • слегка на костылях, всё-таки. Неочевидный код, ошибка в котором — серьезная security-уязвимость
          • у нас одновременно в работе бывает несколько тысяч шаблонов, каждую минуту некоторые из них меняются другими. Сложно оценить перформанс этой системы со сборками и рефлексией

          А нового разора, когда анализировали существующие варианты, по-моему, вообще ещё не существовало.


          В общем, не топлю за то, что однозначно Razor плохо, просто вот по совокупности много всем стало казаться, что слишком много «но».

  • 30 мая 2017 в 14:08

    0

    ↑

    ↓

    Долго думал спрашивать или нет, но все же, чем не устраивает Razor?

    • 30 мая 2017 в 14:15

      0

      ↑

      ↓

      Ответил здесь: https://habrahabr.ru/company/mindbox/blog/329772/#comment_10241078

      • 30 мая 2017 в 14:22

        0

        ↑

        ↓

        Ну есть же альтернативы… Неужели не нашлось ничего стоящего?

        • 30 мая 2017 в 14:34

          0

          ↑

          ↓

          В статье есть немножко про исследование альтернатив, не нашлось.
          Но если знаете какие-то движки, которые подходят под наши требования, скиньте обязательно, мне интересо

          • 30 мая 2017 в 14:37

            +1

            ↑

            ↓

            Особо не вчитывался, но к примеру вот

            Встраивается в html, приятный синтаксис

            • 30 мая 2017 в 14:42

              0

              ↑

              ↓

              Liquid рассматривали очень плотно, не понравился тем, что почти не поддерживается (видно по гитхабу) и, насколько помню, туго расширяется в тех местах, где нам надо.

  • 30 мая 2017 в 14:30

    0

    ↑

    ↓

    исходники движка закрыты? имеет смысл делать статьи на технологии недоступные другим?

    • 30 мая 2017 в 14:38

      0

      ↑

      ↓

      Статья всё же про ANTLR и парсеры, а не про очередной шаблонизатор.

    • 30 мая 2017 в 14:39

      0

      ↑

      ↓

      Исходники закрыты на текущей момент, возможность открыть держим в уме, но это требует политических решений и дополнительной работы,.

      Смысл статьи — показать процесс разработки крупной фичи от этапа сбора требований до выпуска в продакшн, немного познакомить с ANTLR и просто поделиться опытом. Думаю, кому-то точно может быть интересно.

  • 30 мая 2017 в 14:49

    0

    ↑

    ↓

    Неужели нет ничего подобного для c#

    • 30 мая 2017 в 15:10

      0

      ↑

      ↓

      http://nvelocity.sourceforge.net/

  • 30 мая 2017 в 15:07

    0

    ↑

    ↓

    Вы придумали PHP?)


    Нет, серьезно, не рассматривали такую возможность? PHP или PHP+Twig вполне бы подошел. Его тут даже не надо наружу выставлять, просто запускать консольное приложение с параметрами. И к базе он умеет коннектиться.

    • 30 мая 2017 в 15:22

      0

      ↑

      ↓

      Не совсем понятно, как это должно работать. Схема с межпроцессным взамодействием .NET-стека с PHP в условиях десятков тысяч операций в минуту кажется очень странной. В отличие от других альтернатив, которые тут озвучивали, эту мы реально даже не рассматривали.

      • 30 мая 2017 в 16:27

        0

        ↑

        ↓

        Ну что-нибудь типа такого: 


        sendOrderCompleteEmail(email, orderId)
{
    html = executeCommand("php orderComplete.html orderId=" + orderId);
    sendEmail(email, html);

    // или так

    order = findOrder(orderId);
    stdinContent = jsonEncode(order);
    html = executeCommand("php orderComplete.html", stdinContent);
    sendEmail(email, html);
}

        Или демона поднять и данные через порт слать.

    • 30 мая 2017 в 15:24

      0

      ↑

      ↓

      Не нужен тут PHP, движков под C# предостаточно. Также ребята получили опыт и в случае чего расширят свой шаблонизатор именно так, как им надо. Самый наихудший вариант это прикрутить для проекта на C# PHP, хуже что-то придумать сложно.

    • 30 мая 2017 в 16:00

      0

      ↑

      ↓

      Ой, а я даже давным-давно делал парсер PHP как раз на ANTLR. Кстати, решал проблемы, схожие с описанными в статье. Если кому интересно — велкам.

© Habrahabr.ru