On Fri, 2011-01-21 at 13:58 -0800, Mike Orr wrote:
> On Fri, Jan 21, 2011 at 1:13 PM, Daniel Holth <dho...@gmail.com> wrote:
> > I think it is very relaxing that my view handles unedited requests. I'm
> > confused about the problem you are having. Since the framework keeps GET
> > requests out, why does the PUT-handler have to check request.method at all?
>
> There are two issues. Going back to Chris's routing example, although
> I'll change add_view to add_route because I'm mainly thining of URL
> Dispatch.
>
> > config.add_route(NAME, PATTERN, VIEW, request_method='PUT')
> > config.add_route(NAME, PATTERN, VIEW, request_method='POST',
> > request_param="_method=PUT")
>
> If the appdev omits one of these, either because they don't know about
> tunneled PUT or because they underestimate the variety of clients and
> uses, the URL won't match at all and either the user will get a 404 or
> a later (wrong) route will match.
If the problem is distinguishing here, two routes are not necessary
here. Just a single route and two views (or handler actions).
config.add_route('thename', '/foo/put', 'theview', request_method='PUT')
@view_config(route_name='thename', request_param='_method',
request_method='PUT')
def tunneled_put(request):
...
@view_config(route_name='thename', request_method='PUT')
def untunneled_put(request):
....
> In the view, if it's a single-purpose view that handles only record
> modification (i.e., a submission from a form or the non-form
> equivalent), it won't care what the method is. As a corollary, it will
> have to call another view (or return 400 status) if the data fails
> validation, because it doesn't have the form-display code.
>
> If it's a multi-purpose view, the user better check for both kinds of
> PUTs or DELETEs, because if he naively does ``if self.request.method
> == 'POST'`:` or ``if self.request.method == 'PUT':``, the result will
> be wrong if the other PUT style was used. So maybe they should do ``if
> self.request.method != 'GET':`` instead, although that raises the
> possibility that the method may be entirely unexpected ('DELETE'
> instead of 'PUT'), in which case again the result is wrong. (It
> *should* return 405 status if the method is inappropriate for the
> view., and not just act like it were a different method.)
I'd just let the framework decide which view to call if they need to do
very distinct things. If this needs to be codified into some pattern, a
restcontroller-esque package can make the necessary view registrations
against named methods of a handler.
- 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.
