6 ms·
Dango Views Cheatsheets
- atum47 5y agoDjango*
- bkovacev 5y agoI assume this should be renamed to Django Views Cheatsheets instead of Dango Views Cheatsheets?
- punnerud 5y agoYes, a typo from me and too late to change/edit now without help from one of the mods
- 0xbadc0de5 5y ago> Dango Views Cheatsheets I think you mean Django.
- nahimn 5y agoThe J is silent
- otachack 5y agoTime to fork Django into "Dango"! Maybe it enforces a strict "no J's" paradigm? No JSON, JavaScript, etc.
- toyg 5y agoI was hoping it was a new clever framework to avoid writing Javascript, hence no J. Alas...
- julianwachholz 5y agoClearly they meant the ending song of Clannad. :) https://www.youtube.com/watch?v=XXDxZ0YGWG8 https://www.youtube.com/watch?v=XXDxZ0YGWG8
- PennRobotics 5y ago@djang can you fix this title?
- kbrannigan 5y agoThat's why HN is the best place.
- athorax 5y agoGosh dango it!
- dd82 5y agohttps://cdrf.co/ https://cdrf.co/ is DRF's counterpart. Both are pretty essential and informative for Django devs.
- avidal 5y agoThis 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!
- ryannevius 5y agoThis website was absolutely indispensable for me, when CBVs were introduced. Really glad to see it still up and running!
- meshy 5y agoCCBV'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/ https://ccbv.co.uk/) has more information -- the current article link is to a relatively boring index for the classes in Django 4.0.
- jonatron 5y agoFirst: 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.
- meshy 5y agoThank you for the heads up on that! I think I should have the caching configured better now :)
- 0x0000000 5y agoAs a user of CCBV for eight or so years now, thank you very much for creating and maintaining this resource.
- julianwachholz 5y agoI 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/ https://spookylukey.github.io/django-views-the-right-way/
- glomph 5y agoThanks!
- culopatin 5y agoI’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
- grizwaldo 5y agoSimilar 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.
- jmconfuzeus 5y agoSame 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.
- greenie_beans 5y agowow, 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!
- adrianh 5y agoI’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!
- tingletech 5y agoDjango with a j
- sirodoht 5y agoHow come this has not become part of the official Django docs?
- riverdroid 5y agoThis 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.
- deleted 5y ago[deleted]
- BiteCode_dev 5y agoVery 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/ 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#issuecomment-1030673844 https://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.