Велосипедим, или Django-like Javascript Templates

    Одним из компонентов нашего проекта Shopium.ua является административный интерфейс, который строится как полностью выполняющийся на клиенте rich internet application.

    Для отрисовки данных приходящих с сервера в HTML нам часто нужен Javascript-шаблонизатор.

    Различных шаблонизаторов для Javascript существует предостаточно. Даже в библиотеке ExtJS которую мы используем для своего проекта их целых два, однако их синтаксис и возможности каждого далеки от идеала.

    К хорошему быстро привыкаешь, и мы быстро привыкли к синтаксису шаблонов Jinja2 который мы используем для генерации HTML на стороне сервера. И захотели такой же, но с перламутровыми пуговицамино для Javascript.

    И сформировали к нему такие требования:
    1. Django/Jinja-подобный синтаксис
    2. компиляция шаблона в JS код (как в Closure Templates)
    3. автоэкранирование HTML
    4. простота (разработки, использования, внедрения)

    Обыскав интернет и не найдя ничего похожего, мы воскликнули «Да разработчики мы или нет, в конце концов!», и написали свой.

    Шаблонизатор состоит из одного исполняемого файла. Алгоритм работы очень прост:
    1. С помощью pyparsing разбираем исходный код шаблона, и строим синтаксическое дерево.
    2. Рекурсивно пробегаемся по дереву, и транслируем его в Javascript.

    На выходе получаем файл .js с кодом шаблона.

    Полученный файл затем можно подключить в свой проект.

    Исходный код проекта под лицензией MIT доступен в моём репозитории на BitBucket. Там-же есть краткий пример использования шаблонизатора.

    На данный момент весь код очень экспериментальный, и написался буквально за один день. В наших планах довести его до стабильного состояния и использовать везде и повсюду.
    Поделиться публикацией
    Комментарии 19
      +1
      задумка хорошо, ждем реализации
        +1
        для базовых вещей оно работает уже, можно экспериментировать.
        0
        >На выходе получаем файл .js с кодом шаблона.
        А как у этого чуда с отладкой?
          0
          Сейчас не очень. В дальнейшем планируем добиться читабельности сгенерированного js-кода + Firebug/Chrome Developer Tools
          0
          Упал шопиум. Даже одного товара не получилось добавить в свежий магазин.

          Расскажите лучше про архитектуру, про то как вы реализовали магазины на субдоменах на базе django, как оно работает когда растут нагрузки, про велосипеды в самом django :)

          P.S. Коммерческих тайн не надо, хотя бы просто концепции.
            0
            Мы видим ваши трейсбеки, и уже интенсивно их чиним. Субдомены и всё остальное у нас на к счастью базе Werkzeug + SQLAlchemy + Jinja2.

            Хотя мы в wishes.in.ua и на Django делали, могу о нём рассказать.
            0
            Интересный подход. Есть два вопроса:
            1. Можно ли использовать оригинальный неоткомпилированный шаблон через Django для отдачи начальной версии страницы, а откомпилированный js шаблон для асинхронного обновления страницы (думаю можно, на всякий случай уточняю)?
            2. Может быть было бы элегантней использовать стандартный parser/lexer из системы шаблонов Django (наверное и в Jinja2 такое есть)?


              0
              Такая идея есть, но тут есть загвоздка в том, что в Django можно делать свои теги, а в js этих тегов понятное дело не будет, да и наш парсер шаблонов о них ничего не знает. Т.е. для Django так сделать не получится.

              С Jinja ситуация другая, набор тегов там фиксированный и расширяется довольно редко. Единственное что нужно это чтобы со стороны клиента environment (фильтры, глобальные объекты и т.д.) был такой-же как и на сервере, что вполне осуществимо. Архитектурно мы Jinja во многом копируем.

              Идея зрела какое-то время и начинали мы как раз с того что чтобы не плодить мини-велосипеды пытались использовать парсер Jinja2, но отказались, уже не помню почему.
                0
                Спасибо за ответ. Я вот сделал тоже велосипед: кастомный include тег django, который используя стандартные джанговские функции, парсил обычный джанговский темплейт, выдирал всякие лишние теги (был white-list тегов) и далее это чудо инклудилось в страницу перед /body. А потом использовался js-шаблонизатор PURE от BeeBole. Это все я ради фана сделал, для хобби-проекта, так что не production-ready. Таким образом у меня был один темплейт для обработки на сервере и для обработки на стороне клиента. Но это все без предварительной компиляции, что меня не радовало.
                  0
                  Да, идея использовать один и тот-же шаблон на бэкенде и у клиента мне тоже очень нравится. Тут особенно хорошо тем кто на NodeJS что-то делает. Берёшь любой JS движок и вперёд.

                  А PURE мы не осилили. слишком уж он усложняет и без того непростую задачу по генерации
                    0
                    На клиенте и на сервере одни шаблоны?
                    Вам нужен XSLT батенька)))
                      0
                      чур вас, они нам нужны чтобы всё упростить, а не наоборот :)
              +1
              А как же интернационализация?
                0
                А что с ней? Сейчас её нет, а вообще легко добавляется. Или вы о том, что в требования нужно было добавить?
                  0
                  > Или вы о том, что в требования нужно было добавить?
                  да
                    0
                    у нас на тот момент не было такого требования, но сейчас, согласен, я бы добавил.
                0
                напомнило github.com/fitzgen/tempest/
                  0
                  интересно, спасибо за линк
                  0
                  Кстати, более-менее полная реализация django-шаблонов на js есть тут: github.com/simonw/djangode
                  Не знаю правда, легко ли это будет на клиент перенести, при желании можно. Другое дело, что незачем, наверное)

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое