Визуализация объектов JSON с использованием шаблона Django после вызова Ajax

Я пытался понять, как оптимально это сделать 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 , потому что это расширенная версия один выше! Я обнаружил, что таким образом поддержка наследования работает намного лучше.

65 голосов | спросил magicrebirth 19 Maypm09 2009, 15:36:21

8 ответов


0

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

Мне тоже нравится использовать декораторы :-). Но в то же время я следовал подходу, предложенному фрагментом, который я упоминал выше. Единственное, используйте вместо этого фрагмент 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)
ответил magicrebirth 19 Maypm09 2009, 22:29:24
0

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

Шаблон:

<div  id="sortable">

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

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

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

Ajax-представление:

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

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

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

ответил vikingosegundo 19 Maypm09 2009, 20:19:13
0

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

ответил Daniel Roseman 19 Maypm09 2009, 17:06:40
0

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

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

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

ответил Anurag Uniyal 19 Maypm09 2009, 15:43:22
0

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

ответил yfeldblum 19 Maypm09 2009, 15:47:12
0

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

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

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

ответил Weiss I Nicht 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 09 Sep 2010 11:36:48 +0400 2010, 11:36:48
0

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

ответил Skylar Saveland 3 MaramThu, 03 Mar 2011 05:30:34 +03002011-03-03T05:30:34+03:0005 2011, 05:30:34
0

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

ответил Casebash 18 J0000006Europe/Moscow 2010, 10:15:13

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132