Month: March 2022

Here’s my “quick reference” on the Django ListView method execution order and how to override them:

__init__()
Standard when instance of class is created

setup()
Initializes: self.request, self.args, and self.kwargs

Overriding this method allows mixins to setup instance attributes for reuse in child classes. When overriding this method, you must call super().

dispatch()
Re-directs at GET to get(), POST to post(), etc.

http_method_not_allowed()
Called only when dispatch() cannot properly dispatch to GET

get()
Calls methods in the following order:

get_template_names()
Simple method that gets either (but not both):
– the template_name from a variable
– the object modelname

get_queryset()
Gets the queryset; must be an iterable

get_context_object_name()
Simple method that gets either:
– the template_name from a variable context_object_name
– the object model_name appended with _list

get_context_data()
Sets the viewbag/dictionary for the Jinja template

render_to_response()
This is called last using return keyword to return a “response_class” instance to dispatch()

---

Important Notes: if you override get(), you must explicitly call get_queryset() and get_context_data() in your own version of get(). You might also need to implement both methods as well.

You can implement any or all 4 methods, but you aren’t required to override get(). The dispatch() method will do that.

The most common configuration is to implement your own get_queryset() and (sometimes) implement get_context_data() calling the super() method first. The custom get_context_data() method allows you to “tack on” extra context.

See the official Django ListView docs for more details: https://docs.djangoproject.com/en/dev/ref/class-based-views/generic-display/#listview