Подтвердить что ты не робот

Django и клиентские javascript-шаблоны

Введение

В настоящее время я пишу очень стандартное приложение на основе Django (в основном это причудливый CRM/список контактов). Это похоже на работу, но по мере того, как я пытаюсь улучшить интерфейс с помощью большего количества кода AJAXy UI (используя jQuery), он начинает испытывать настоящую боль, чтобы работать. Я получаю длинные блоки хрупких обработчиков событий jQuery, которые анализируют DOM, нажимают изменения обратно на сервер, возвращают некоторые JSON и пытаются и обновляют DOM на основе этого.

Я чувствую, что, как минимум, я, вероятно, хочу добавить некоторые шаблоны на стороне клиента в микс. В качестве альтернативы, я мог бы попробовать переключиться на JS-инфраструктуру и просто использовать приложение Django в качестве уровня абстракции базы данных. Даже если я знаю и люблю Python, я мог бы отказаться от приложения Django и попробовать и пойти с решением JS/ Node.js или что-то в этом роде.

Кто-нибудь еще был в этой ситуации? Как вы его решили?

Цели проектирования

  • DRY: Я не хочу реплицировать свои модели или мои шаблоны (или, по крайней мере, больше, чем необходимо).
  • Я хочу, чтобы посетители приземлялись на странице, чтобы получить результаты на сервере rendereed.
  • По мере того, как посетители нажимают на вещи, я бы хотел обработать это с помощью клиентских шаблонов и рендеринга и обновить сервер через вызовы AJAX на интерфейс REST.

Итак... как мне это сделать? Я собрал ссылки на несколько фреймворков и систем шаблонов. В определенном порядке:

dust.js:

Это, по-видимому, используется LinkedIn для решения подобной проблемы. Он использует Node.js на стороне сервера, что не идеально (я никогда не использовал Node), но, по крайней мере, это не основанный на JVM. Он также кажется спящим на github - я нашел списки рассылки, где люди задавались вопросом, куда идет сопровождающий. Это звучит неплохо - сообщение в блоге от LinkedIn неплохо продает технологию, особенно способность ее скомпилировать. Но, похоже, это просто шаблон. Этого достаточно для того, чего я хочу?

Mustache:

Эта опция имеет как реализацию Python, так и JS, и кажется популярной... но я не могу найти тех, кто, кажется, использует шаблоны Mustache с Django. Разве это потому, что слишком легко заслужить сообщение в блоге, или это невозможно или иначе нецелесообразно? Он также довольно ограничен; по крайней мере, мне, вероятно, придется обратиться к какой-то структуре MVC JS, верно?

Магистраль, позвоночник, нокаутJS, EmberJS, JavascriptMVC и т.д.:

Там так много фреймворков, это довольно сложно. Все они кажутся совершенно хорошими на первый взгляд. Мне также кажется, что мне нужно будет переписать много моего приложения, если я поеду по этому маршруту, и я действительно хотел бы найти того, кто уже сделал что-то подобное. Кроме того, было бы неплохо, если бы был хороший выбор для кого-то из Django в качестве фона; Я не хочу изучать полдюжины различных фреймворков, чтобы их оценить.

DerbyJS

Это выглядит интересно, поскольку он обрабатывает как клиентские, так и серверные стороны в одном пакете, но немного незрелый. Они предупреждают против использования его в производстве, и, если я понимаю документы, он еще не поддерживает какую-либо настойчивость, которая... ограничивает. У меня такое чувство, что если бы это было закончено, это было бы прекрасно для того, что я хочу, хотя...

Так....

Итак, э-э... теперь что? Кто-нибудь использовал любой из этих инструментов, чтобы попытаться добавить визуализацию на стороне клиента в Django webapp? Как все прошло?

4b9b3361

Ответ 1

Для полной интеграции с шаблонами Django я нашел это: Yz-Javascript-Django-Template-Compiler. Я никогда не использовал его сам, и, к сожалению, он выглядит немного невосприимчивым.

