I've previously raised this idea and created a pull request. https://github.com/django/django/pull/378
The problem with creating with a catch all view: You have following models: Country, Industry, Company, School. You want to have the following kinds of urls: /<country>/ /<country>/ <industry>/ /<country>/<company>/ /<country>/<company>/<industry>/ /<country>/<school>/ /<country>/<school>/<industry>/ / <industry>/ /<company>/ /<company>/<industry>/ /<school>/ /<school>/<industry>/ It can get extremely cumbersome to use catch-all views to manage all of these URLs, rather than a single view with optional keyword-arguments. In my example I have only listed 4 models. It wouldn't be implausible to suggest there are situations when there could be more. I suggest it is better for the framework to handle this complex URL routing on the urls.py level, because it really isn't the view's responsibility to think about URLs; Since URLs already introspect into view's arguments, and in some cases, even instantiate class based views, especially generic views, it would be better to keep urlresolver's relationship with views instead of introducing a new relationship where views must now take care of URLs too. I think the Inversion of Control principle would be good to follow: http://en.wikipedia.org/wiki/Inversion_of_control On Tuesday, March 19, 2013 2:23:41 AM UTC+11, julianb wrote: > > Hi, > > imagine the following use case: > > You build an online store where you have sorted products into several > categories and maybe associated an occasion. Now you want to build URLs. So > the URL schema that all of the store's owners agree on is: > > /<product-slug>/ > /<category-slug>/ > /<occasion-slug>/ > > Look simple. > > Because product slugs should generally be different to category slugs and > occasions, you expect no clashes here. And you don't want to bloat the URLs > by putting product/ and category/ in there. And you also do not want to > resort making it look cryptic by having just /p/<product-slug>/ and so on. > Then it comes to Django. How do you do that? > > Well, at the moment, as far as I am aware, you can't. The first URL will > match everything all the time, not giving the other views a chance to kick > in. > > So I propose some kind of URL fallthrough. The view could do > > raise UrlNotMatched > > and the dispatcher goes to the next possible matching view. > > Would that be good? Any thoughts? > -- 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 django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
