#31949: Allow builtin view decorators to be applied directly to async views.
--------------------------------+-------------------------------------
Reporter: Michael Galler | Owner: Ben Lomax
Type: New feature | Status: assigned
Component: Core (Other) | Version: 3.1
Severity: Normal | Resolution:
Keywords: async | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+-------------------------------------
Comment (by Ben Lomax):
Thank you for your review, it's always very appreciated. I'll try to
address each of your points as best as I understand things:
1. **Complexity / forced implementation:** The utility function was my
attempt to make the decorator function work more similarly to the mixin
classes, which look for `process_request` and `process_response`
attributes amongst others. However, it might be that we don't want
decorator ''functions'' to mirror the decorator ''class'' pattern, and so
I'm happy to move away from it.
2. **Sync-only `process_X` functions:** As it stands, I would suggest that
allowing for async passed-in functions (e.g. the `etag_func` argument of
the `@condition` decorator) should be pushed back into a separate piece of
work after this one. It seems to me that converting the builtin decorators
to be async-able at the cost of only allowing sync functions to be passed
to them is a good iterative step forward.
3. **The `contrib.auth` decorators:** Fair point, I can cover those too.
4. **`sync_and_async_middleware` never checked in functions:** Correct me
if I've misunderstood this, but I thought that the decorator wasn't for
internal use, but was used by external code as a way of knowing if the
middleware could handle sync and/or async view functions. For example,
when layering middleware it would help Django figure out if it needed to
"adapt the request to fit the middleware's requirements" (as per [the
docs](https://docs.djangoproject.com/en/4.1/topics/http/middleware
/#asynchronous-support)).
5. **async-switch inline:** I think this should be possible for any
decorators which only act of the request. If a decorator needs to act on
the response, we need to await the view to get the response, _and then_
act on that response. If this isn't acceptable, we might be able to do
something with partial functions perhaps, but that seems like a non-
trivial jump in complexity.
6. **implementation that adjusts the wrapped callback:** I'll be honest, I
don't think I understand your suggestion here. Are you suggesting we
somehow flag a `process_request` function to be run when the `BaseHandler`
handles the async view? I think this would mean defining the response
processing in the decorator, but not actually running it "within the
decorator".
A good follow up question feels like is: is there a way to break this work
up logically to give partial functionality quicker? For example, only
doing this for decorators which don't act on the view response?
--
Ticket URL: <https://code.djangoproject.com/ticket/31949#comment:22>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/01070184a9037e17-8c3123c4-c802-4d88-8fe1-0de97780841c-000000%40eu-central-1.amazonses.com.
