On Sun, 2007-10-07 at 02:39 +0200, David Larlet wrote: > 2007/10/6, Malcolm Tredinnick <[EMAIL PROTECTED]>: > > > > I had a quick read of it. Looks like you're on the right track. > > Thanks for your reactivity. > > > > > The main problem I see with it is that you're over-populating the data > > structures a bit. If the request is a PUT, you're still populating > > self.POST as a side-effect. We should neaten this up a bit. > > > > When I started to think about this and how we would use it, it's not a > > complete no-brainer and I'm beginning to think my original suggestion > > (and what Andreas implemented in django-rest-interface) might not be the > > easiest for end users (third-party programmers like yourselves). A > > couple of possibilities spring to mind: > > > > (1) We always populate self.POST and only self.POST. Since the > > recommended way to check the method is to check request.method first, it > > means the same code can potentially be used to handle PUT and POST data. > > > > (2) We populate self.POST if request.method == 'POST' and self.PUT if > > request.method == 'PUT' and leave the other one blank. > > > > (3) We leave self.POST available for backwards compatibilty, but use a > > more generic name like self.DATA for the data we extract. This is a > > version of (1) with renaming involved. > > > > Right at the moment, I'm probably slightly in favour of option (1) > > because it's the smallest change and we can think of self.POST as "the > > posted data" regardless of how the HTTP verb is spelt. Code will act > > based on request.method, but there are more possibilities for factoring > > out common pieces when working with the data. > > I'm not sure that "smallest change" should drive the decision, even if > I admit that a backward incompatible change could be a pain.
It doesn't drive the decision, but it is absolutely a consideration. > The > option (3) seems more natural to me to make the difference between > what you post and the POST verb, it's more explicit. What about > self.PUT in this scenario? That's called option (2). :-) > > > > > So then the only change that is needed is to also populate that field > > when the method is "PUT" (with accompanying changes in HttpRequest). > > > > I'd be interested in hearing your thoughts, Peter and David, on this, > > since you've already got experience using that piece of the framework. > > Is there a lot of commonality between the way you're handling the PUT > > and POST paths? I know it's a slight change to Andreas' code, but it's > > not too intrusive from the looks of it. [Andreas: have I forgotten some > > subtlety here?] > > The current standard solution of restapi, which get data given the > receiver looks enough flexible to me. I never had to factorize PUT and > POST because restapi already handle this for me. There are a lot of cases that Andreas' work doesn't cover, since REST is a very broadly applicable theory. That was one of the challenges of the project: working out what areas needed help and where we would just be adding constraints or creating equivalent amounts of work. As soon as you start to move to situations where your publically exposed resources don't map more or less one-to-one onto models, things become a lot trickier and we haven't quite solved that -- partly because I suspect it's not really solvable. My point here is not in any way to diminish the work Andreas has done or the use you are getting from it. In certain scenarios, it is obviously a great help and he's done some excellent design and implementation. I was very happy with the work Andreas did. However, some perspective is necesary. My point *is* to say that there are uses for PUT and POST beyond django-rest-api and there are plenty of situations where I would directly implement the handling, rather than using the django-rest-api classes. So we are looking for a consistent Django solution here, rather than just something that works smoothly with django-rest-api. It's that former case where I'm thinking there might be a reasonable overlap in the code between PUT and POST handling. I'm still not sure about this -- it's going to take a little more mulling over. [...] > I think too, given the success of the last one, what about some kind > of GSoC or REST sprint? At this point, it could be interesting to end > with something which can be merged to the trunk. I'm not against sprints, but we're talking about a very small change here. The reason we asked GSoC students to develop their apps as third-party applications this year was to precisely avoid any rush to inclusion. Django-rest-api is a perfect example: with the exception of needing PUT support in HttpRequest, there's no changes required to core, so there's no real need to include it in core. Maybe, one day, it might be a candidate for django/contrib/, but it's not at that point yet and for the time being, hosting at Google is great because it gives Andreas -- and anybody else who wants to contribute -- an issue tracker, subversion hosting and the whole enchilada without any fuss. So let's stay focused on adding PUT support to HttpRequest in this thread. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
