Is it okay to set instance variables in a Django class based view?

Question

I trying out Django's class based views (CBVs).

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

    def get(self, request, **kwargs):
        #more code...

Now, I know that I can get the request params from self.request. Now say I want to parse these request params and store them within the class. Can I store those in self.xxx? Now, obviously based on how classes work, this seems straightforward.

But I can't make out the flow of control, looking at the definition of View (superclass of TemplateView). The source mentions as_view() to be the 'entry-point'

I thought of setting my instance variables at the beginning of get_context_data() but that doesn't seem right to do initialization there.

Can I define an __init__() for my CBV? If so, will there be threading issues or something where multiple page-accesses possibly work with a global instance of my parsed data?

I know this sounds a bit messy, but I'm just a bit confused with the code flow in CBVs.

Answer 1

According to the source of django.views.generic.base.View.as_view:

• on django startup, as_view() returns a function view, which is not called
• on request, view() is called, it instantiates the class and calls dispatch()
• the class instance is thread safe

According to the source of django.views.generic.base.View.__init__, the request object is out of scope at this point so you can't parse it in your own constructor overload.

However, you could parse the request and set class view instance attributes in an overload of django.views.generic.base.View.dispatch, this is safe according to the 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)

Answer 2

@jpic provided a great answer. Inspired from it, I would like to reference the following blog post where the author claims that:

... We cannot override view, as doing so would require overriding as_view(). Overriding dispatch() is appealing (and what I did originally when I presented this talk) because it offers a single simple place to do so, but this defies the logic of dispatch(). Instead, it is best to call set_account() in overrides of both get() and post(). ...

Therefore, one can override the get or post methods and set any self.whatever variables. It feels somehow cleaner.