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

Question

¿Cuál es la diferencia (en el lenguaje que puede entender un python/django noob) en una vista entre render(), render_to_response() y direct_to_template()?

p. Ej. de Nathan Borror's basic apps examples

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, lo que debe usar en cualquier situación particular?

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() es un completamente nuevo acceso directo para render_to_response en 1.3 que utilizará automáticamente RequestContext que yo sin duda será el uso de ahora en adelante.

---

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

render_to_response(template[, dictionary][, context_instance][, mimetype])¶ 

render_to_response es su función estándar utilizado en los tutoriales y tal render. Para utilizar RequestContext tendría que especificar context_instance=RequestContext(request)

---

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

direct_to_template es una vista genérica que utilizo en mis puntos de vista (a diferencia de en mis URL) ya que como la nueva función render(), automáticamente usa RequestContext y todos sus context_processor s.

Pero direct_to_templatedeben evitarse ya que las vistas genéricas basadas en función están en desuso. Utilice render o una clase real, consulte https://docs.djangoproject.com/en/1.3/topics/generic-views-migration/

Estoy contento de no haber escrito RequestContext en mucho, mucho tiempo.

Answer 2

De Django docs:

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

direct_to_template es algo diferente. Es una vista genérica que usa un diccionario de datos para procesar el html sin la necesidad de views.py, lo usa en urls.py. Documentos here

Answer 3

Render es

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

Así que en realidad no hay diferencia entre render_to_response excepto que envuelve su contexto haciendo que la plantilla pre-procesadores de trabajo.

Directo a la plantilla es generic view.

No tiene sentido usarlo aquí porque hay sobrecarga sobre render_to_response en forma de función de visualización.

Answer 4

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

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

• direct_to_template() está diseñado para ser utilizado solo en urls.py sin una vista definida en views.py pero can be used in views.py to avoid having to type RequestContext

• render() es un acceso directo para render_to_response() que suministra automáticamente context_instance=Request .... Su disponible en la versión de desarrollo de Django (1.2.1), pero muchos han creado sus propios accesos directos como this one, this one o la que me lanzó inicialmente, Nathans basic.tools.shortcuts.py

Answer 5

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) 

Lo que el tercer parámetro context_instance hace realidad? Siendo RequestContext establece un contexto básico que luego se agrega al user_context. Entonces la plantilla obtiene este contexto extendido. Las variables que se agregan están dadas por TEMPLATE_CONTEXT_PROCESSORS en settings.py. Por ejemplo, django.contrib.auth.context_processors.auth agrega la variable user y la variable perm a las que se puede acceder en la plantilla.