[pyar] [django] Reemplazo de variables en template con render_to_response()

[fisa]

2010/11/11 Eugenia Bahit #KittyTux <eugeniabahit en gmail.com>:
> El 11 de noviembre de 2010 00:11, fisa <fisadev en gmail.com> escribió:
>>
>>
>> Hacerte tu propia vista de login no es complicado, basicamente tendrías
>> que:
>>  * hacer una vista donde:
>>    * dentro de la vista, loguee al usuario (normalmente en el post).
>> Info de como hacerlo en [0]
>>    * si el usuario se logueo correctamente, redireccionar a la url
>> que recibiste en el parámetro get "next"
>>  * setear en los settings la LOGIN_URL
>>
>> Es un poco tricky, en especial por lo del next. El flujo sería básicamente
>> así:
>> 1) el usuario pide una url, ej: "/mi_perfil/"
>> 2) el decorador de login_required ve que la vista que se va a ejecutar
>> necesita login, y el usuario no esta logueado. Así que redirecciona a
>> la url: settings.LOGIN_URL + "?next=" + url que se pidió y no se puede
>> acceder. Si la LOGIN_URL es "/login/", en este caso redireccionaría a
>> "/login/?next=/mi_perfil/"
>> 3) se ejecuta tu vista de login, como GET, así que mostrarás tu
>> template de login al usuario.
>> Pero ojo! Acá es donde recibís el next, no en el POST! Así que tenés
>> que tener algún mecanismo para que cuando te hagan el POST de login,
>> "recuerdes" cual era el valor que ahora estás recibiendo en el GET.
>> Podés ponerlo en el formulario de login, como un campo oculto, es lo
>> más recomendable.
>> 4) el usuario escribe sus datos, click en logín, se hace un POST a tu
>> vista de login.
>> 5) tu vista de login ahora llamada desde el POST, hace la
>> autenticación, y si fue correcta redirecciona a lo que había en el
>> valor next. En este caso, a "/mi_perfil/". (Si habías puesto el valor
>> del next en tu formulario, lo vas a estar recibiendo como dato de POST
>> ahora, lo que es sencillo de leer)
>> 6) ahora la vista original va a poder accederse, porque el usuario ya
>> está logueado.
>>
>> Se entiende? Cualquier cosa preguntá.
>>
>> Peeeero, me queda en el tintero: por qué querés hacer tu propia vista
>> de login? si es para pasar datos a los templates, seguramente son
>> datos que tooodas tus vistas pasan, y por ende lo recomendable sería
>> que lo metas en un context processor. Con el context processor te
>> ahorrás dos problemas: pasarlos siempre, y hacer tu propia vista de
>> login :)
>> Si querés te comento como es eso.
>>
>> Saludos!
>>
>> [0] http://docs.djangoproject.com/en/dev/topics/auth/#how-to-log-a-user-in
>>
>> --
>> fisa  -  Juan Pedro Fisanotti
>> _______________________________________________
>
> Másssssssssssss claro, echémosle agua! Clarísimo!!! Millon of zenkius!!!!!
> xDDD
>
> Te cuento bien para que es lo del login ya que, por lo que estuve leyendo
> sumado a lo que me comentás, CREO que lo del context processor es lo que
> posiblemente esté buscando.
>
> El login en sí, simplemente es porque el acceso a la app estará restringido
> a quien tenga un password para hacer uso de la misma.
>
> Todos los datos que necesito pasarle al template, son constantes (que en
> este caso, a lo bruto, mandé la data como venía en un diccionario, ya
> cansada de no poder resolverlo). Estas constantes, la idea es definirlas en
> el archivo constants.py y son puramente para cuestiones estéticas que ayuden
> a modificar fácilmente el estilo de los templates (logotipo, colores y
> cosillas de ese tipo).
>
> La idea de tener estos datos como constantes y - en principio - en un
> archivo separado (luego irán a una base de datos, espero...) y no poner el
> dato directamente en el template, es porque:
> - tal vez algunos datos sea necesario utilizarlos más de una vez en
> distintos templates
> - porque la app estará destinada a usuarios comunes y corrientes que si
> quieren cambiar alguna cuestión estética, la idea es que puedan hacerlo
> mediante un formulario que los guíe.
>
> Vale aclarar, que estos datos deben renderearse/renderizarse (nunca voy a
> decidir cual de los dos términos usar) aunque el usuario no se haya logueado
> aún.
>
> Si hubiera algo que me permitiera pasar esta data en un diccionario dentro
> del patrón del urls.py, algo así como:
> (r'.*accounts/login_submit/$', 'django.contrib.auth.views.login',
> {'template_name': 'registration/login.html'}, {'datos_adicionales':
> fuckin_datos}) por poner un ejemplo, sería MUYYYYYY FELIZ!
>
> Gracias again!!!
>
> Eugenia.
>

Para eso entonces realmente te conviene usar un context processor.
Lo hacés creando una función que recibe una request como parámetro, y
devuelve un diccionario con los datos que quieras pasar al template.

Después agregas esa función a la lista del setting
TEMPLATE_CONTEXT_PROCESSORS (ojo, si no la tenés, vas a tener que
agregarla a mano con el tuyo y todos los de django por defecto [0]).

Y después de eso, en tus vistas siempre que hagas un
render_to_response, tenés que pasarle el request context, así:

render_to_response('algo.html', valores_de_la_vista,
context_instance=RequestContext(request))

(necesitás importar RequestContext: from django.template import RequestContext)

Si no hacés eso, no van a procesarse los context processors.

Saludos!


[0] para django 1.2 el valor por defecto es:

TEMPLATE_CONTEXT_PROCESSORS = ("django.contrib.auth.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n",
"django.core.context_processors.media",
"django.contrib.messages.context_processors.messages")

-- 
fisa  -  Juan Pedro Fisanotti