Hi Tom, interested to see why you think a single wrapping view is a reasonable alternative for the example I showed above, where you have following list of URLs:
/<country>/ # front page for country /<country>/ <industry>/ # list of schools and companies with activities in that industry, in that country /<country>/<company>/ # list of industries company has activities in, in that country /<country>/<company>/<industry>/ # list of activities company has in that industry, in that country /<country>/<school>/ # list of activities school has in that country /<country>/<school>/<industry>/ # list of activities school has, in that industry / <industry>/ # list of schools and companies with activities in that industry, in all countries /<company>/ # list of industries company has, globally /<company>/<industry>/ # list of activities company has in that industry, globally /<school>/ # list of industries the school is involved in, globally /<school>/<industry>/ # list of activities school has in that industry, globally What is the reasonable alternative? The only way I can think how a wrapping view will be able to handle this case, is to write your own router like router_view1(slug1=None) router_view2(slug1=None, slug2=None) router_view3(slug1=None, slug2=None, slug3=None) In each case you'll have lots of ifs, try..excepts, for each model, and then to appropriate view. For the second and third router_views you'd have to have the same thing repeated, but this time it is nested. Yet, in urls.py, all you have is: (r'/<slug1>') (r'/<slug1>/<slug2>') (r'/<slug1>/<slug2>/<slug3>') Forcing the user to handle complex logic like this (each user probably needs to do it differently), which is not easy to test due to many branches involved, IMHO is a big cost. There's also the question of view_middleware not being applied for the appropriate view unless the user specifically looks into how middleware gets called and manages handling view middleware themselves in the different router_views. Perhaps you have a better way to implement this than what I can think of? This is how we do it in our company, and it'd be great if this can be improved. On Thursday, March 28, 2013 3:28:10 AM UTC+11, Tom Christie wrote: > > For what it's worth I'd be against this proposal as it stands. > > * I haven't seen anything anything that convinces me that a single > wrapping view isn't a reasonable alternative in the examples cited. > * A `UrlNotMatched` exception sounds like the potential source of > incredibly non-obvious bugs and surprising behavior. > * Allow a single HTTP call to end up calling into multiple views just > seems like it would a fundamentally bad design decision. > > I really don't see the trade-off of allowing this type of behavior to be > worth the cost of breaking the current mental model of what a view is and > does. > > Just my personal opinion of course :) > > Tom > -- 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.