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