«Падение» в Django URLConf?

Question

У меня есть ситуация, когда я в основном разрешаю любой URL без префикса;Один способ, которым я думал о его разработке, заключался в том, чтобы в основном иметь два '' совпадения - первый видел, сможет ли он удовлетворить запрос, и если нет, то провалится ко второму.

• Если я raise Http404 с первого взгляда, я получаю страницу 404.

• Если я return, я получаю ValueError жалобу, что я "не вернулОбъект HttpResponse. "

Если кратко взглянуть на код в django.core.urlresolvers, я совершенно убежден, что архитектура просто не в состоянии сделать это - она ​​разрешается до одного совпаденияфаза разрешения URL полностью отделена от фазы просмотра, и как только вы перейдете к представлению, возврат к фазе разрешения URL уже не будет.Это правильно?Лично я видел бы это как небольшой недостаток;Я вижу, как может быть полезно иметь два типа 404: один говорит «нет, его не существует», как в настоящее время, а другой - «я не знаю об этом», что бы выглядело так.через далее URLConf.На данный момент мне кажется, что любой, кто хочет использовать этот стиль системы, должен заменить часть разрешения URL в Django.

Я работал над этим (в основном получая тривиальное представление, чтобы подсунуть его одному изатем другой), так что я не думаю, что мне действительно больше нужна эта конкретная вещь, но все же мне любопытно, есть ли способ , который я просто не заметилили есть ли более аккуратное решение.

Answer 1

Я не знаю, почему у вас есть два вида здесь. Конечно, у вас действительно есть только одна точка зрения, которая может делать две (или более) вещи. Измените функцию просмотра на что-то вроде:

 if canDoMethod1(request):
    doMethod1(request)
 else:
    doMethod2(request)

или что-то еще. Это срабатывает на любом URL. Сортировка.

Answer 2

Я думаю, что обходной путь, который вы упомянули в конце , является правильным способом сделать это в Django.Это часть договора о том, что он должен возвращать HttpResponse, поэтому избежать этого невозможно.