On Fri, 2011-01-21 at 12:30 -0800, Mike Orr wrote: > 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.
It could and probably should be a cookbook entry. > 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.) What is the distinction you're trying to make between "PUT" and "tunneled PUT"? Are you saying that a view should return something different to a browser client than to a non-browser client based on whether the _method param exists? - C -- 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.
