pelicula - Django: ¿Por qué debería usar alguna vez render_to_response?

django wikipedia

Question

considera esto:

return render(request, ''index.html'', {..context..})
return render_to_response(''index.html'', {..context..})

Por un lado, el render es más limpio y más pitón. Por otro lado, utiliza la request como su primer argumento, que encuentro redundante y confuso. Entonces empecé a preguntarme sobre las diferencias más grandes ...

Según los documentos :

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

Así que la diferencia es solo en usar RequestContext. Entonces, ¿qué es importante sobre RequestContext? Echemos un vistazo a los documentos de nuevo :

una clase de contexto especial [...] actúa de manera ligeramente diferente a la normal django.template.Context. La primera diferencia es que toma un HttpRequest como su primer argumento.

De acuerdo. Eso no importa en absoluto

La segunda diferencia es que automáticamente llena el contexto con algunas variables, de acuerdo con su configuración de TEMPLATE_CONTEXT_PROCESSORS [...] Además de estas, RequestContext siempre usa django.core.context_processors.csrf [...] está deliberadamente codificado y no se puede desactivar con la configuración TEMPLATE_CONTEXT_PROCESSORS.

Así que esta es la parte importante: asegurarse de que todos los procesadores de contexto funcionen correctamente, con énfasis en csrf. Entonces, para volver a mi primer ejemplo, estos son en realidad los mismos:

return render(request, ''index.html'', {...})
return render_to_response(''index.html'', {...}, context_instance=RequestContext(request))

Ahora, el segundo ejemplo es obviamente mucho peor, todo parece lamentablemente demasiado complicado. Así que mi gran pregunta es ¿Por qué usar render_to_response en absoluto? ¿Por qué no desaprobarlo?

Otras preguntas que vienen a la mente:

1. ¿No hay una mejor manera de imponer RequestContext como predeterminado?
2. ¿Hay una manera de evitar pasar la request como un argumento? Es terriblemente redundante. Encontré una publicación de blog que muestra cómo convertir render_to_response en un decorador fácil de usar. ¿No podemos hacer algo similar con render ?
3. ¿Hay algún pensamiento sobre este tema (si es un problema)? No veo nada de eso en la futura línea de tiempo de desprecio . Lo encuentro especialmente confuso, considerando que el render surgió con django 1.3 específicamente para resolver los problemas con render_to_response , y que todos están de acuerdo en que no debería usar render_to_response

Sé que parece un poco fuera de tema, pero espero obtener respuestas que expliquen por qué render_to_response se mantiene y / o ejemplos de casos de uso en los que se render_to_response usar render_to_response en lugar de render (si hay alguno)

Answer 1

Demasiado largo; no leí

When context processors are applied

Cuando usa RequestContext , las variables que proporciona directamente se agregan primero, seguidas de cualquier variable proporcionada por los procesadores de contexto. Esto significa que un procesador de contexto puede sobrescribir una variable que haya suministrado, así que tenga cuidado de evitar nombres de variables que se superpongan con los suministrados por sus procesadores de contexto.

Veamos primero cómo se definen los métodos render_to_response y render .

def render_to_response(*args, **kwargs):
"""
Returns a HttpResponse whose content is filled with the result of calling
django.template.loader.render_to_string() with the passed arguments.
"""
httpresponse_kwargs = {''content_type'': kwargs.pop(''content_type'', None)}
return HttpResponse(loader.render_to_string(*args, **kwargs), **httpresponse_kwargs)
def render(request, *args, **kwargs):
"""
Returns a HttpResponse whose content is filled with the result of calling
django.template.loader.render_to_string() with the passed arguments.
Uses a RequestContext by default.
"""
httpresponse_kwargs = {
''content_type'': kwargs.pop(''content_type'', None),
''status'': kwargs.pop(''status'', None),
}
if ''context_instance'' in kwargs:
context_instance = kwargs.pop(''context_instance'')
if kwargs.get(''current_app'', None):
raise ValueError(''If you provide a context_instance you must ''
''set its current_app before calling render()'')
else:
current_app = kwargs.pop(''current_app'', None)
context_instance = RequestContext(request, current_app=current_app)
kwargs[''context_instance''] = context_instance
return HttpResponse(loader.render_to_string(*args, **kwargs),
**httpresponse_kwargs)

