Would that mean that the object returned by request.DATA/POST/whatever could be a different type, depending on what the user posted?
I don't want to see code like: if isinstance(request.DATA, YamlObject): ... elif isinstance(request.DATA, dict): ... although, I'm not sure how any view could handle any random content-type... Le mercredi 4 septembre 2013 13:57:29 UTC+2, Marc Tamlyn a écrit : > > The thing with request.POST is that it's kinda unintuitive when extended > to other HTTP methods (e.g. PUT). This is why the old request.raw_post_data > was renamed request.body. > > request.POST would behave in the expected traditional web way of picking > up form encoded POST data, which would also be available in request.DATA as > well, but request.DATA is the "new" way of doing it. Personally, I'd > lowercase it though, to remove confusion with the PHP $POST $GET $REQUEST > which we mimic on the request object. The generally have different use > cases anyway - one for complex web things and the other for standard web > browsers. > > (the above is what tom said...) > > Tom - what else do you have in DRF's Request that you would need? > > > On 4 September 2013 12:56, Tom Christie <[email protected] <javascript:> > > wrote: > >> > Creating a request.DATA attribute would break compatibility with old >> code and seem to me less intuitive. >> >> The implementation would ensure `request.POST` would still be populated >> for form data. >> >> There wouldn't have to be any backwards incompatible changes, and usage >> of `request.DATA` (or whatever better name there might be, perhaps simply >> `request.data`) would be entirely optional for using with generic request >> parsing, instead of form data only. >> >> >> > Where should request.FILE go in that case >> >> request.FILES would be populated by form data as normal, and would be >> empty on JSON or other submissions. In order to support multipart parsing >> the request parsing API would need to provide for parsers that support file >> upload, in a similar way that REST framework currently does. >> >> > Would request.POST just be a call to request.DATA? >> >> That's an open question, but I'd probably expect it to only return data >> if the request contains multipart or url-encoded form data. (Ie. the >> behaviour wouldn't change.) >> >> Cheers, >> >> Tom >> >> On Wednesday, 4 September 2013 12:33:00 UTC+1, Stefan Berder wrote: >>> >>> Tom, >>> I agree that the middleware solution is not the best and in my mind >>> creates fragmentation of the same type of request handling. >>> >>> A generic content-type framework would make the request parsing more >>> flexible, stronger to change in the future and open the door to any type. >>> >>> I'm curious about the choice of request.DATA though, when doing a POST >>> request, I expect the data to be in the POST dictionary and nowhere else. >>> Creating a request.DATA attribute would break compatibility with old code >>> and seem to me less intuitive. Where should request.FILE go in that case? >>> Would request.POST just be a call to request.DATA? >>> >>> Stefan >>> >>> On Wednesday, 4 September 2013 18:13:12 UTC+8, Tom Christie wrote: >>>> >>>> Hi Stefan, >>>> >>>> Sure, I'd be interested in seeing us improve how we deal with JSON >>>> requests and responses. >>>> >>>> My preference would be to introduce a request parsing and response >>>> rendering API that allows us to support not just JSON, but any media type >>>> that has a parser installed for it. (I've commented on some of this >>>> before, >>>> here<https://groups.google.com/forum/#!searchin/django-developers/tomchristie%7Csort:date/django-developers/Qr0EorpgYKk/6qyCrVqZwmMJ>, >>>> >>>> although I think I'm warming towards the idea that it's probably about >>>> time >>>> we started addressing at least some of this in core.) >>>> >>>> Unsurprisingly I'd suggest the same general approach that is used in >>>> REST framework - A lazy `request.DATA` attribute (or similar) that when >>>> accessed, inspects the media type on the request, and parses the request >>>> stream with an appropriate parser if possible. The installed parsers can >>>> be configured globally, or on a per-request basis. The existing multipart >>>> and form-encoded parsing behaviour would no longer be a special case baked >>>> directly into the request object, but instead be the default installed >>>> parsers. >>>> >>>> Taking this approach makes it trivial to write views that can handle >>>> both JSON and form data, and providing a proper parser API makes it easy >>>> for developers to package up and share their own parser implementation, >>>> such as YAML, XML and MsgPack. (And, looking forwards, JSON-based media >>>> types such as hypermedia types.) >>>> >>>> In REST framework this behaviour is (by necessity) implemented in a >>>> Request object that wraps the underlying HttpRequest, but the same basic >>>> implementation can be applied to implementing it directly in the Request >>>> object, and would be somewhat easier. >>>> >>>> I'm interested to see Marc suggesting middleware specifically for >>>> handling JSON requests. That'd work, and would be a simple approach. My >>>> reservations with that would be: >>>> >>>> * We'd not be making it any easier for users to deal with request >>>> parsing generally. >>>> * There's no way to write views that deal with request data in an >>>> agonistic way, and dealing with differing media types would require >>>> switching based on the media type in the view itself. For example, the >>>> generic views would still only support form data. As another example, if >>>> you wanted to add, say, MsgPack support to your application, you'd need to >>>> re-write all your views. >>>> >>>> From my point of view this is already a solved problem, and I'd really >>>> like to see a generic approach to handling request data, and a >>>> corresponding approach to rendering responses into an appropriate media >>>> type. >>>> >>>> All the best, >>>> >>>> Tom >>>> >>>> On Tuesday, 3 September 2013 06:30:04 UTC+1, Stefan Berder wrote: >>>>> >>>>> Hi, >>>>> I looked around the list and couldn't find any mention of this subject. >>>>> >>>>> In `django.http.request.**HttpRequest._load_post_and_**files()` there >>>>> is explicit mention of two content type ('multipart/form-data' and >>>>> 'application/x-www-form-**urlencoded'), any other content type will >>>>> get empty values for self._post. >>>>> >>>>> Given that a lot of user form interaction is now happening through >>>>> 'XMLHttpRequest', I think that the 'application/json' content type should >>>>> be supported. A lot of javascript libraries will use json as the default >>>>> format: >>>>> * angularjs: >>>>> http://docs.angularjs.org/api/**ng.$http<http://docs.angularjs.org/api/ng.$http>, >>>>> >>>>> see "Setting HTTP Headers" >>>>> * emberjs: https://github.com/emberjs/**data/blob/master/packages/** >>>>> ember-data/lib/adapters/rest_**adapter.js#L974<https://github.com/emberjs/data/blob/master/packages/ember-data/lib/adapters/rest_adapter.js#L974> >>>>> * backbone: http://backbonejs.org/#Sync >>>>> * jquery: >>>>> http://api.jquery.com/jQuery.**ajax/<http://api.jquery.com/jQuery.ajax/>(the >>>>> only one using 'application/x-www-form- >>>>> **urlencoded' by default) >>>>> >>>>> I'm trying primarily to create a discussion on the subject and am >>>>> ready to provide the code for it as I had to write it. This would help >>>>> avoid hacks to handle the request object in my view. >>>>> >>>>> I know there are some apps to handle API construction >>>>> (django-tastypie, django-rest, django-piston and certainly others) they >>>>> use >>>>> either request wrappers or request handling in their views. >>>>> >>>>> Stefan >>>>> >>>> -- >> 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] <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. For more options, visit https://groups.google.com/groups/opt_out.
