ifequal - En Django, ¿es posible acceder a la sesión de usuario actual desde una etiqueta personalizada?
templates dirs django (5)
Puede hacerlo con procesadores de contexto personalizados (consulte http://docs.djangoproject.com/en/dev/ref/templates/api/ )
En este caso, crearía un nuevo archivo llamado context_processors.py en el mismo nivel que su archivo settings.py, que contiene:
def add_session(request):
return {''session'': request.session}
Luego, en su archivo settings.py, agregue:
TEMPLATE_CONTEXT_PROCESSORS = ("django.core.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n",
"django.core.context_processors.media",
''context_processors.add_session'',)
Ahora podrá consultar el contexto [''session''] en su etiqueta personalizada.
Tenga en cuenta que esto solo funcionará para las plantillas procesadas con un RequestContext asignado, como en el siguiente código:
def test(request):
return render_to_response(''test.html'',{}, context_instance=RequestContext(request))
Estoy escribiendo una etiqueta personalizada en Django que debe mostrar un valor almacenado en una sesión de usuario, pero no puedo encontrar una manera de acceder al objeto de sesión desde una función de etiqueta personalizada. ¿Hay alguna manera de hacerlo, sin asignar manualmente el objeto de sesión a una variable de contexto?
Lo encontré útil: http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser
Puede usar el middleware para tomar la información del usuario y almacenarla con un hilo local, y luego usarla con su definición de etiqueta.
Sin ánimo de ofender a Sebastian, parece que fue un truco útil en un punto, pero curiosamente el 24 de diciembre en una entrada de blog sobre el acceso a los datos del usuario en el administrador, James Bennett, gerente de publicación de Django, dijo lo siguiente sobre el uso del threadlocal hackear
Un gran descargo de responsabilidad: hay muchos usos potenciales para este tipo de características. Muchos de ellos están equivocados y estúpidos y no deberías probarlos. ... Además, de vez en cuando verá a alguien sugerir que estas características se pueden obtener mediante lo que se conoce como el "hack threadlocal"; esto básicamente implica colocar request.user en una especie de variable mágica disponible a nivel mundial, y es una cosa muy mala de usar si no sabes lo que estás haciendo. En general, también es algo muy malo de usar incluso si sabes lo que estás haciendo, ya que probablemente solo lo estés haciendo porque eres perezoso y no tienes ganas de asegurarte de pasar la información correctamente. Entonces, si ves a alguien sugiriendo que hagas esto usando un "threadlocal", ignora a esa persona.
No digo que deba ignorar a Sebastian, pero podría valer la pena buscar otras vías en lugar de usar threadlocal, que no se considera una mejor práctica.
Debería poder agregar el procesador de contexto de solicitud en su archivo settings.py:
TEMPLATE_CONTEXT_PROCESSORS = ("django.core.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n",
"django.core.context_processors.media",
''django.core.context_processors.request'',)
Esto hará lo mismo que la respuesta actual, sin tener que agregar un archivo personalizado.
Usar render_to decorator desde django-annoying parece ser la mejor opción (como se ve en otra pregunta en )