Django: ¿cuál es la diferencia entre render (), render_to_response () y direct_to_template ()?

¿Cuál es la diferencia (en el lenguaje una pitón / django novato puede entender) en una vista entre render(), render_to_response()y direct_to_template()?

por ejemplo, de los ejemplos de aplicaciones básicas de 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,
    })

Pero también he visto

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

Y

    return direct_to_template(request, template_name, my_data_dictionary)

¿Cuál es la diferencia, qué usar en una situación particular?

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

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

render()es un nuevo atajo completamente nuevo para render_to_response1.3 que usará automáticamente lo RequestContextque definitivamente usaré de ahora en adelante.

EDITAR 2020: Cabe señalar que render_to_response()se eliminó en 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_responsees su función de representación estándar utilizada en los tutoriales y demás. Para usar RequestContexttendrías que especificarcontext_instance=RequestContext(request)

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

direct_to_templatees una vista genérica que uso en mis vistas (a diferencia de mis URL) porque, al igual que la nueva render()función, usa automáticamente RequestContexty todas sus context_processors.

Pero direct_to_template debe evitarse ya que las vistas genéricas basadas en funciones están en desuso. Utilice rendero una clase real, consulte https://docs.djangoproject.com/en/1.3/topics/generic-views-migration/

Estoy feliz de no haber escrito RequestContexten mucho, mucho tiempo.

Reformulando las respuestas de Yuri, Fábio y Frosts para el novato de Django (es decir, yo), casi con toda seguridad una simplificación, pero ¿un buen punto de partida?

• render_to_response()es el "original", pero requiere que ponga context_instance=RequestContext(request)casi todo el tiempo un PITA

• direct_to_template()está diseñado para usarse solo en urls.py sin una vista definida en views.py pero puede usarse en views.py para evitar tener que escribir RequestContext

• render()es un acceso directo render_to_response()que automáticamente proporciona context_instance=Request... Está disponible en la versión de desarrollo de django (1.2.1) pero muchos han creado sus propios accesos directos como este , este o el que me lanzó inicialmente, Nathans basic.tools. atajos.py

Render es

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

Entonces, realmente no hay diferencia entre, render_to_responseexcepto que envuelve su contexto haciendo que los preprocesadores de plantilla funcionen.

Directo a la plantilla es una vista genérica .

Realmente no tiene sentido usarlo aquí porque hay una sobrecarga render_to_responseen forma de función de vista.

De django docs :

render () es lo mismo que una llamada a render_to_response () con un argumento context_instance que fuerza el uso de RequestContext.

direct_to_templateEs algo diferente. Es una vista genérica que usa un diccionario de datos para representar el html sin la necesidad de views.py, lo usa en urls.py. Documentos aquí

Solo una nota que no pude encontrar en las respuestas anteriores. En este código:

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

¿Qué context_instancehace realmente el tercer parámetro ? Al ser RequestContext , establece un contexto básico que luego se agrega user_context. Entonces la plantilla obtiene este contexto extendido. Las variables que se agregan están dadas TEMPLATE_CONTEXT_PROCESSORSen settings.py. Por ejemplo, django.contrib.auth.context_processors.auth agrega variables usery variables permque luego son accesibles en la plantilla.