Django urlpatterns для hostname

Я не буду сейчас детально рассказывать, что такое urlpatterns в django, понадеясь на осведомлённость возможных читателей. Однако для тех, кому это внове, дам краткий пример. В Django для сопоставления url`ов коду используются конфигурационные файлы urls.py (Urlconf). Основной смысл этих файлов в подобных строчках:

(r'login/$', 'someapp.views.login')

Данная строка означает, что когда пользователь зайдёт на страницу www.example.com/login/ , то для генерации страницы вызовется функция someapp.views.login . В простейшем случаем первым параметром такой строки является регулярка, вторым - нужная функция. Заметьте, что регулярка сопоставляется только с путём, а хостнейм отбрасывается. Сами urlconf весьма удобны, но такое игнорирование хостнейма не даёт использовать стандартные джанговские подходы для реализации подобных вещей:

• Вызов различных функций в зависимости от части хостнейма, например, pda.example.com - PDA версия сайта, blog.example.com - блог на сайте. Конечно, это можно реализовать и другими средствами, однако создание разветвлённой структуры всё же затруднено.


• Передача параметров в функции в зависимости от хостнейма. Например, tilarids.blogspot.com - на самом деле, все такие страницы могут генерироваться одной функцией в зависимости от имени пользователя

Т.о., возникает желание получить механизм, который бы работал аналогично urlconf, но вместо пути работал бы с хостнеймом. После небольшого исследования на эту тему у меня создалось впечатление, что это так нигде и не реализовано. Отсюда и родился подобный код:

class HostnameDispatcher(object):
    def __init__(self, view, myregex): 
        self.regex = re.compile(myregex, re.UNICODE)
        self.view_func = view
    def __call__(self, request, *args, **kwargs):
        current_site = RequestSite(request)
        match = self.regex.search(current_site.domain)
        print "Current args:",args, kwargs
        if match:
            new_kwargs = match.groupdict()
            if new_kwargs:
                new_args = args
            else:
                new_args = match.groups() + args
            new_kwargs.update(kwargs);
            return self.view_func(request,*new_args,**new_kwargs)

class HostnameRegexPattern(RegexURLPattern):
    def __init__(self, regex, callback, hostname_re,proto=u'http://',default_args=None, name=None):
        RegexURLPattern.__init__(self,regex,callback,default_args, name)
        self.hostname_regex = hostname_re
        self.dispatcher = HostnameDispatcher(self.callback, self.hostname_regex)
        self.old_regex = self.regex
        self.regex = re.compile(u'\b'+proto+hostname_re+u'/'+regex,re.UNICODE)
        
    def resolve(self, path):
        match = self.old_regex.search(path)
        if match:
            kwargs = match.groupdict()
            if kwargs:
                args = ()
            else:
                args = match.groups()
            kwargs.update(self.default_args)
            return self.dispatcher, args, kwargs

Хочется заметить, что основными требованиями к коду были:

• Полная совместимость со стандартными способами resolve и reverse (получения функции по адресу и адреса по функции соответственно)
• Безболезненное встраивание в рабочую систему Django

Возможно, код несколько сумбурный - несмотря на недолгую жизнь, он успел почувствовать на себе процесс развития и переделывания. Постараюсь объяснить, что здесь зачем. Итак:

• HostnameDispatcher - класс, который позволяет resolv`ить функцию по хостнейму, являсь некой надстройкой над этими самими функциями(вернёмся к терминологии django и будем называть их view). Например,

  disp = HostnameDispatcher(my_view,r'^(.*)$')

  создаёт на основе существующего view новый объект, который при резолве добавляет параметры из хостнейма. Удобно, быстро, но никак не поможет при reverse. А вот reverse - это как раз самая сложная, но и не менее нужная часть
• HostnameRegexPattern - это замена стандартным урлпаттернам. resolve здесь реализуется через уже упомянутый HostnameDispatcher. А вот с reverse пришлось извратиться. В django нет хорошей возможности изменять стандартное поведение reverse. Т.о., я просто изменил существующую регулярку, и в итоге получил почти правильный результат. Единственное, выскакивает '/' в начале. Для его устранения я не придумал ничего лучше, чем сделать небольшой патч для django(в django.core.urlresolvers):

  def backspace_process(func):
      def reverse_new(viewname, urlconf=None, args=None, kwargs=None):
          ret_val = func(viewname, urlconf, args, kwargs)
          if ret_val[:4]=='/%08':
              return ret_val[4:]
          return ret_val
      return reverse_new
  
  def reverse(viewname, urlconf=None, args=None, kwargs=None):
      args = args or []
      kwargs = kwargs or {}
      return iri_to_uri(u'/' + get_resolver(urlconf).reverse(viewname, *args, **kwargs))
  
  reverse = backspace_process(reverse)

  Т.е., добавляется в начале отдельный символ(\b), который потом удаляется при надобности. Такое удаление не должно никак повлиять на другие urlpatterns

Ну и наконец: как это использовать. Нет ничего проще- записываем в urls.py в паттерны такую строчку:

HostnameRegexPattern('test/(\d+)/$', 'blog.views.test',r'^(.*)$'),

, где первый параметр - регулярка для пути, второй - функция, третий - регулярка для хостнейма. Всё! :)

Кто может предложить что-нибудь более интересное, или улучшить уже существующий код - буду весьма благодарен.