On 13/04/13 22:48, Brantley Harris wrote: > There's a line in the django URL Dispatcher documentation that is pretty > weird: > > The URLconf doesn’t look at the request method. In other words, all > request methods – POST, GET, HEAD, etc. – will be routed to the same > function for the same URL. > > > Well, why? Most modern web frameworks allow you to specify the method > in the routing configuration, Django seems to be an exception in this > respect. > > It would be extremely easy to implement, and would lead to vastly better > code across new projects, including a simpler way of writing rest style > interfaces: > > url('^objects/$', 'views.create_object', methods=['post', 'put'], > name='create_object'), > url('^objects/$', 'views.get_objects', name='list_objects'), > > > This has come up many times before and been swatted down for various > reasons. One is that it could be implemented with a one-off dispatcher, > as in: > > url('^objects/$', create_or_list(list=get_objects, > create=create_object), name='create_or_list_objects') > > > But this is overly complex for what should be a simple configuration, > forces one to create the same name for the url, and worse, creates a > level of indirection breaking the abstraction up; or in other words > you're trying to do route configuration, why not do it in the place > you're already doing route configuration? > > The other argument is that you can do this with Class Based Views. I > don't believe this is a good argument as one would have to utilize Class > Based Views to get this basic functionality. In fact CBV's, only really > solve two common issues, one is the boilerplate inherit in forms, and > the other method routing. But the proposed solution to method routing > is simpler and better.
You don't have to use Django's CBVs to get this functionality - you can write your own, avoiding anything you dislike about them. One reason for not doing this kind of despatch is that handling for different HTTP methods often involves a lot of common code. The classic form workflow would become longer, more complicated and/or less DRY if it was implemented using two functions instead of one: https://docs.djangoproject.com/en/dev/topics/forms/#using-a-form-in-a-view So, I would disagree that dispatching on HTTP verb would lead to vastly better code - it could easily make things worse. However, this is not an argument against having the *option* to do method-name dispatching in the URLconf - I can see that there are valid use cases for that. Regards, Luke -- Environmentalists are much too concerned with planet earth. Their geocentric attitude prevents them from seeing the greater picture -- lots of planets are much worse off than earth is. Luke Plant || http://lukeplant.me.uk/ -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to firstname.lastname@example.org. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.