>> "I want A, B, C or D - I can give you B or D - Then D - OK"
Yes, this. As long as I have the chance to determine B & D BEFORE the
content negotiation is complete. As opposed to having them fixed in code
by e.g. specifying to_json & to_html methods.
LP,
Jure
On 22/11/2019 02:04, Matemática
On Thu, Nov 21, 2019 at 3:03 AM Jure Erznožnik
wrote:
> If possible, could the logic determining "the best match for your options"
> be overridable?
>
Actually it is quite straightforward, the client set in the header of its
request all the media types it wants ("accepts as a response") with a
pr
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
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
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
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
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
ate 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 upfro
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
y 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 mo
roups.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 depreca
[mailto:django-developers@googlegroups.com]*On Behalf
Of*Tom Forbes
*Sent:*Saturday, November 16, 2019 10:16 AM
*To:*django-developers@googlegroups.com
<mailto:django-developers@googlegroups.com>
*Subject:*Re: Deprecate HttpRequest.is_
gt;
>>> On 18 Nov 2019, at 15:18, Matthew Pava 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 r
;> 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
o:django-developers@googlegroups.com]*On Behalf Of*Tom Forbes
*Sent:*Saturday, November 16, 2019 10:16 AM
*To:*django-developers@googlegroups.com
<mailto:django-developers@googlegroups.com>
*Subject:*Re: Deprecate HttpRequest.is_ajax
I would agree. Flask has done the same:
legroups.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
gt; practice should be documented when it is deprecated?
>
> From: django-developers@googlegroups.com
> [mailto:django-developers@googlegroups.com] On Behalf Of Tom Forbes
> Sent: Saturday, November 16, 2019 10:16 AM
> To: django-developers@googlegroups.com
> Subject: Re: D
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
I think this is a good starting point. What do we think about adding a
“accepts_json” helper of some kind? It seems that the vast, vast majority of
usages I can find of “is_ajax” is to return a JSON response, which I feel could
be served nicely with a helper. There are also, annoyingly, two diff
I'm afraid that implementing a whole content negociation framework is a bit
ambitious, unless someone has much time to devote to that.
We could start smaller, similar to django-accept-header. I quickly sketched
what it could look like in:
https://github.com/django/django/compare/master...claudep
any plan with
https://github.com/django/deps/blob/master/draft/content-negotiation.rst
one?
On Sunday, November 17, 2019 at 2:00:26 PM UTC+6, Adam Johnson wrote:
>
> Right - Flask's error message also points to something I was mistaken
> about. XMLHttpRequest does not set this header. jQuery ad
Hi.
I would be really favorable suggested approach which would open up more
possibilities to responses. And in general sounds good direction.
su 17. marrask. 2019 klo 10.00 Adam Johnson kirjoitti:
> Right - Flask's error message also points to something I was mistaken
> about. XMLHttpRequest do
Right - Flask's error message also points to something I was mistaken
about. XMLHttpRequest does not set this header. jQuery adds it (
https://api.jquery.com/jquery.ajax/#jQuery-ajax-settings ), and presumably
some other JS libraries.
In my opinion there are not many good reasons to have to change
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
24 matches
Mail list logo
