I'm basically in agreement with Russ here. I'd consider the first three points as being non-controversial.
With regards to ProcessFormView I think implementing a put() method, but not a patch() method falls squarely into the 'good-enough' category of behavior. In any case, although there are existing conventions, the exact semantics of PATCH requests are a little vague[*], and the generic view's handling of PUT/PATCH is of fairly limited use, given that they only support form-encoded data, and not, say JSON data. Given that, I don't think we need to get too hung up on correctness in that particular area. Cheers, Tom [*]: As an example Ember's `json-api` style uses RFC 6902, which is more involved than most conventional implementations of PATCH: http://tools.ietf.org/html/rfc6902 On Tuesday, 21 May 2013 13:38:15 UTC+1, Russell Keith-Magee wrote: > > Hi Krzysztof > > On Mon, May 20, 2013 at 7:48 PM, Krzysztof Jurewicz < > [email protected] <javascript:>> wrote: > >> There is a RFC describing HTTP method named PATCH: >> >> http://tools.ietf.org/html/**rfc5789 <http://tools.ietf.org/html/rfc5789> >> >> Quoting that RFC: >> “ The difference between the PUT and PATCH requests is reflected in the >> way the server processes the enclosed entity to modify the resource >> identified by the Request-URI. In a PUT request, the enclosed entity >> is considered to be a modified version of the resource stored on the >> origin server, and the client is requesting that the stored version >> be replaced. With PATCH, however, the enclosed entity contains a set >> of instructions describing how a resource currently residing on the >> origin server should be modified to produce a new version.” >> >> Django currently has (seemingly shallow) support for PUT method. Based on >> that, I’ve grepped for places in code where it is implemented to see if >> support for PATCH could be easily added on a basis of symmetry. Those >> places are: >> >> In test client: >> There is a `put` method, but `patch` is also implemented: >> https://github.com/django/**django/commit/** >> 293f7a21147ad94c92c7d5b3f33cba**b2f87b001b<https://github.com/django/django/commit/293f7a21147ad94c92c7d5b3f33cbab2f87b001b> >> >> In View class: >> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d* >> *73b9d46476/django/views/**generic/base.py#L33<https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L33> >> `put` is listed in http_method_names >> >> In RedirectView: >> `put` is a fallback to .get(): >> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d* >> *73b9d46476/django/views/**generic/base.py#L207<https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/base.py#L207> >> >> In ProcessFormView: >> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d* >> *73b9d46476/django/views/**generic/edit.py#L164<https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/edit.py#L164> >> PUT is implemented as a fallback to POST and it seems to assume that >> request data is form encoded. While it is not generally true for PUT >> method, it looks like a reasonable assumption when processing a form. >> However since PATCH request doesn’t have to contain full form data, I think >> the best approach may be to not implement `patch` method here (unless we >> want to deal with editing only some of the form’s fields – for example this >> is the case in Rails, where PATCH will be the primary method for updates in >> 4.0 version: http://weblog.rubyonrails.org/** >> 2012/2/25/edge-rails-patch-is-**the-new-primary-http-method-** >> for-updates/<http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates/>). >> The same stays true to `get_form_kwargs` method in FormMixin: >> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d* >> *73b9d46476/django/views/**generic/edit.py#L44<https://github.com/django/django/blob/a93672622829e0d4a2ff3240456d4d73b9d46476/django/views/generic/edit.py#L44> >> In general, Django’s approach to whether PUT should be treated as a >> request containing form data seems to be inconsistent because we generate >> forms in the views, but we refuse to generate PUT QueryDict on a request >> object: https://groups.google.com/d/**msg/django-developers/** >> dxI4qVzrBY4/m_9IiNk_p7UJ<https://groups.google.com/d/msg/django-developers/dxI4qVzrBY4/m_9IiNk_p7UJ>. >> So maybe it’s worth to consider removing PUT support in form processing >> just on the basis of consistency. >> >> In conclusion, it seems pretty easy to add basic PATCH support similar to >> PUT. So if it gets enough +1s, I’m willing to make a patch and hope it gets >> included in 1.6 alpha. Or maybe it is (from a technical point of view) so >> small a feature that it doesn‘t need to be merged before alpha release? >> > > These are all reasonable and fairly small I'd be happy to see these added > after the alpha - a ticket and patch would definitely be welcome. > > The only one that is even remotely controversial to me is the handling of > PATCH in ProcessFormView. I agree that there are potential problems with > using PUT as an analog of POST, but it largely works in this situation; so > I don't know if it's worth deprecating the PUT->POST fallback in this case. > > Strictly, I think it's actually a separate issue -- the first three points > you raise are about allowing PATCH at all; the last point is about how we > should deal with PATCH in a specific case. Once the first two items on your > list are addressed, it would be possible to implement a patch() method on > your own generic view subclass; the question is what Django should be doing > as a project to make that implementation easier/more useful. > > Yours, > Russ Magee %-) > -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
