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

¿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() ?

Por ejemplo, a partir de 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 cualquier 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 método abreviado de render_to_response para render_to_response en 1.3 que automáticamente utilizará RequestContext que definitivamente render_to_response 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 de render estándar utilizada en los tutoriales y similares. Para usar RequestContext deberías 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 uso en mis vistas (a diferencia de en mis direcciones URL) porque, al igual que la nueva función render() , utiliza automáticamente RequestContext y todos sus context_processor .

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

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

Replanteando las respuestas de Yuri, Fábio y Frosts para el noob Django (es decir, yo), es casi seguro que es una simplificación, pero ¿un buen punto de partida?

  • render_to_response() es el “original”, pero requiere que se context_instance=RequestContext(request) en 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 se puede usar en views.py para evitar tener que escribir RequestContext

  • render() es un acceso directo para render_to_response() que proporciona automáticamente 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.shortcuts.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) 

Por lo tanto, realmente no hay diferencia entre render_to_response excepto que envuelve su contexto haciendo que la plantilla de preprocesadores funcione.

Directo a la plantilla es una vista genérica .

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

De los documentos django:

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

direct_to_template es algo diferente. Es una vista genérica que utiliza un diccionario de datos para representar el html sin la necesidad de views.py, se usa en urls.py. Docs aqui

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é hace el tercer parámetro context_instance realidad? Al ser RequestContext , configura un contexto básico que luego se agrega a user_context . Así que 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 el user variable y la variable perm que luego son accesibles en la plantilla.