On Fri, Jan 21, 2011 at 12:15 PM, Chris McDonough <chr...@plope.com> wrote: > On Fri, 2011-01-21 at 12:13 -0800, Daniel Holth wrote: >> I always setup two view functions, one for GET and one for POST. >> >> I don't do PUT, but if you want Pyramid lets you condition a view on >> both the request method and parameters. The second function should >> only be called for a PUT, or a POST with _method=PUT in the >> parameters: >> >> def some_method(request): >> # handle everything else >> >> def some_method_PUT(request): >> # handle the PUT >> >> ... >> >> config.add_view(some_method) >> config.add_view(some_method_PUT, request_method='PUT') >> config.add_view(some_method_PUT, request_method='POST', >> request_param="_method=PUT") > > True, I guess we handle it already by default, so unless there's some > usage pattern I don't understand (likely), we don't really need to argue > about supporting it or not.
We at least need to document it as a FAQ, and mention it in the routing section and view section. This syntax does make the routes less straightforward (they show the low-level details rather than the high-level intention). If the application is expecting both tunneled PUT and direct PUT, it will have to accomodate both possibilities. And views will also have to handle tunneled PUT themselves because it won't be converted. (Although that could be done in the view handler .__init__, but that's kind of a band-aid approach because it covers only the views and not the routes.) -- Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
