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

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

например. из Основные примеры приложений Nathan Borror

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)

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

Ответы

Ответ 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 в течение долгого времени.

Ответ 2

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

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

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

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

Ответ 3

Render -

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.

Ответ 4

Из django docs:

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

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

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