articles/2025/django-views/

[giscus[bot]]

articles/2025/django-views/

Why I only use Django's base View class instead of generic class-based views or function-based views.

https://www.loopwerk.io/articles/2025/django-views/?utm_campaign=Django%2BNewsletter&utm_medium=email&utm_source=Django_Newsletter_300

[jfmatth]

Nice article, thanks for sharing.

[MHLut]

Interesting idea, and I'm trying this approach now in one of my hobby projects.

One request for the implementation examples: also add the import paths for the Django requirements, like TemplateResponse.

[kevinrenskers]

Good point! I've updated the article.

[danilovmy]

A funny article. The author doesn't want to remember other “magic” methods and still uses magic such as get_object_or_404, redirect, or something else.
And if the author wants to avoid code duplication, he puts the code in “dispatch.” How did he change dispatch? Using the same code as is in get_object method from SingleObjectMixin. Probably, a one-line mixin in the class definition is easier than import + method override + ...

The author's approach shows that he probably does not understand an important idea of GCBV: the declarative way.

A declarative way means less testing.
A declarative way means less complexity (for example, you can use Halstead metrics).
A declarative way means less cyclomatic complexity.
A declarative way means less documentation.

I agree with this article if the author earns money based on the number of lines of code. In this case, Black-formatter can also help to get many more lines.

[kevinrenskers]

I actually explicitly said that I don’t use the dispatch method myself. It’s just there to point out the “textbook” solution.

Also, how are get_object_or_404 and redirect "magic"? They are the complete opposite! You explicitly import them, you call them yourself, there is absolutely no magic involved. Such a bad faith argument you're making here.

It’s fine if you don’t agree with the article, but there is no need for your sarcasm.

[alexandremjacques]

I have the exact same approach. Having the request.method == 'POST' everywhere seems much like a hack. Specially since it's another code execution branch to worry about.

One question: put of curitosity, why you return TemplateResponses instead of calling the render() function?

[kevinrenskers]

One question: put of curitosity, why you return TemplateResponses instead of calling the render() function?

See https://spookylukey.github.io/django-views-the-right-way/the-pattern.html for an explanation:

The issue with just using render is that you get a plain HttpResponse object back that has no memory that it ever came from a template. Sometimes, however, it is useful to have functions return a value that does remember what it’s “made of” — something that stores the template it is from, and the context. This can be really useful in testing, but also if we want to something outside of our view function (such as decorators or middleware) to check or even change what’s in the response before it finally gets ‘rendered’ and sent to the user.

For now, you can just accept that TemplateResponse is a more useful return value than a plain HttpResponse. (If you are already using render everywhere, there is absolutely no need to go and change it though, and almost everything in this guide will work exactly the same with render instead of TemplateResponse).

It often is more useful so I just use it all the time for consistency. It's also about removing one more abstraction layer.

Also sometimes I return a subclass of TemplateResponse, for example to work with htmx / Alpine AJAX. Search for AlpineTemplateResponse on https://www.loopwerk.io/articles/2025/alpine-ajax-django/. So I just never use render() to keep things consistent.

[rocha6464]

Thanks for sharing! As you have recommended, I have replaced generic CBVs with the base View class in a Django/Alpine Ajax project, and find that it is immediately clearer what I need to code to implement the logic. I use my time and effort more productively to implement features rather than trying to understand how the CBV classes hang together. The downside is more lines of code, but that is an acceptable price to pay.

I suspect I will continue to use the generic CBVs to implement simple and straight-forward view logic, but I now have a better approach to implementing custom view logic when that is required. Thanks once again!