Pull to refresh

Comments 19

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

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

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

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


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

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

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

А PURE мы не осилили. слишком уж он усложняет и без того непростую задачу по генерации
На клиенте и на сервере одни шаблоны?
Вам нужен XSLT батенька)))
чур вас, они нам нужны чтобы всё упростить, а не наоборот :)
А что с ней? Сейчас её нет, а вообще легко добавляется. Или вы о том, что в требования нужно было добавить?
> Или вы о том, что в требования нужно было добавить?
да
у нас на тот момент не было такого требования, но сейчас, согласен, я бы добавил.
Кстати, более-менее полная реализация django-шаблонов на js есть тут: github.com/simonw/djangode
Не знаю правда, легко ли это будет на клиент перенести, при желании можно. Другое дело, что незачем, наверное)
Only those users with full accounts are able to leave comments. Log in, please.