¿No hay una mejor manera de imponer RequestContext como predeterminado?

Nota en la sección Subclassing Context: RequestContext

Si está utilizando el render_to_response abreviado render_to_response Django para rellenar una plantilla con el contenido de un diccionario, su plantilla pasará una instancia de Context de manera predeterminada (no un RequestContext )

Desde el código anterior, el método render_to_response llama al método loader.render_to_string donde se context_instance parámetro context_instance en esta línea .

Listado de códigos para el método loader.render_to_string

def render_to_string(template_name, dictionary=None, context_instance=None,
dirs=None):
"""
Loads the given template_name and renders it with the given dictionary as
context. The template_name may be a string to load a single template using
get_template, or it may be a tuple to use select_template to find one of
the templates in the list. Returns a string.
"""
dictionary = dictionary or {}
if isinstance(template_name, (list, tuple)):
t = select_template(template_name, dirs)
else:
t = get_template(template_name, dirs)
if not context_instance:
return t.render(Context(dictionary))
# Add the dictionary to the context stack, ensuring it gets removed again
# to keep the context_instance in the same state it started in.
with context_instance.push(dictionary):
return t.render(context_instance)

¿No podemos hacer simple de usar decorador con render ?

Podemos escribir decorador para esto, pero su pregunta es subjetiva. Si es fácil de usar o no es difícil de decir. Depende mucho

¿Hay una manera de evitar pasar la solicitud como un argumento?

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

class RequestContext se define en esta línea . Listado de códigos para la class RequestContext

class RequestContext(Context):
"""
This subclass of template.Context automatically populates itself using
the processors defined in TEMPLATE_CONTEXT_PROCESSORS.
Additional processors can be specified as a list of callables
using the "processors" keyword argument.
"""
def __init__(self, request, dict_=None, processors=None, current_app=None,
use_l10n=None, use_tz=None):
Context.__init__(self, dict_, current_app=current_app,
use_l10n=use_l10n, use_tz=use_tz)
if processors is None:
processors = ()
else:
processors = tuple(processors)
updates = dict()
for processor in get_standard_processors() + processors:
updates.update(processor(request))
self.update(updates)

La última pregunta no necesita una respuesta, si comprende cómo funciona realmente el código detrás de Django.

Answer 2

La mayoría de las aplicaciones usan render_to_response ya que era la opción recomendada por defecto desde el principio hasta Django 1.3. El motivo de la coexistencia de ambos es histórico, desaprobar render_to_response obligará a que se reescriba una gran cantidad de código, lo que no es correcto en versiones menores. Sin embargo, en este hilo de django-developer dicen que sería posible incluir en la línea de tiempo de desaprobación para 2.0.

Aquí está la cita de Russell Keith-Magee , uno de los principales desarrolladores de Django. Keith-Magee responde a una pregunta publicada por Jacob Kaplan-Moss, otro colaborador de Django que plantea la cuestión de desaprobar render_to_response :

Creo que deberíamos desaprobar render_to_response () a favor de render (). render_to_response () es solo render (request = None, ...), ¿verdad? ¿Alguna razón para mantener ambos alrededor? No hay ninguna razón en particular para mantener a los dos, aparte de la rotación de códigos que implicaría la depreciación.

Y Keith-Magee responde:

Esto es algo que no tengo ningún problema en desaprobar en la programación 2.0, pero migrar cada uso de render_to_response () durante los próximos 18 meses / 2 lanzamientos parece ser una medida extrema para imponer en toda la base de usuarios cuando mantener render_to_response () no toma cualquier esfuerzo real.

Nadie ha estado discutiendo esa desaprobación, pero supongo que la respuesta a tu pregunta es: no hay ninguna razón técnica, es solo su intención de no forzar una actualización de toda la base de código en una versión menor (al menos no importante).