Cómo pasar información usando una redirección HTTP (en Django)

Tengo una vista que acepta el envío de un formulario y actualiza un modelo.

Después de actualizar el modelo, quiero redirigir a otra página y quiero que aparezca un mensaje como “Field X actualizado con éxito” en esta página.

¿Cómo puedo “pasar” este mensaje a la otra página? HttpResponseRedirect solo acepta una URL . He visto esto hecho antes en otros sitios. ¿Cómo se logra esto?

Esta es una característica incorporada de Django, llamada “mensajes”

Consulte http://docs.djangoproject.com/en/dev/topics/auth/#messages

De la documentación:

Un mensaje está asociado con un usuario. No hay concepto de caducidad o marcas de tiempo.

Los mensajes son utilizados por el administrador de Django después de acciones exitosas. Por ejemplo, “La encuesta Foo se creó con éxito”. es un mensaje

Puede usar la aplicación django-flashcookie http://bitbucket.org/offline/django-flashcookie/wiki/Home

Puede enviar múltiples mensajes y tener tipos ilimitados de mensajes. Digamos que desea un tipo de mensaje para advertencias y otro para mensajes de error, puede escribir

def simple_action(request): ... request.flash['notice'] = 'Hello World' return HttpResponseRedirect("/") 

o

 def simple_action(request): ... request.flash['error'] = 'something wrong' return HttpResponseRedirect("/") 

o

 def simple_action(request): ... request.flash['notice'] = 'Hello World' request.flash['error'] = 'something wrong' return HttpResponseRedirect("/") 

o incluso

 def simple_action(request): ... request.flash['notice'] = 'Hello World' request.flash['notice'] = 'Hello World 2' request.flash['error'] = 'something wrong' request.flash['error'] = 'something wrong 2' return HttpResponseRedirect("/") 

y luego en tu plantilla mostrarlo con

 {% for message in flash.notice %} {{ message }} {% endfor }} 

o

 {% for message in flash.notice %} {{ message }} {% endfor }} {% for message in flash.error %} {{ message }} {% endfor }} 

Me gustó la idea de usar el marco de mensajes, pero el ejemplo en la documentación de django no funciona para mí en el contexto de la pregunta anterior.

Lo que realmente me molesta, es la línea en los documentos de django:

If you're using the context processor, your template should be rendered with a RequestContext. Otherwise, ensure messages is available to the template context.

lo cual es incomprensible para un novato (como yo) y necesita expandirse, preferiblemente con el aspecto de esas 2 opciones.

Solo pude encontrar soluciones que requerían representación con RequestContext … que no responde a la pregunta anterior.

Creo que he creado una solución para la segunda opción a continuación:

Esperemos que esto ayude a alguien más.

== urls.py ==

 from django.conf.urls.defaults import * from views import * urlpatterns = patterns('', (r'^$', main_page, { 'template_name': 'main_page.html', }, 'main_page'), (r'^test/$', test ), 

== viewtest.py ==

 from django.contrib import messages from django.http import HttpResponseRedirect from django.core.urlresolvers import reverse def test(request): messages.success( request, 'Test successful' ) return HttpResponseRedirect( reverse('main_page') ) 

== viewmain.py ==

 from django.contrib.messages import get_messages from django.shortcuts import render_to_response def main_page(request, template_name ): # create dictionary of items to be passed to the template c = { messages': get_messages( request ) } # render page return render_to_response( template_name, c, ) 

== main_page.html ==

 {% block content %} {% if messages %} 
{% for message in messages %}

{{ message.message }}

{% endfor %}
{% endif %} {% endblock %}

He leído y comprobado todas las respuestas, y me parece que el camino a seguir ahora es usar el marco de mensajería . Algunas de las respuestas son bastante antiguas y probablemente hayan sido de la manera correcta en el momento de la publicación.

Hay muchas soluciones.

1 Use la versión de Django-trunk – admite el envío de mensajes a usuarios anónimos

2 sesiones

 def view1(request): request.session['message'] = 'Hello view2!' return HttpResponseRedirect('/view2/') def view2(request): return HttpResponse(request.session['message']) 

3 redirecciona con param

 return HttpResponseRedirect('/view2/?message=Hello+view2') 

4 cookies

¿Puede pasar el mensaje como un parámetro de consulta a la URL a la que está redirigiendo? No es terriblemente RESTy, pero debería funcionar:

 return HttpResponseRedirect('/polls/%s/results/?message=Updated" % p.id) 

y haga que esa vista busque un parámetro de mensaje, restriegue para nasties y muéstrelo en la parte superior.

Creo que este código debería funcionar para ti

 request.user.message_set.create(message="This is some message") return http.HttpResponseRedirect('/url') 

También puede hacer que la URL de redireccionamiento sea la ruta a una vista ya parametrizada.

urls.py:

 (r'^some/path/(?P\w+)/$', direct_to_template, {'template': 'field_updated_message.html', }, 'url-name' ), 

views.py:

 HttpResponseRedirect( reverse('url-name', args=(myfieldname,)) ) 

Tenga en cuenta que args = necesita tomar una tupla.

La solución utilizada por Pydev UA es la menos intrusiva y puede usarse sin modificar casi nada en su código. Cuando pasa el mensaje, puede actualizar su contexto en la vista que maneja el mensaje y en su plantilla puede mostrarlo.

Utilicé el mismo enfoque, pero en lugar de pasar un texto simple, pasé un dictado con la información en campos útiles para mí. Luego, en la vista, también se actualizó el contexto y luego se devolvió la plantilla renderizada con el contexto actualizado.

Sencillo, efectivo y muy discreto.

Aunque hasta ahora todas las sugerencias funcionan, sugeriría ir con Ry4an’s (páselo en la URL de solicitud): solo cambie el texto real a un texto codificado dentro de un conjunto predefinido de mensajes de texto.

Dos ventajas aquí:

  1. Menos posibilidades de que algo se filtre a través de la limpieza de contenido inadecuado
  2. Puede localizar sus mensajes más tarde si es necesario.

Los otros métodos relacionados con las cookies … bueno, no funcionan si el navegador no admite cookies y son un poco más caros … Pero solo un poco. De hecho, son más limpios para los ojos.