Swig - быстрый механизм моделирования шаблонов JS-типа.

Pure - скомпилированный JS-шаблонный инструмент, который с небольшим размышлением может хорошо работать с Django, я думаю, потому что шаблоны просто нормальный действительный HTML.

Другие интересные библиотеки шаблонов JS:

Ответ 2

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

Цели дизайна - именно то, чего я пытаюсь достичь с помощью моего текущего проекта. На данный момент я пытаюсь сделать следующее:

Client-Side

Использование Backbone + (здесь используется некоторый шаблонный шаблон)

на стороне сервера

Отображает первый набор html, а также отображает некоторые данные JSON, с которыми может работать Backbone и работать (например, загруженная страница, максимальные страницы и т.д.).

Пример

Клиент загружает: http://mysite.com/blog/archive/5

Сервер отображает:

<html>
    <head>
        <script>
            var data = {
                page:5 // Rendered by Server,
                maxPages: 10
            };

            $(function(){
                // Hook up all Backbone stuff, and hook into interaction events
            });
        </script>
    </head>
    <body>
        <!-- Content -->
    </body>
</html>

Это решает пункты 2 и 3 дизайна: ваш сервер загружает начальное состояние вашего веб-приложения, и пользователь может перемещаться с клиентской стороны оттуда.

С точкой дизайна 1: На стороне клиента все в порядке. Однако для серверной стороны вам нужен механизм js для отображения ваших шаблонов. LinkedIn упоминает об этом в своей статье:

  • Поддержка на стороне сервера:, если у вас есть клиент, который не может выполнить JavaScript, например поисковый робот, страница должна отображаться на стороне сервера. После написания тот же шаблон dust.js может отображаться не только в браузере, но и на сервере с помощью node.js или Rhino.

Итак, вы застряли в двух вариантах:

  • используйте шаблонный движок с node.js или Rhino или
  • найдите шаблонный двигатель с поддержкой в ​​других технологических пакетах.

Как ни странно, благодаря сообщению выше, я понял, что Mustache, которые имеют библиотеки, доступные для большинства обычных стеков, выполняет эту потребность отлично, поэтому я начну смотреть на интеграцию с моим проектом. (Не уверен, есть ли какие-либо библиотеки для Handlebars.js) Это должно позволить нам писать шаблоны Mustache.js как для сервера, так и для клиента, и иметь для них рендеринг html на обоих концах с теми же шаблонами.

РЕДАКТИРОВАТЬ: Не следует ли, чтобы решение "на стороне сервера" не обязательно должно было быть на вашем выбранном языке/стеке. Например, только потому, что вы используете Dust.js, значит, вам нужно закодировать все ваше приложение в node.JS. Возможно, вы сможете получить, выполнив свои скрипты компиляции с помощью команды оболочки.

EDIT: выясняется, что у Усы не существует решения "прекомпиляции", что означает, что шаблоны должны отображаться непосредственно на странице для рендеринга на стороне клиента (таким образом, без кеширования), который не идеален на 100%.

Ответ 3

Я знаю этот старый вопрос, но я как-то попал сюда, так что, возможно, другие это делают.

Я также пытаюсь найти решение для построения RIA, которое будет работать на максимально возможном количестве устройств, реагировать, выполнять и с хорошим ux. Django на бэкэнд с шаблонами реализуется, чтобы иметь возможность корректно отказать при необходимости.

Теперь я просматриваю все эти js-фреймворки, и я немного волнуюсь, в основном о производительности и доступности.

Принимая во внимание, что на сервере внедряются шаблоны, я склоняюсь к решению с выполнением частичных обновлений DOM с html-фрагментами, переданными на бэкэнд, и отправляется на толстый клиент вместо json. Похож на лучший вариант для меня.

Идея взята из: http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering/

С уважением, Mike

Ответ 4

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

Проект, веб-приложение для отладки служб HTTP, находится на GitHub, если вы хотите взглянуть: Spyglass.