Dango Views Cheatsheets | Hacker News Reader

Dango Views Cheatsheets

ccbv.co.uk

89 pointspunnerud32 comments

CCBV's (Classy Class-Based Views) primary maintainer here.

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.

First: thank you. Second, Re: HN Hug, I see the header

    cf-cache-status: DYNAMIC

Maybe you should double check your caching? Edit: You've fixed it, it's faster now.

Thank you for the heads up on that! I think I should have the caching configured better now :)

As a user of CCBV for eight or so years now, thank you very much for creating and maintaining this resource.

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:

https://spookylukey.github.io/django-views-the-right-way/

Similar experience. CBVs didn't exist when I started using Django, but I switched over to using them almost exclusively when they were introduced.

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.

Same here. I find that FBVs are more explicit and easier to deal with. That's why it's easier to onboard junior devs in a project built with FBVs.

Many people say that CBVs is Django on Rails but Rails doesn't use multiple inheritance or complicated MRO.

wow, i've been using django for like a year and a half, and this articulates a lot of the pains i've had. thank you for sharing!

I’m one of the creators of Django and I’d personally never write a class-based view.

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!

I think they're great when you need to extend a bunch of views at the same time without changing their core logic.

It was trivially easy to add authentication, caching, multiple response types and other magic without bothering the rest of the dev team.

Thanks!

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

https://cdrf.co/ is DRF's counterpart. Both are pretty essential and informative for Django devs.

I find I don't need the DRF one because it's flatter, DRF DestroyAPIView has 4 ancestors compared to 8 in Django DeleteView.

https://cdf.9vo.lt/ might also be of interest. It's a similar website for Django's Forms.

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.

Thanks to the authors/maintainers!

> Dango Views Cheatsheets

I think you mean Django.

The J is silent

Time to fork Django into "Dango"!

Maybe it enforces a strict "no J's" paradigm? No JSON, JavaScript, etc.

I was hoping it was a new clever framework to avoid writing Javascript, hence no J.

Alas...

Clearly they meant the ending song of Clannad. :)

https://www.youtube.com/watch?v=XXDxZ0YGWG8

@djang can you fix this title?

That's why HN is the best place.

Gosh dango it!

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.

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.

This website was absolutely indispensable for me, when CBVs were introduced. Really glad to see it still up and running!

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.

I assume this should be renamed to Django Views Cheatsheets instead of Dango Views Cheatsheets?

Yes, a typo from me and too late to change/edit now without help from one of the mods

How come this has not become part of the official Django docs?

Django with a j

Django*

Reply on news.ycombinator.com