JavaScript

индекс
246,38

Велосипедим, или 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. Там-же есть краткий пример использования шаблонизатора.

На данный момент весь код очень экспериментальный, и написался буквально за один день. В наших планах довести его до стабильного состояния и использовать везде и повсюду.
+21
3 сентября 2010, 12:08
30

комментарии (19)

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

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

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

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


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

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

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

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

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