Django-в чем разница между render(), render to response() и direct to template()?

в чем разница (на языке python/django noob может понять) в представлении между render(), render_to_response() и direct_to_template()?

, например,Натан Тайлер Хичкок это

def comment_edit(request, object_id, template_name='comments/edit.html'):
    comment = get_object_or_404(Comment, pk=object_id, user=request.user)
    # ...
    return render(request, template_name, {
        'form': form,
        'comment': comment,
    })

но я также видел

    return render_to_response(template_name, my_data_dictionary,
              context_instance=RequestContext(request))

и

    return direct_to_template(request, template_name, my_data_dictionary)

какая разница, что использовать в любой конкретной ситуации?

5 ответов


https://docs.djangoproject.com/en/1.8/topics/http/shortcuts/#render

render(request, template[, dictionary][, context_instance][, content_type][, status][, current_app])

render() - это совершенно новый ярлык для render_to_response в 1.3, который будет автоматически использовать RequestContext что я определенно буду использовать с этого момента.


https://docs.djangoproject.com/en/1.8/topics/http/shortcuts/#render-to-response

render_to_response(template[, dictionary][, context_instance][, mimetype])¶

render_to_response ваша стандартная функция рендеринга используется в учебниках и такие. Использовать RequestContext вы должны указать context_instance=RequestContext(request)


https://docs.djangoproject.com/en/1.8/ref/generic-views/#django-views-generic-simple-direct-to-template

direct_to_template - это общее представление, которое я использую в своих представлениях (в отличие от моих URL-адресов), потому что как новый render() функция, она автоматически использует RequestContext и все context_processors.

но direct_to_template следует избегать как основанные на функции общие представления не одобрять. Либо используйте render или фактический класс, см. https://docs.djangoproject.com/en/1.3/topics/generic-views-migration/

Я счастлив, что не набрал RequestContext в долгое, долгое время.


перефразирование ответов Юрия, Фабио и Фростов для Django noob (т. е. меня) - почти наверняка упрощение, но хорошая отправная точка?

  • render_to_response() является "оригинальным", но требует от вас сдачи context_instance=RequestContext(request) почти все время, Пита.

  • direct_to_template() конструировано быть использованным как раз внутри urls.py без представления, определенного в views.py но это!--15-->смогите быть использовано внутри views.py чтобы избежать необходимости печатать Объекта RequestContext

  • render() ярлык для render_to_response() это автоматически поставляет context_instance=Request.... Он доступен в версии разработки django (1.2.1), но многие создали свои собственные ярлыки, такие как этот, этот или тот, который бросил меня изначально, Натанс basic.tools.shortcuts.py


визуализация

def render(request, *args, **kwargs):
    """ Simple wrapper for render_to_response. """
    kwargs['context_instance'] = RequestContext(request)
    return render_to_response(*args, **kwargs)

Так что на самом деле нет никакой разницы между render_to_response кроме этого обертывания контекста, что делает шаблон предварительно процессоры работают.

Direct to template - это универсальный вид.

нет смысла использовать его здесь, потому что есть накладные расходы над render_to_response в виде функции зрения.


С Django docs:

render() совпадает с вызовом render_to_response() с аргумент context_instance, что заставляет использовать RequestContext.

direct_to_template Это что-то другое. Это общее представление, которое использует словарь данных для отображения html без необходимости views.py, вы используете его в urls.py - ... Docs здесь


только одна заметка, которую я не мог найти в ответах выше. В этом коде:

context_instance = RequestContext(request)
return render_to_response(template_name, user_context, context_instance)

какой третий параметр context_instance на самом деле? Бытие RequestContext он устанавливает некоторый базовый контекст, который затем добавляется в user_context. Таким образом, шаблон получает этот расширенный контекст. Какие переменные добавляются, задается TEMPLATE_CONTEXT_PROCESSORS in settings.py - ... Например, Джанго.ВНО.автор.context_processors.двиг добавляет переменную user и переменная perm которые после этого доступны в шаблон.