Changes between Initial Version and Version 3 of Ticket #33611
- Timestamp:
- Mar 31, 2022, 2:10:36 AM (3 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #33611
- Property Cc added
- Property Component HTTP handling → Generic views
-
Ticket #33611 – Description
initial v3 1 1 The current [https://docs.djangoproject.com/en/4.0/topics/async/#async-views topic docs for Async views] say this about class-based views: 2 2 3 > For a class-based view, this means making its __call__() method an async def (not its __init__() or as_view()).3 > For a class-based view, this means making its `__call__()` method an async def (not its `__init__()` or `as_view()`). 4 4 5 5 This isn't really appropriate for Django's class-based views: 6 6 7 * We don't implement `__call__()`, rather going via `as_view() — for a per-request instance — and then `dispatch()`.8 * Users expect to implement the HTTP method handlers — `get `, `post`, and so on — rather than these ''more internal'' bits.7 * We don't implement `__call__()`, rather going via `as_view()` — for a per-request instance — and then `dispatch()`. 8 * Users expect to implement the HTTP method handlers — `get()`, `post()`, and so on — rather than these ''more internal'' bits. 9 9 10 10 Ideally we'd allow specifying `async def` at the method handler level, to allow using `await` in the handler, and writing views such as this: