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

Какая разница (в языке, который может понять нуб 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)

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

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

РЕДАКТИРОВАТЬ 2020: Следует отметить, что render_to_response()был удален в Django 3.0

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очень долго.

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

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

Прямо к шаблону это общий вид .

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

Из документации Django :

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

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

Просто одну записку я не смог найти в ответах выше. В этом коде:

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которые затем доступны в шаблоне.