"Fallthrough" in Django URLConf?
I've got a situation where I'm basically allowing any URL, with no prefix; one way that I had been thinking of designing it involved basically having two ''
matches - the first would see if it could serve the request and if not it would fall through to the second.
If I
raise Http404
from the first view, I get a 404 page.If I
return
, I get aValueError
complaining I "didn't return an HttpResponse object."
Looking briefly at the code in django.core.urlresolvers
, I'm开发者_如何学运维 fairly convinced that the architecture simply isn't in place to do this - it resolves to a single match, the URL resolution phase is entirely separate from the view phase and once you've gone to the view there's no returning to the URL resolution phase. Is this correct? Personally I would see this as a slight deficiency; I can see how it could be quite useful to have two types of 404 - one saying "no, it doesn't exist" as it currently does, and one saying "I don't know about it", which would make it look through further the URLConf. At the moment it seems to me like anyone wanting this style of system basically has to replace the URL resolution part of Django.
I've worked around this (basically getting a trivial view to palm it off to one and then the other), so I don't think I really have any need for this particular thing any more, but still I'm curious if there is a way of doing this which I just didn't spot, or whether there might be a neater workaround.
I think the workaround you mention at the end is the right way to do this in Django. It's part of the contract of a view that it must return an HttpResponse, so there's no way of avoiding that.
I don't know why you have two views here. Surely you really only have one view, which can do two (or more) things. Change your view function to something like:
if canDoMethod1(request):
doMethod1(request)
else:
doMethod2(request)
or whatever. That gets triggered on any URL. Sorted.
精彩评论