2010-02-02 4 views
1

Итак, у меня есть это приложение Django, и я продолжаю добавлять новые функции, чтобы предоставлять все более детализированные представления данных. Чтобы дать быстрое представление о проблеме, вот подмножество urls.py:Управлять Все более сложными Django-URL-адресами эффективно? (urls.py)

# Simple enough . . . 
(r'^$', 'index'), 
(r'^date/(?P<year>\d{4})$', 'index'), 
(r'^date/(?P<year>\d{4})-(?P<month>\d{2})$', 'index'), 
(r'^date/(?P<year>\d{4})-(?P<month>\d{2})-(?P<day>\d{2})$', 'index'), 
(r'^page/(?P<page>\d+)$', 'index'), 

Так что, да, вид по умолчанию, вид даты, постраничный просмотр, то аналогичные установки для конкретных пользователей URLs:

# user 
(r'^user/(?P<username>\w+)$', 'index_username'), 
(r'^user/(?P<username>\w+)/date/(?P<year>\d{4})$', 'index_username'), 
(r'^user/(?P<username>\w+)/date/(?P<year>\d{4})-(?P<month>\d{2})$', 'index_username'), 
(r'^user/(?P<username>\w+)/date/(?P<year>\d{4})-(?P<month>\d{2})-(?P<day>\d{2})$', 'index_username'), 
(r'^user/(?P<username>\w+)/page/(?P<page>\d+)$', 'index_username'), 

Затем, аналогично снова для команд. , ,

# Team View 
(r'^team/(?P<team>\w+)$', 'index'), 
(r'^team/(?P<team>\w+)/date/(?P<year>\d{4})$', 'index'), 
(r'^team/(?P<team>\w+)/date/(?P<year>\d{4})-(?P<month>\d{2})$', 'index'), 
(r'^team/(?P<team>\w+)/date/(?P<year>\d{4})-(?P<month>\d{2})-(?P<day>\d{2})$', 'index'), 
(r'^team/(?P<team>\w+)/page/(?P<page>\d+)$', 'index'), 

Теперь я хочу, чтобы добавить представление «поиск», и на самом деле я думаю, что было бы неплохо, чтобы просто добавить, что к концу многие из перечисленных выше URL-адресов, так что я мог ударить что-то вроде:

/search/foo
/user/fred/date/2010-01/search/baz

И тогда я мог бы просто передать параметр поиска в целях, которые могли бы ограничивает результаты соответствующим образом.

Но скажите, если я хочу применить это к пользовательскому, командному и датируемому представлениям, у меня есть 12 новых строк, добавленных к urls.py. И каждый раз я добавляю еще один вариант потенциального вида (скажем, с разбивкой по страницам результатов поиска?). , , он просто чувствует, что должен быть лучший способ.

Из моих исследований, ответ, казалось бы:
1) Более широкое согласование в urls.py и есть функция просмотра разбора строки запроса.
2) Может быть, какая-то более логичная логика регулярного выражения в urls.py, которая может сказать «если этот шаблон совпадает, включите параметр при переходе к функции просмотра» несколько раз. Но это, возможно, кошмарно для поддержания.

Кто-нибудь придумал разумное решение для управления сложными URL-адресами элегантно? Я думаю, что в какой-то момент чистнее просто передать логику соответствия параметров самому представлению, чтобы проанализировать параметры из строки запроса. Таким образом, в верхней части представления я мог бы иметь некоторый код, который выглядит следующим образом:

# Date Queries 
re_ymd = re.compile('date/(?P<year>\d{4})-(?P<month>\d{2})-(?P<day>\d{2})') 
re_ym = re.compile('date/(?P<year>\d{4})-(?P<month>\d{2})') 
re_y = re.compile('date/(?P<year>\d{4})') 
if(re_ymd.search(qs)): 
    year = re_ymd.search(qs).group('year') 
    month = re_ymd.search(qs).group('month') 
    day = re_ymd.search(qs).group('day') 
elif(re_ym.search(qs)): 
    year = re_ym.search(qs).group('year') 
    month = re_ym.search(qs).group('month') 
elif(re_y.search(qs)): 
    year = re_y.search(qs).group('year') 

# Pagination queries 
re_p = re.compile('page/(?P<page>\d+)') 
if(re_p.search(qs)): 
    page = re_p.search(qs).group('page') 

# Search queries 
re_s = re.compile('search/(?P<search>\w+)') 
if(re_s.search(qs)): 
    search = re_s.search(qs).group('search') 

Итак, что умный способ снижения repetetive сложности я о введении в urls.py?

ответ

3

Почему бы не использовать параметры GET, или django-filter, если все, что вы делаете, просто фильтрует/группирует результаты по-разному?

Причины, по которым я вижу использование GET, это то, что его проще реализовать и кажется немного чище: в решении URL/search/foo/user/bar/and/user/bar/search/foo/есть 2 имени для того же самого содержания. В GET-параметрах решения есть все те же страницы.

+1

У вас здесь есть правильный URL - URL предназначен для уникальной идентификации ресурсов, а не для фильтрации. –

+0

Да, это то, что я получаю в самом низу моего вопроса: в значительной степени обходя «urls.py» и разбирая аргументы запроса из строки запроса в функции просмотра. Я не уверен, что django-filter - это инструмент, который я хочу, но спасибо за подтверждение решения, которое я воспринимаю. , , – dannyman

+0

Но в вашем решении вы по-прежнему используете URL-адреса, просто не используя механизм маршрутизации URL-адресов django, но придумывая свои собственные. используя параметры GET, ваш код будет наполовину длинным и в два раза чистым. –

0

Давайте сосредоточимся на этом:

# Simple enough . . . 
    (r'^$', 'index'), 
    (r'^date/(?P<year>\d{4})$', 'index'), 
    (r'^date/(?P<year>\d{4})-(?P<month>\d{2})$', 'index'), 
    (r'^date/(?P<year>\d{4})-(?P<month>\d{2})-(?P<day>\d{2})$', 'index'), 
    (r'^page/(?P<page>\d+)$', 'index'), 

Я предполагаю, что есть некоторые из них:

def index(year=2010, month=2, day=2, page=0): 
     # whatever 

Итак, почему бы не совместить вам регулярных выражений в одном, например,

 r'^date/(?P<year>\d{4})(-(?P<month>\d{2})(-(?P<day>\d{2}))?)?$ 

Я не пробовал, но я уверен, что что-то подобное будет работать.

EDIT:

Хотя переписывание регулярные выражения могли бы работать, посмотрим на ответ Ofri Равивом, потому что это может быть, что у вас есть некоторые мета-проблема.

Смежные вопросы