Django - в чем разница между render (), render_to_response () и direct_to_template ()?

Question

В чем разница (на языке, который понимает нуб python / django) в представлении между 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)

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

Answer 1

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_processor s.

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

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

Answer 2

Перефразируя ответы Юрия, Фабио и Фроста для нуба Джанго (то есть меня) - почти наверняка упрощение, но хорошая отправная точка?

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

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

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

Answer 3

Визуализация -

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, за исключением того, что она оборачивает ваш контекст, заставляя препроцессоры шаблона работать.

Прямо к шаблону - generic view .

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

Answer 4

Из django docs :

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

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

Answer 5

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

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

Что на самом деле делает третий параметр context_instance? Будучи RequestContext , он устанавливает некоторый базовый контекст, который затем добавляется к user_context. Таким образом, шаблон получает этот расширенный контекст. Какие переменные добавляются, задается TEMPLATE_CONTEXT_PROCESSORS в settings.py. Например, django.contrib.auth.context_processors.auth добавляет переменную user и переменную perm, которые затем доступны в шаблоне.