Re: Extend URL resolver support for HTTP Methods / REST support

[Ned Batchelder]

Malcolm Tredinnick wrote: On Fri, 2006-09-22 at 10:20 +0200, Simon de Haan wrote: Yeah I get it and agree with you. So your suggestion is to not implement this in the urlpatterns and introduce it as a dispatcher in the view? That what works now and it's the an accepted Python idiom for simulating a switch statement from other languages. I'm using that sort of view now in a couple of places where I'm supporting POST, PUT, GET and DELETE all on the same resource (an Atom publishing application). Anyway, let's see what others think (we're in North American nap time at the moment, so let's give them a chance to catch up). Like I said in the bug, I'm interested to hear what possibilities people might have. I don't know about the rest of North America, but I'm up from my nap.. I prefer keeping the dispatch in the view as well, for some of the same reasons: clarity of the url map, and singleness of purpose.  The fact is, there are all sorts of reasons why the view function may need to take different paths.  The HTTP method is just one of them.  What if I want very different code for authenticated and anonymous?  Or with cookie and without cookie?  I may have a valid reason for doing that micro-dispatch, but that doesn't mean we should invent a way of expressing it in the URL map.  The URL map is a simple structure for associating a URL with a view.  The other details about the request that may alter the processing can all be handled in the view.  Frankly, the URL map is already a little overloaded for my tastes, but those overloads are for good map-related causes (the optional dictionary of view arguments is so that different URLs can map to the same view while expressing their differences, and helps make generic views useful; and the string-or-callable overload makes it easier and more natural to express what view to use). --Ned. -- Ned Batchelder, http://nedbatchelder.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---