Hi all,
I would love to be involved with this feature.
My suggestion is to do the following:
- Check requst.is_ajax()
- Check request.META.get('CONTENT_TYPE').count('application/json')
- Parse request.body using django.utils.simplejson.loads
- ... and set *request.JSON* to the result
I have a small piece of middleware that implements this procedure and have
posted it as a gist, https://gist.github.com/abhillman/6910689.
If there is interest in using my code, I would be very happy to write some
unit tests.
abh
On Thursday, September 12, 2013 3:46:53 AM UTC-7, Stefan Berder wrote:
>
> Tom,
> I get the context and that form is tied to that behavior but outside of
> "that's how it is now" is there any technical reason for this? I can't read
> forms code at the moment but will do tonight and will look at how FILES is
> used in there. I'm not usually afraid by impacts of it's the "right thing
> to do". I think it would make for a stronger interface of you could simply
> find your data in request.data.
>
> I will create a branch in my fork on github and will send it here for
> progress.
>
> Stefan, from my mobile
> --
> http://www.bonz.org/
> /(bb|[^b]{2}/
> On 12 Sep 2013 18:20, "Tom Christie" <[email protected] <javascript:>>
> wrote:
>
>> > why keep data and files separated
>>
>> Mostly because that's the way it already works, so...
>>
>> * request.data would essentially provide a strict superset of the
>> functionality that request.POST provides. In general you'd be able to
>> replace `request.POST` with `request.data` anywhere and seemlessly start
>> supporting JSON or other data without any other changes required.
>> * Form expect the data and files to be provided separately which would be
>> awkward otherwise.
>>
>> > In the absence of strong objection, I will start working on this base.
>>
>> Sure thing. As it happens, I was also considering taking a crack at this
>> in the coming weeks, so please do follow up on this thread linking to your
>> repo if you start working on it, so myself and others can track any
>> progress. (And perhaps collaborate.)
>>
>> Cheers :)
>>
>> Tom
>>
>> On Wednesday, 11 September 2013 04:52:08 UTC+1, Stefan Berder wrote:
>>>
>>> On Tue, Sep 10, 2013 at 12:17 PM, S Berder <[email protected]> wrote:
>>> > On Tue, Sep 10, 2013 at 9:05 AM, Curtis Maloney
>>> > <[email protected]> wrote:
>>> >>
>>> >> On 9 September 2013 19:50, S Berder <[email protected]> wrote:
>>> >>>
>>> >>> Gents,
>>> >>> to sum it up, arguments made and details of how I see the
>>> >>> implementation of a response/request encode/decode framework:
>>> >>>
>>> >>> * need a pluggable interface so current content-types are supported
>>> >>> (`application/x-www-form-**urlencoded`, `multipart/form-data`), new
>>> >>> types (`application/json`), custom and future types
>>> >>> (`application/vnd.foobar+json` anybody? See
>>> >>> http://developer.github.com/**v3/media/#api-v3-media-type-**
>>> and-the-future<http://developer.github.com/v3/media/#api-v3-media-type-and-the-future>
>>>
>>> >>> for example, `application/msgpack`, `application/protobuf`,
>>> >>> `application/capnproto`, etc).
>>> >>> * decoder/encoder map (content-type, decoder) should be smart to
>>> >>> handle patterns like `text/*` or `application/*xml*` and match
>>> things
>>> >>> like `Accept: application/json, text/plain, * / *`
>>> >>> * choice of decoder would be made on the Content-Type header, maybe
>>> >>> supporting a raw by default so data is just passed in case of
>>> unknown
>>> >>> content type.
>>> >>> * decoder/encoder should be available through `request` and
>>> `response`
>>> >>> objects.
>>> >>> * decoded data structure (python object) would be stored in
>>> `request.data`
>>> >>> * first step is to support requests, next step is to handle
>>> responses
>>> >>> with the same pluggable functionality and coherent API.
>>> >>> * A sensible default for response Content-type would be `text/html;
>>> >>> charset=UTF-8`. It should be made available through a setting entry
>>> >>> anyway
>>> >>>
>>> >>
>>> >> You should also have access to the decision made by the data parser
>>> as to
>>> >> which parser was used, instead of having to infer it yourself from
>>> the
>>> >> content type header.
>>> >
>>> > Indeed, that's the 4th point of my list, maybe it's not clear as it is
>>> > but this would be supported.
>>> >
>>> >>>
>>> >>> Some questions though:
>>> >>>
>>> >>> * why keep data and files separated, I see no good reason for this
>>> >>> except mimicking PHP's structure. An uploaded file comes from a
>>> named
>>> >>> input, I hope to find it in request.data (why do a common structure
>>> >>> otherwise). I might be missing something but nothing indicates a
>>> real
>>> >>> need for this in django/http/request.py
>>> >>
>>> >>
>>> >> True, there's some added complexity [small as it is] in forms because
>>> File
>>> >> fields need to look elsewhere for their values.
>>> >>
>>> >>>
>>> >>> * isn't more or less any data sent to your backend representable as
>>> a
>>> >>> dict or object with dict access modes? I try to think about
>>> >>> occurrences where some data would not have a 'name'.
>>> >>>
>>> >>
>>> >> I frequently send JSON lists of data to my APIs...
>>> > Ok, was a bit short sighted on this one, still thinking in terms of
>>> > form bound data, it was a long day here in Shanghai. I suppose that
>>> > the kind of python object you receive is not so important as you
>>> > should do data validation anyway. Your earlier concern about checking
>>> > for different content-types doesn't apply to the solution I have in
>>> > mind as to whatever data representation you have at the beginning, you
>>> > should get a very similar object after decoding. What I mean is if you
>>> > send the *same* data through Yaml or JSON, the object in request.data
>>> > should be the same or extremely close. I say extremely close because
>>> > I'm thinking about xml that is always way more verbose than the others
>>> > and *might* add more data to the resulting object. (hint: I don't like
>>> > XML, don't need it in what I do and last used it ~8/9 years ago in a
>>> > disastrous explosion of SOAP and unix/microsoft interfaces)
>>> >
>>> > Stefan
>>> > --
>>> > http://www.bonz.org/
>>> > /(bb|[^b]{2})/
>>>
>>> In the absence of strong objection, I will start working on this base.
>>>
>>> Stefan
>>> --
>>> http://www.bonz.org/
>>> /(bb|[^b]{2})/
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/s8OZ9yNh-8c/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> [email protected] <javascript:>.
>> To post to this group, send email to
>> [email protected]<javascript:>
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/eacbcaab-8429-4ecb-b5c5-38d39610fe09%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
