Comments 19
задумка хорошо, ждем реализации
>На выходе получаем файл .js с кодом шаблона.
А как у этого чуда с отладкой?
А как у этого чуда с отладкой?
Упал шопиум. Даже одного товара не получилось добавить в свежий магазин.
Расскажите лучше про архитектуру, про то как вы реализовали магазины на субдоменах на базе django, как оно работает когда растут нагрузки, про велосипеды в самом django :)
P.S. Коммерческих тайн не надо, хотя бы просто концепции.
Расскажите лучше про архитектуру, про то как вы реализовали магазины на субдоменах на базе django, как оно работает когда растут нагрузки, про велосипеды в самом django :)
P.S. Коммерческих тайн не надо, хотя бы просто концепции.
Мы видим ваши трейсбеки, и уже интенсивно их чиним. Субдомены и всё остальное у нас на к счастью базе Werkzeug + SQLAlchemy + Jinja2.
Хотя мы в wishes.in.ua и на Django делали, могу о нём рассказать.
Хотя мы в wishes.in.ua и на Django делали, могу о нём рассказать.
Интересный подход. Есть два вопроса:
- Можно ли использовать оригинальный неоткомпилированный шаблон через Django для отдачи начальной версии страницы, а откомпилированный js шаблон для асинхронного обновления страницы (думаю можно, на всякий случай уточняю)?
- Может быть было бы элегантней использовать стандартный parser/lexer из системы шаблонов Django (наверное и в Jinja2 такое есть)?
Такая идея есть, но тут есть загвоздка в том, что в Django можно делать свои теги, а в js этих тегов понятное дело не будет, да и наш парсер шаблонов о них ничего не знает. Т.е. для Django так сделать не получится.
С Jinja ситуация другая, набор тегов там фиксированный и расширяется довольно редко. Единственное что нужно это чтобы со стороны клиента environment (фильтры, глобальные объекты и т.д.) был такой-же как и на сервере, что вполне осуществимо. Архитектурно мы Jinja во многом копируем.
Идея зрела какое-то время и начинали мы как раз с того что чтобы не плодить мини-велосипеды пытались использовать парсер Jinja2, но отказались, уже не помню почему.
С Jinja ситуация другая, набор тегов там фиксированный и расширяется довольно редко. Единственное что нужно это чтобы со стороны клиента environment (фильтры, глобальные объекты и т.д.) был такой-же как и на сервере, что вполне осуществимо. Архитектурно мы Jinja во многом копируем.
Идея зрела какое-то время и начинали мы как раз с того что чтобы не плодить мини-велосипеды пытались использовать парсер Jinja2, но отказались, уже не помню почему.
Спасибо за ответ. Я вот сделал тоже велосипед: кастомный include тег django, который используя стандартные джанговские функции, парсил обычный джанговский темплейт, выдирал всякие лишние теги (был white-list тегов) и далее это чудо инклудилось в страницу перед /body. А потом использовался js-шаблонизатор PURE от BeeBole. Это все я ради фана сделал, для хобби-проекта, так что не production-ready. Таким образом у меня был один темплейт для обработки на сервере и для обработки на стороне клиента. Но это все без предварительной компиляции, что меня не радовало.
А как же интернационализация?
напомнило github.com/fitzgen/tempest/
Кстати, более-менее полная реализация django-шаблонов на js есть тут: github.com/simonw/djangode
Не знаю правда, легко ли это будет на клиент перенести, при желании можно. Другое дело, что незачем, наверное)
Не знаю правда, легко ли это будет на клиент перенести, при желании можно. Другое дело, что незачем, наверное)
Sign up to leave a comment.
Велосипедим, или Django-like Javascript Templates