I agree with Adam that it should be deprecated with no replacement. The content negotiation is something that should be in but not as a replacement of it, as a general improvement.
I think there shouldn't be a replacement because "is_ajax" asks whether it came from a ""regular"" browser instead of jQuery and with the content negotiation you ask if the requester accepts a type - which can also lead to errors because the client may also accept other types (no example coming to my mind), and if so, it will lead to undesired behavior. The right approach would be making AJAX requests request JSON output explicitly, by using a dedicated endpoint or by appending something that manifests their intention - like in https://docs.djangoproject.com/en/2.2/topics/class-based-views/mixins/#more-than-just-html is done with a get parameter. Not decide the response type by where it came from as it is unreliable as stated before, it provides convenience in some use cases but can lead to errors. Seems better to me to refactor the view code so you can write a different view for Ajax requests that returns a JSON without code duplication. As a shortcut, something like "For simple AJAX endpoints wrap your view with (something like) a "jsonview" decorator which will check the accept header (with something like Claude's code), return the appropriate error code if not, set the response type accordingly, and you should return a dict of strings (you have to take care of the serialization, i.e with https://docs.djangoproject.com/en/2.2/topics/serialization/#serialization-formats-json). On Mon, Nov 18, 2019 at 3:28 PM Tom Forbes <t...@tomforb.es> wrote: > What I meant by that is it’s not an approach that scales well to lots of > views. It might be better to have separate endpoints to return JSON (e.g > adding a /json suffix), and in the past this has made services I’ve worked > on a lot more maintainable and easy to understand. But it’s not as quick to > do as `if request.is_ajax()` and requires a bit more upfront work. If you > find you need to do this a lot then maybe something more structured like > Django Rest Framework will be a better choice, which also handles content > negotiation really well (it can produce XML, CSV, JSON, etc etc). > > On 18 Nov 2019, at 15:18, Matthew Pava <matthew.p...@iss.com> wrote: > > “In my opinion there are not many good reasons to have to change behaviour > if a request is made via XHR. I think the most common usage is to have a > single view that returns a JSON response or a HTML response depending on if > XHR is used ( > https://github.com/search?l=Python&q=request.is_ajax&type=Code), which > isn’t great and isn’t reliable.” > > I do this. What would the best way to handle this? Perhaps the proper > practice should be documented when it is deprecated? > > *From:* django-developers@googlegroups.com [ > mailto:django-developers@googlegroups.com > <django-developers@googlegroups.com>] *On Behalf Of *Tom Forbes > *Sent:* Saturday, November 16, 2019 10:16 AM > *To:* django-developers@googlegroups.com > *Subject:* Re: Deprecate HttpRequest.is_ajax > > I would agree. Flask has done the same: > > DeprecationWarning: Request.is_xhr is deprecated. Given that the > X-Requested-With header is not a part of any spec, it is not reliable > > In my opinion there are not many good reasons to have to change behaviour > if a request is made via XHR. I think the most common usage is to have a > single view that returns a JSON response or a HTML response depending on if > XHR is used ( > https://github.com/search?l=Python&q=request.is_ajax&type=Code), which > isn’t great and isn’t reliable. > > > > On 16 Nov 2019, at 16:08, Adam Johnson <m...@adamj.eu> wrote: > > Django's HttpRequest.is_ajax method determines whether the request was > made with the JS API XMLHttpRequest > https://docs.djangoproject.com/en/2.2/ref/request-response/#django.http.HttpRequest.is_ajax > . It does so by checking the X-Requested-With header. > > The new way of making "AJAX" requests from the browser is the JavaScript > fetch() API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API . > > I think the is_ajax() documentation is at least a little misleading in > pretending XMLHttpRequest is the only JS API. There also aren't any special > headers set by fetch() so it's not possible to detect its requests. > > I propose deprecating is_ajax() with no replacement. > > Thoughts? > > -- > Adam > > -- > 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 django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMyDDM0i-p0ZxBj-fSheGs-2pMXH7K7Oka%3DCjy1YXx-emBu3mw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAMyDDM0i-p0ZxBj-fSheGs-2pMXH7K7Oka%3DCjy1YXx-emBu3mw%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 django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es > <https://groups.google.com/d/msgid/django-developers/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es?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 django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/cb12b0005c5e4191be3a97d0d2c44cc5%40iss2.ISS.LOCAL > <https://groups.google.com/d/msgid/django-developers/cb12b0005c5e4191be3a97d0d2c44cc5%40iss2.ISS.LOCAL?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 django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/DA72EC9C-AE24-4C04-854A-A6E19DD64132%40tomforb.es > <https://groups.google.com/d/msgid/django-developers/DA72EC9C-AE24-4C04-854A-A6E19DD64132%40tomforb.es?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 django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnh%2B5xr1fWteL6bh2NhF0yJV%3DPwyvhkiLYyPmGO23q0sZ9w%40mail.gmail.com.
