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 [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.
