python - tutorial - django windows
Django: ¿cuál es la diferencia entre render(), render_to_response() y direct_to_template()? (5)
¿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?
De los docs django:
render () es lo mismo que una llamada a render_to_response () con un argumento context_instance que fuerza el 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
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 ajusta 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.
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 secontext_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 RequestContextrender()
es un acceso directo pararender_to_response()
que proporciona automáticamentecontext_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
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.
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)
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.