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 -~----------~----~----~----~------~----~------~--~---
