Just my 2 cents... If you drop request.POST, request.GET, and replace them all with request.DATA -- we're going to again be branching away from Django trunk.
For our uses -- POST and GET are completely different things -- whether you use one at a time or not is unrelated. Things should be differentiated between POST and GET as you don't want someone to start sending data to your forms through request.GET. On 18 oct, 04:32, "David Larlet" <[EMAIL PROTECTED]> wrote: > 2007/10/18, Malcolm Tredinnick <[EMAIL PROTECTED]>: > > > > > > > On Tue, 2007-10-16 at 21:52 +0200, David Larlet wrote: > > > 2007/10/10, David Larlet <[EMAIL PROTECTED]>: > > > > > BTW, no more thought about the way of handling PUT? I've just added a > > > > patch against test.client which add .put() and .delete(), I'm waiting > > > > for (a) reaction(s) to add tests and documentation. > > > > Sorry for insisting on that point but this is important to me, once > > > the decision is taken I can produce patches but I need your feedback > > > here to continue :) > > > <rant>Well, since I'm working on Django on a totally volunteer basis and > > already have a fairly large prioritised list of things to do -- many of > > which, quite honestly, have a larger impact on the broader Django > > userbase than this one -- as well as day jobs that need attention in > > order to pay the bills, it would be impolite of me not to entirely > > reshuffle things to meet your needs then. :-(</rant> > > <rant class="mitsuhiko"> > I perfectly understand because I'm in the same situation. But > sometimes, when someone motivated ask me politely and when this item > just take me a couple of minutes, I decide to put this one in top of > my todolist because I know that my decision will have consequences and > maybe this guy is insisting because he's got time right now. > </rant> > > > > > My personal preference is to use request.DATA and keep request.POST > > around as a backwards compatibility feature for a release or two. That > > way PUT, POST -- and if somebody wants to use it later, OPTIONS, etc -- > > can all use the same attribute, since you can only be doing one at a > > time. That saves having to add a new attribute for every potential HTTP > > verb (note that the set isn't restricted to just PUT, POST, GET and > > DELETE) and helps write common code for processing the data -- > > request.method tells you the verb, request.DATA gives you the entity > > body. > > > My second favourite preference is to add request.PUT, as > > django-rest-interface does at the moment. > > > However, neither decision is binding until at least one other core > > maintainer steps in with some agreement or sufficient time passes that > > I'm convinced they really don't care which way we go. > > Thanks for your answer, I agree with you that request.DATA could be > interesting. I will update my patches with this proposition given the > fact that Jacob agree with you. > > David --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
