Визуализация объектов JSON с использованием шаблона Django после вызова Ajax - PullRequest
65 голосов
/ 19 мая 2009

Я пытался понять, какой оптимальный способ сделать Ajax в Django . Читая кое-что, я понял, что общий процесс:

  1. сформулируйте ваш Ajax-вызов, используя некоторую библиотеку JavaScript (например, jQuery ), настройте шаблон URL в Django, который перехватывает вызов и передает его функции просмотра

  2. в функции просмотра Python извлекает интересующие вас объекты и отправляет их обратно клиенту в формате JSON или аналогичном (с помощью встроенного модуля сериализатора или simplejson) )

  3. определяет функцию обратного вызова в JavaScript, которая получает данные JSON и анализирует их, чтобы создать любой HTML-код, необходимый для отображения. Наконец, скрипт JavaScript помещает HTML туда, где он должен оставаться.

Теперь, что я до сих пор не понимаю, это как шаблоны Django связаны со всем этим? Очевидно, мы вообще не используем всю мощь шаблонов. В идеале я подумал, что было бы неплохо передать обратно объект JSON и имя шаблона, чтобы можно было выполнить итерацию данных и создать блок HTML. Но, может быть, я здесь совершенно не прав ...

Единственный ресурс, который я нашел в этом направлении, это этот фрагмент (769) , но я еще не пробовал. Очевидно, что в этом случае произойдет то, что весь полученный HTML создается на стороне сервера, а затем передается клиенту. Функция обратного вызова JavaScript должна отображать ее только в нужном месте.

Это вызывает проблемы с производительностью? Если нет, даже без использования приведенного выше фрагмента, почему бы не отформатировать HTML-код непосредственно в бэкэнде, используя Python вместо внешнего интерфейса?

Большое спасибо!

ОБНОВЛЕНИЕ: используйте фрагмент 942 , потому что это расширенная версия приведенного выше! Я обнаружил, что поддержка наследования работает намного лучше при этом ..

Ответы [ 8 ]

25 голосов
/ 19 мая 2009

Эй, спасибо, Викингосегундо!

Мне тоже нравится использовать декораторы :-). Но в то же время я следовал подходу, предложенному фрагментом, который я упоминал выше. Единственное, используйте вместо фрагмент n. 942 , потому что это улучшенная версия оригинала. Вот как это работает:

Представьте, что у вас есть шаблон (например, 'subtemplate.html') любого размера, содержащий полезный блок, который вы можете использовать повторно:

     ........
    <div id="results">          
        {% block results %}
            {% for el in items %}
                   <li>{{el|capfirst}}</li>
            {% endfor %}
        {% endblock %}      
    </div><br />
     ........

Импортируя в свой файл просмотра фрагмент выше, вы можете легко ссылаться на любой блок в ваших шаблонах. Интересная особенность заключается в том, что учитываются отношения наследования между шаблонами, поэтому, если вы ссылаетесь на блок, который включает в себя другой блок и т. Д., Все должно работать нормально. Итак, ajax-view выглядит так:

from django.template import loader
# downloaded from djangosnippets.com[942]
from my_project.snippets.template import render_block_to_string

def ajax_view(request):
    # some random context
    context = Context({'items': range(100)})
    # passing the template_name + block_name + context
    return_str = render_block_to_string('standard/subtemplate.html', 'results', context)
    return HttpResponse(return_str)
13 голосов
/ 19 мая 2009

Вот как я использую один и тот же шаблон для традиционного рендеринга и рендеринга Ajax-ответа.

Шаблон:

<div  id="sortable">

{% include "admin/app/model/subtemplate.html" %}
</div>

Включенный шаблон (он же: подшаблон):

<div id="results_listing">
{% if results %}
    {% for c in results %}
        .....
    {% endfor %}
{% else %}

Аякс-просмотр:

@login_required
@render_to('admin/app/model/subtemplate.html')#annoying-decorator
def ajax_view(request):
    .....

    return { 
        "results":Model.objects.all(),
    }      

Конечно, вы можете использовать render_to_response. Но мне нравятся эти надоедливые декораторы: D

7 голосов
/ 19 мая 2009

Нет причин, по которым вы не можете вернуть бит HTML с использованием Ajax и вставить его на существующую страницу в нужной вам точке. Очевидно, что вы можете использовать шаблоны Django для рендеринга этого HTML, если хотите.

6 голосов
/ 19 мая 2009

Когда вы делаете Ajax, я не думаю, что вы используете шаблоны. Шаблон существует для того, чтобы вы могли легко генерировать динамический HTML на стороне сервера, и, следовательно, он обеспечивает несколько программных хуков внутри HTML.

В случае Ajax вы передаете данные JSON и можете отформатировать их в Python. и HTML / элементы документа будут генерироваться на стороне клиента с использованием JSON некоторой библиотекой JavaScript, например, JQuery на стороне клиента.

Может быть, если у вас есть очень специфический случай замены некоторого внутреннего HTML-кода на стороне сервера HTML, то, возможно, вы можете использовать шаблоны, но в таком случае зачем вам нужен JSON? Вы можете просто запросить страницу HTML через Ajax и изменить внутренний или внешний или любой другой HTML.

3 голосов
/ 09 сентября 2010

Хотя шаблоны действительно предназначены только для презентаций, не должно иметь значения, выполняете ли вы их на стороне сервера или на стороне клиента. Все сводится к отделению логики управления, выполняющей действие, от логики представления, которая просто отвечает за создание разметки. Если вашей логике управления javascript приходится обрабатывать то, как вы отображаете или отображаете HTML, вы можете делать это неправильно, но если вы изолируете эту логику рендеринга от другого объекта или функции и просто передаете ей данные, необходимые для рендеринга, тогда ты должен быть в порядке; это отражает то, как мы разделяем наши контроллеры, модели и представления на стороне сервера.

Взгляните на проект github: http://github.com/comolongo/Yz-Javascript-Django-Template-Compiler

Он компилирует шаблоны django в оптимизированные функции javascript, которые будут генерировать HTML-презентацию с данными, которые вы передаете. Скомпилированные функции в чистом javascript, поэтому нет никаких зависимостей от других библиотек. Поскольку шаблоны компилируются, а не анализируются во время выполнения, все строки и переменные уже помещены в строки javascript, которые просто необходимо объединить, поэтому вы получаете огромное увеличение скорости по сравнению с методами, которые требуют от вас сделать манипуляцию домом или синтаксический анализ, чтобы получить окончательную презентацию. Прямо сейчас есть только основные теги и фильтры, но их должно быть достаточно для большинства вещей, и будет добавлено больше тегов, когда люди начнут делать запросы на них или начнут вносить свой вклад в проект.

3 голосов
/ 19 мая 2009

Шаблоны предназначены для представления . Ответ с данными в формате X (JSON, JSONP , XML, YAML , * ml и т. Д.) Не является представлением, поэтому вам не нужны шаблоны. Просто сериализуйте ваши данные в формат X и верните их в HttpResponse.

1 голос
/ 03 марта 2011

Вы можете использовать jquery.load() или аналогичный, генерируя HTML на сервере и загружая его в DOM с помощью JavaScript. Я думаю, что кто-то назвал это AJAH .

0 голосов
/ 18 июня 2010

К сожалению, шаблоны Django предназначены для выполнения только на стороне сервера. Существует по крайней мере один проект для визуализации шаблонов Django с использованием Javascript, но я не использовал его, и поэтому я не знаю, насколько он быстр, хорошо поддерживается или актуален. Кроме этого, вы должны либо использовать шаблоны Django на сервере, либо генерировать динамические элементы на клиенте без использования шаблонов.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...