Re: Deprecate HttpRequest.is_ajax

On Wed, Nov 20, 2019 at 11:52 PM James Bennett wrote: > On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney > 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

Re: Deprecate HttpRequest.is_ajax

Not so sure though, but would like to know if https://github.com/python-hyper these libraries are of any use for django http? On Thursday, November 21, 2019 at 5:52:12 AM UTC+6, James Bennett wrote: > > On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney > wrote: > >> >> Yeah, I expected DRF had thi

Re: Deprecate HttpRequest.is_ajax

On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney 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

Re: Deprecate HttpRequest.is_ajax

On Thu, 21 Nov 2019, at 09:25, Tom Forbes wrote: > > If Django were to provide a solid API for parsing Accept headers [not as > > easy as it sounds] and selecting a preferred response type [based on accept > > preference weights] ... would that take care of the bulk of "content > > negotiation

Re: Deprecate HttpRequest.is_ajax

> If Django were to provide a solid API for parsing Accept headers [not as easy > as it sounds] and selecting a preferred response type [based on accept > preference weights] ... would that take care of the bulk of "content > negotiation”? > I could imagine a view progressing past the boiler pl

Re: Deprecate HttpRequest.is_ajax

Le 20.11.19 à 22:46, Curtis Maloney a écrit : > My reading of this discussion boils down to "if we get rid of is_ajax (a > buy-in convention nobody can rely on), how do people decide if it's an > AJAX call or not?". To my mind, the "content negotiation" advocates have > it right: HTTP has a mechani

Re: Deprecate HttpRequest.is_ajax

My reading of this discussion boils down to "if we get rid of is_ajax (a buy-in convention nobody can rely on), how do people decide if it's an AJAX call or not?". To my mind, the "content negotiation" advocates have it right: HTTP has a mechanism for determining what response format is desired.

Re: The Missing Piece in Indexing

Hi Behzad Your database will automatically use the appropriate indexes for given queries, thanks to its optimizer. See https://en.m.wikipedia.org/wiki/Query_optimization and DB specific docs such as: https://www.postgresql.org/docs/9.0/planner-optimizer.html , https://dev.mysql.com/doc/internals/e

The Missing Piece in Indexing

Hey all! I noticed a while ago that we can set indexes in the models Meta as described here . But I can't find any commands on the Queryset which helps us use the declared indexes, the equivalent of `USE INDEX` in the DB. Is th

Re: Deprecate HttpRequest.is_ajax

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 wrote: > What I meant by that is it’s not an approach that scales well to lots of > views. It might be be

Re: Deprecate HttpRequest.is_ajax

Agree. I understood that the discussion already turned to /"//If it is deprecated, then the question that arises naturally is "What would be the proper/new way of doing it?"//"/. Also, to clarify: What I wrote wasn't trying to impose a particular solution. I was just hoping to point out the