Class-based Views: Past, Present and Future
summary
Django 1.3 introduces class-based views as a lightweight class wrapper providing method-based HTTP verb dispatch (get/post/options/head) and class-based generic views as composable mix-ins for common patterns (single-object, form handling, template/JSON responses). This gives reusable extension points and cleaner injection of pre/post-save logic, but the generic mix-in graph is complex—dubbed the ravioli problem—and initial documentation is poor. Work items: pick canonical decorator/mixin patterns, improve docs, and explore richer, API-first UI generic views (admin-style class architectures or separate packages).
AI-written summary · about
chapters (11)
- 0:00Start
- 2:24Generic Views
- 6:19Configuration Options
- 14:00Automatic Naive Head Request Handling
- 15:30Class-Based Generic Views
- 17:40Problem Three Ravioli
- 25:25Permissions
- 26:42Permission Checking
- 32:07Api Driven User Interface
- 33:42Api Driven User Interfaces
- 36:50Call to Action
related talks
40mClass-based Views: Past, Present and Future
49mGeneric View? What is that and why would I use it?
24mDemystifying Mixins with Django
27mThe Beauty of ViewSets in Django Rest Framework
27mWhat You Should Know About Django REST Framework
45mJust Add Await: Retrofitting Async Into Django
01h 06mEffective Django
24mThe Ins and Outs of Model Inheritance