In this mailing list alone, Michael, Tom, David, Felipe, julianb, Ian and I
have all proposed different solutions. 7 different solutions to what
appears to be a very common problem. :(
Tom:
As you said the get_instance_or_404 only works for simple cases.
The switcher view only works if the delegates have no kwargs, or if they
do, all their kwargs are named the same way. The problem remains: URL
structure forcing a particular design onto user's view definitions.
Good point about the middleware:
The view middleware can't be called just once with the 'correct' view,
> because there's not way of determining up front if a view will raise a
> `UrlNotMatched` without calling into it.
>
>
Currently in my pull request they do get called again and I see it is a
problem.
David: The slugs wouldn't be overlapping if they inherited from some sort
of "Organization" model with unique slug. The user could also add
validation code to prevent company and schools having same slugs.
Michael: How does the middleware work with other URLs that do not need to
have fallthrough? Do you have to add them to excluded_path_patterns? Would
like a more general description of how it works. Also, couldn't the caching
logic, (ignoring fallthrough urls for a minute), be implemented in a view
decorator (which is also what how we do it)?
I have thought about some of everyone's proposed solutions, especially
Ian's and Tom's. What about a new function for use when declaring
urlpatterns, called "urlrouter_view" which you wrap around URLs to
explicitly mark them as having fallthrough enabled. When calling it, it
will look at its arguments to make sure the patterns are all identical. It
creates an anonymous view that would route to each view one by one until
one resolves without raising the DoesNotResolve exception. If no view could
handle the URL, it will raise an Http404. (Since the number of URLs are
more limited, maybe we can do away with DoesNotResolve and use a Http404 as
a signal to continue resolving.) Any view middleware would only have been
run once for the URL, given the anonymous view as the argument and any
keyword arguments are converted to list argument format for the middleware.
Here is an example (forgive my poorly named views):
urlpatterns += patterns('',
# ... other normally managed urls.
urlrouter_view(
url(r'^(?P<country>[_a-z0-9-]+)/(?P<company>[_a-z0-9-]+)/$',
'list_activity'),
url(r'^(?P<country>[_a-z0-9-]+)/(?P<industry>[_a-z0-9-]+)/$',
'list_company'),
url(r'^(?P<company>[_a-z0-9-]+)/(?P<industry>[_a-z0-9-]+)/$',
'list_activity'),
),
# ... other normally managed urls.
)
So basically my proposal as it stands but its abilities have to explicitly
marked in urls.py. I have not thought about how this can be implemented
yet, especially in regards to url includes and exposing the url names and
kwargs to reverse, but it addresses the problem with view_middleware.
Alternative syntax (names can be improved), removes repetition on regex:
urlpatterns += patterns('',
# ... other normally managed urls.
urlrouter_view('^([_a-z0-9-]+)/([_a-z0-9-]+)/$'
view('list_activity', kwargs=['country', 'company'],
name="list_activity),
view('list_company', kwargs=['country', 'industry'], name="
list_company),
view('list_activity', kwargs=['company', 'industry'],
name="list_activity),
),
# ... other normally managed urls.
)
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.
