python - site - django wikipedia

Django: tener middleware comunicarse con vistas/plantillas

Question

Muy bien, esta es probablemente una pregunta muy tonta, pero soy nuevo en Python / Django, así que no puedo entender bien sus conceptos de alcance todavía. En este momento estoy escribiendo una clase de middleware para manejar algunas cosas, y quiero establecer variables ''globales'' a las que puedan acceder mis vistas y plantillas. ¿Cuál es la forma "correcta" de hacer esto? Consideré hacer algo como esto:

middleware.py

from django.conf import settings

class BeforeFilter(object):
    def process_request(self, request):
        settings.my_var = ''Hello World''
        return None

views.py

from django.conf import settings
from django.http import HttpResponse

def myview(request):
    return HttpResponse(settings.my_var)

Aunque esto funciona, no estoy seguro si es la "forma de Django" o la "forma de Python" de hacer esto.

Entonces, mis preguntas son:
1. ¿Es esta la manera correcta?
2. Si es el camino correcto, ¿cuál es la forma correcta de agregar variables que se pueden usar en la plantilla real desde el middleware? Supongamos que quiero evaluar algo y quiero establecer un nombre de headername variable como ''Mi nombre de sitio'' en el middleware, y quiero poder hacer {{ headername }} en todas las plantillas. Haciéndolo de la forma en que lo tengo ahora, tendría que agregar el nombre del headername al contexto dentro de cada vista. ¿Hay alguna forma de evitarlo? Estoy pensando en algo parecido a $this->set(''headername'',''My Site Name''); de CakePHP $this->set(''headername'',''My Site Name'');
3. Estoy usando la clase de middleware como un equivalente de beforeFilter de CakePHP que se ejecuta antes de que se beforeFilter cada vista (o controlador en CakePHP). ¿Es esta la manera correcta de hacer esto?
4. Completamente relacionado pero es una pequeña pregunta, ¿cuál es una buena manera de imprimir los contenidos de una variable en el navegador ala print_r ? Supongamos que quiero ver todas las cosas dentro de la request que se pasa a la vista? ¿Es pprint la respuesta?

Answer 1

1. No es la mejor manera. Puede establecer my_var en la solicitud en lugar de en la configuración. La configuración es global y se aplica a todo el sitio. No desea modificarlo para cada solicitud. Podría haber problemas de concurrencia con la actualización de varias solicitudes / leyendo la variable al mismo tiempo.

2. Para acceder a request.my_var en sus plantillas, puede hacer {{request.my_var}} . Para acceder a la variable de solicitud en su plantilla, deberá agregar django.core.context_processors.request a su configuración TEMPLATE_CONTEXT_PROCESSORS .

3. Sí. Otra terminología para describir el middleware de solicitud sería solicitar pre-procesador / filtro / interceptor.

Además, si desea utilizar un nombre de sitio común para el encabezado en sus plantillas, es posible que desee verificar la aplicación de sitios de Django que proporciona una variable de nombre de sitio para su uso.

Answer 2

1) Si modifica ''configuración'', esto será global incluso en todas las solicitudes. En otras palabras, las solicitudes concurrentes van a pisotearse entre sí si necesita que cada solicitud tenga su propio valor. Es más seguro modificar el objeto de solicitud en sí, que es lo que hace el middleware de Django común (por ejemplo, django.contrib.auth.middleware.AuthenticationMiddleware agrega una referencia a ''usuario'' en el objeto de solicitud)

2) (EDIT 2) Vea # 4, obtener un conjunto común de variables en cada plantilla probablemente sea más adecuado para un procesador de contexto personalizado

3) No estoy familiarizado con CakePHP, pero agregar un middleware process_request definitivamente es una buena manera de preprocesar cada solicitud de Django.

4) Eche un vistazo al documento para los procesadores de contexto de la plantilla . Si usa RequestContext, cada plantilla tendrá una variable de contexto llamada ''solicitud'' que puede volcar a su plantilla. También puede usar el procesador de contexto de depuración y hacer algo como esto, de modo que solo se vuelque cuando configure.DE.DE = Verdadero:

{% if debug %}
  <!-- {{ request.REQUEST }} -->
{% endif %}

Esto funcionará tanto para GET como para POST, pero puede modificarlo en consecuencia si solo necesita uno o el otro.

EDITAR

Además, solo miré más de cerca a tus views.py No estoy seguro de entender por completo lo que está tratando de hacer allí simplemente devolviendo la variable en la respuesta. Si realmente tiene ese caso de uso, probablemente también quiera configurar el tipo mimet de esta manera:

return HttpResponse (..., mimetype=''text/plain'')

Eso es solo para ser explícito de que no está devolviendo HTML, XML u otro tipo de contenido estructurado.

EDIT 2

Acabo de ver que la pregunta se actualizó con una nueva subestación, respuestas renumeradas

Answer 3

Esto es lo que hacemos. Usamos un procesador de contexto como este ...

def context_myApp_settings(request):
    """Insert some additional information into the template context
    from the settings.
    Specifically, the LOGOUT_URL, MEDIA_URL and BADGES settings.
    """
    from django.conf import settings
    additions = {
        ''MEDIA_URL'': settings.MEDIA_URL,
        ''LOGOUT_URL'': settings.LOGOUT_URL,
        ''BADGES'': settings.BADGES,
        ''DJANGO_ROOT'': request.META[''SCRIPT_NAME''],
    }
    return additions

Aquí la configuración que activa esto.

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",
    "myapp. context_myApp_settings",
    )

Esto proporciona información "global" en el contexto de cada plantilla que se procesa. Esta es la solución estándar de Django. Consulte http://docs.djangoproject.com/en/dev/ref/templates/api/#ref-templates-api para obtener más información sobre los procesadores de contexto.

"¿Cuál es una buena forma de imprimir los contenidos de una variable en el navegador ala print_r?"

En la vista? Puede proporcionar una cadena pprint.pformat a una plantilla que se procesará con fines de depuración.

En el registro? Tienes que usar el módulo de logging de Python y enviar cosas a un archivo de registro separado. El uso de declaraciones de impresión simples para escribir cosas en el registro no funciona maravillosamente de manera consistente para todas las implementaciones de Django (mod_python, por ejemplo, pierde todas las cosas de stdout y stderr).