This DjangoProject page on Generic Display Views seems to be the most helpful, imo.
It covers both ListView and DetailView and explains in detail the methods executed in a class-based display view — Here’s an example of DetailView methods called:
Actually, you’re really doing it upside down. Instead of a central
ClubView, it’s more flexible to have one view class for each of the individual actions/pages. E.g., you might have something like this:
model = Club
model = Club
This way you only need to override specific functionality unique to each of those actions, by defining a particular method on the view class which does what you need. E.g. you need to filter the possible Clubs in the
ClubListView dynamically, based on something from the request? Just override the
ClubListView.get_queryset method to apply the appropriate filter.
If there is some really peculiar behaviour that needs to be applied to all the views, it depends on what this behaviour really is about: if it’s related to this specific model, it should probably best be defined in the model itself, or perhaps its manager; and if it’s really something specific to the views, you should write and extend a mixin along with the actual view class.
- Celery workers unable to connect to redis on docker instances
- Took too long to shut down and was killed
- Django – Extending another apps ModelAdmin?
dispatch is called before
post – or, for that matter,
get depending on the request. Overriding it should let you set extra information.
The docs lack detail – I didn’t really get it until I read the source. But the source is nicely readable except for being spread across multiple files.
You could write a
get_club method in your parent class. You can then use this in your subclasses, and you don’t have to repeat the logic.
- Clone an inherited django model instance
- How do you update a django template context variable after an AJAX call?