Django - в чому різниця між render (), render_to_response () та direct_to_template ()?

Яка різниця (мовою пітон / 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)

Яка різниця, що використовувати в будь-якій конкретній ситуації?

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те, що я зараз напевно буду використовувати.

EDIT 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)майже весь час вводити ПДФА.

• 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 () з аргументом контексту_речовини, який змушує використовувати RequestContext.

direct_to_templateце щось інше. Це загальний вигляд, який використовує словник даних для візуалізації html без необхідності view.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які потім доступні в шаблоні.