On Wed, Nov 20, 2019 at 11:52 PM James Bennett <[email protected]> wrote:
> On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney <[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]. > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKbzzst8PxCr8q26UfYzLAZKi6fqQV9nUjpotkFb%2Byo1w%40mail.gmail.com.
