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.


Reply via email to