I want ask a question regarding creating a string,why while creating a string where user give the input,there are different references of that object
On Mon, Nov 18, 2019, 8:58 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/CAAh_qstvPiBfPKK666UzDmgApF6KWVNYUVHTTurVb1UEK9hx4w%40mail.gmail.com.
