python - tutorial - django views

¿Está bien establecer variables de instancia en una vista basada en clase Django?

Question

Probando las vistas basadas en la clase de Django (CBV).

class BlahView(TemplateView):
template_name = ''blah/blah.html''
def get_context_data(self, **kwargs):
#code...
def get(self, request, **kwargs):
#more code...

Ahora, sé que puedo obtener los parámetros de solicitud de self.request. Ahora diga que quiero analizar estos parámetros de solicitud y almacenarlos dentro de la clase. ¿Puedo almacenar esos en self.xxx ? Ahora, obviamente, basado en cómo funcionan las clases, esto parece sencillo.

Pero no puedo distinguir el flujo de control, mirando la definición de View (superclase de TemplateView ). La source menciona que as_view() es el ''punto de entrada''

Pensé en establecer mis variables de instancia al comienzo de get_context_data() pero eso no parece correcto para hacer la inicialización allí.

¿Puedo definir un __init__() para mi CBV? Si es así, ¿habrá problemas de subprocesos o algo en el que varios accesos de página posiblemente funcionen con una instancia global de mis datos analizados?

Sé que esto suena un poco desordenado, pero estoy un poco confundido con el flujo de código en los CBV.

Answer 1

@jpic dio una gran respuesta. Inspirado en esto, me gustaría hacer referencia a la siguiente publicación del blog donde el autor afirma que:

... No podemos anular la vista, ya que hacerlo requeriría anular as_view (). Sobresalir dispatch () es atractivo (y lo que hice originalmente cuando presenté esta charla) porque ofrece un solo lugar simple para hacerlo, pero esto desafía la lógica de dispatch (). En su lugar, es mejor llamar a set_account () en anulaciones tanto de get () como post (). ...

Por lo tanto, uno puede anular los métodos get o post y establecer cualquier variable self.whatever . Se siente de alguna manera más limpio.

Answer 2

De acuerdo con la fuente de django.views.generic.base.View.as_view :

• en el inicio de django , as_view () devuelve una view función, que no se llama
• a petición , se llama a view() , crea una instancia de la clase y llama a dispatch()
• la instancia de clase es segura para subprocesos

De acuerdo con el origen de django.views.generic.base.View.__init__ , el objeto de solicitud está fuera de alcance en este punto, por lo que no puede analizarlo en su propia sobrecarga de constructor.

Sin embargo, puede analizar la solicitud y establecer los atributos de instancia de vista de clase en una sobrecarga de django.views.generic.base.View.dispatch , esto es seguro de acuerdo con la source :

class YourView(SomeView):
def dispatch(self, request, *args, **kwargs):
# parse the request here ie.
self.foo = request.GET.get(''foo'', False)
# call the view
return super(YourView, self).dispatch(request, *args, **kwargs)