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" >
> 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 wrote:
>>> > On Tue, Sep 10, 2013 at 9:05 AM, Curtis Maloney
>>> > wrote:
>>> >>
>>> >> On 9 September 2013 19:50, S Berder 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
>>>
>>> >>> 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 s
