This was an incredible resource back when CBVs were first introduced. While I tended to prefer function-based views (when I was still heavily using Django), this page was the first one I opened when I knew I was going to be using a CBV.
I'm delighted to see this on the front-page of HN. I hope it's standing up to the HN hug!
It's been a real pleasure to have a hand in something that continues to help people after all this time. CCBV was a group project during a hackday in Feb 2012. Having this here makes me realise that we're only a couple of days past the 10th "birthday" of the website's first commit :)
Edit: As others have pointed out, there's a typo in the title. It should be "Django", rather than "Dango".
I don't know if it's within the rules, but I suggest that the link should be changed too, as the main page (https://ccbv.co.uk/) has more information -- the current article link is to a relatively boring index for the classes in Django 4.0.
I have been a faithful follower of Class Based Views for years just until recently when I got completely immersed into the FBV way of thinking thanks to Luke Plant's excellent write up about Django Views - The Right Way:
I’m learning Django for a personal project and I’ve followed the CBV because that’s what the resources I’m using pushed. Now I’m reading this thinking “ah crap” lol
This is a big improvement to supplement the existing docs, but how does one know what the parameter types are without wading deep into the implementation or trial and error? This has been a major point of frustration for me when interacting with python code (especially someone else's) beyond simple scripts.
Very useful, especially since CBV have terrible ergonomics. They have hidden code path, state and flow everywhere in their thousands methods, MRO to follow, they are verbose and hard to debug (good luck putting a breakpoint in the right place).
I miss generic function views, but you can almost use CBV like them: in your view fuction, do "return YourCBV.as_view(params)" and you are good to go. Much easier than subclassing.
Of course, with FastAPI, we know that there an even better API for that: DI. It's more composable, easier to follow, to test and with less side effects.
I'm against OOP, I use it myself, but you should use it for what it's good at: multiple operations around a central state, crafting an api with __dunder__ methods, and namespacing related data and operations.
33 comments
[ 1.8 ms ] story [ 71.2 ms ] threadI think you mean Django.
Maybe it enforces a strict "no J's" paradigm? No JSON, JavaScript, etc.
Alas...
https://www.youtube.com/watch?v=XXDxZ0YGWG8
Thanks to the authors/maintainers!
I'm delighted to see this on the front-page of HN. I hope it's standing up to the HN hug!
It's been a real pleasure to have a hand in something that continues to help people after all this time. CCBV was a group project during a hackday in Feb 2012. Having this here makes me realise that we're only a couple of days past the 10th "birthday" of the website's first commit :)
Edit: As others have pointed out, there's a typo in the title. It should be "Django", rather than "Dango".
I don't know if it's within the rules, but I suggest that the link should be changed too, as the main page (https://ccbv.co.uk/) has more information -- the current article link is to a relatively boring index for the classes in Django 4.0.
https://spookylukey.github.io/django-views-the-right-way/
Reading Luke's articles brought me back to FBVs, now I avoid CBVs whenever I can and feel happier for it.
The CCBV site from the original post seems nice and handy though.
Many people say that CBVs is Django on Rails but Rails doesn't use multiple inheritance or complicated MRO.
It requires too much knowledge on part of the developer and is generally an abstraction for the sake of abstraction.
Simple functions are much clearer!
It was trivially easy to add authentication, caching, multiple response types and other magic without bothering the rest of the dev team.
I miss generic function views, but you can almost use CBV like them: in your view fuction, do "return YourCBV.as_view(params)" and you are good to go. Much easier than subclassing.
Of course, with FastAPI, we know that there an even better API for that: DI. It's more composable, easier to follow, to test and with less side effects.
django-ninja (https://github.com/vitalik/django-ninja/) already offers a lot of that for Django, and I hope it will become a huge success. It is however, currently thinking of using classes somewhere to reuse init view code, so I made a proposal to extend the API design around more flexible approacheshttps://github.com/vitalik/django-ninja/issues/15#issuecomme...
I'm against OOP, I use it myself, but you should use it for what it's good at: multiple operations around a central state, crafting an api with __dunder__ methods, and namespacing related data and operations.