If possible, could the logic determining "the best match for your
options" be overridable?
That way standard implementation would cater for 80/20 and everyone
would still have an option to customise further.
LP,
Jure
On 21/11/2019 02:22, Matemática A3K wrote:
On Wed, Nov 20, 2019 at 11:52 PM James Bennett <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney
<[email protected] <mailto:[email protected]>> wrote:
Yeah, I expected DRF had this "solved" already. From my own
experimentation, mapping `cgi.parse_header` over the the
"Accept" header value, split by comma, gets a usable result;
then sort that list by 'q' (defaulting to 1.0) and you have
your priority.
Both the original and forks seem to've been abandoned now, but the
mimeparse library encapsulated this into a nice little function
that took an Accept header, and a list of content-types you could
support in the response, and told you which one was the best
match. The code's still out there and under a permissive license
if somebody wants to pick it up again.
I think now that providing alternatives is the way to go :)
When 'is_ajax' is used for content negotiation, then proper content
negotiation via the Accept headers should be done.
When 'is_ajax' is used for different content delivery (like routing),
then make the convention explicit or refactoring should be done.
|
|
|In the case of content negotiation -
https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation
- this is only about media types (Accept-Language is already parsed in
i18n).|
|
|
|Just parsing them it and make them available in the request -
filtered by the supported ones - as an ordered list
("accepted_media_types") and the preferred one
("preferred_media_type") seems sufficient to me.|
|
|
|For functional views, it would be up to you to decide which one you
support and how it is delivered with something like "if 'json' in
request.preferred_media_type:". We can add decorators for setting the
response type for a specific media type and optionally returning a 406.
|
|
|
|For CBVs, a mixin should be done - something like
ContentNegotiationMixin - where you define the the types you want to
support in it (or otherwise use the settings) and you should define or
override methods like "to_JSON", "to_XML", "to_LABEL" that will
serialize your context into the media type that is the best match for
your options.
|
|
|
||
|As more than one media type may correspond to one format, if a dict
that labels the supported types is defined, something like:|
|
|
|SUPPORTED_MEDIA_TYPES_LABELS = {|
| "application/json": "JSON",|
| "text/json": "JSON",|
| "application/pdf": "PDF",|
| "text/html": "HTML",|
|}
|
||
||
|
|
|All the filtering can be easily done.
|
|
|
||
||
||
If so, the deprecation warning should be something like:
|DeprecationWarning: Request.is_ajax is deprecated. Given that the
X-Requested-With header is not a part of any spec, it is not reliable.
If you are doing content negotiation, see
..docs/media_type_negotiation. If you are serving different content if
the requests are made via AJAX, choose a convention for *your* project
to discern them or consider refactoring your code (making your views
specific to one intent for each verb).|
||
|
|
|If you agree - in general - with this direction, I can find time to
implement it.
|
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAL13Cg9x9ZWM0LTLoMMF%3DxgMydqrOKhEnhsRn-miFkVk5Rx6tg%40mail.gmail.com
<https://groups.google.com/d/msgid/django-developers/CAL13Cg9x9ZWM0LTLoMMF%3DxgMydqrOKhEnhsRn-miFkVk5Rx6tg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKbzzst8PxCr8q26UfYzLAZKi6fqQV9nUjpotkFb%2Byo1w%40mail.gmail.com
<https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKbzzst8PxCr8q26UfYzLAZKi6fqQV9nUjpotkFb%2Byo1w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" 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-developers/9c3dd791-bed0-6c73-d40a-0462c4e93a1a%40gmail.com.
