Class-based Views: Past, Present and Future
summary
Class-based views arrive in Django 1.3 as a replacement for function-based generics and land with real costs and benefits the commit turns one edit view function into nine classes so extension points exist but the learning curve is steep initial docs are poor and no formset support exists yet yet the model admin already shows the approach can work suggesting a path to API-driven UIs and a possible migration of admin into a class-based framework documentation has since improved
AI-written summary · about
chapters (16)
- 0:00Start
- 0:58In the beginning...
- 2:15Key features
- 2:25Example: Before
- 8:00REFACTOR
- 9:13What went wrong?
- 12:19Class Based Views
- 13:42CB Generic Views
- 17:33Mixins
- 22:02Example: After CBGV
- 26:36Documentation
- 31:38Modern problems
- 35:16API-driven UI in Django
- 36:14django.contrib.admin
- 38:41Call to action
- 39:57Questions?
related talks
40mClass-based Views: Past, Present and Future
49mGeneric View? What is that and why would I use it?
41mWhat is the Django admin good for?
29mPushing The Pony's Boundaries - Django Admin Customization
27mThe Beauty of ViewSets in Django Rest Framework
24mDemystifying Mixins with Django
19mPatterns for Extensibility
28mDo Your Views Know Too Much?