Proposed middleware: SubdomainURLsMiddleware

SubdomainURLsMiddleware

Example of what you'd change in settings.py:

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.middleware.doc.XViewMiddleware',
    'mysite.myapp.middleware.SubdomainURLsMiddleware'
)

DOMAINS_URLCONF = {
    'mobile' : 'mysite.mobile_urls',
    'companyA : 'mysite.companyA_urls',
}

I appreciate this as a workable solution in some cases, but I don't think it is general enough. This doesn't easily address cases where many/all of the subdomains are sharing a single URLCONF, particularly a deeply nested URLCONF, and yet still need to differentiate content. It also doesn't provide anything in the way of support for standard contrib apps like Flatpages, as there would be no way to have different flatpages appearing on different subdomains solely by modifying the URLCONF.

Yeah, I agree with you Max. For domains that have at least some overlapping url/view mappings, this solution would require duplication, which is not ideal. This solution satisfies only a small percentage of subdomain needs out there, thus making it not generic enough. However, I think such a "recipe", for lack of a better term, could be useful to some. I guess I'm not actually expecting this to become part of the Django API, but rather wanted to get the discussion started up again, to see if we could draft up a generic solution. I would be more than willing to be a part of such an effort.

updated -- it asumes your Site domain is just the base (e.g. mysite.com)

fyi - i have done something similar for my project http://sct.sphene.net/ but the middleware would also support regular expressions to define urlconfs .. a config would look like:

SPH_HOST_MIDDLEWARE_URLCONF_MAP = {
  r'^(P<groupName>\w+)\.sphene\.net': { 'urlconf': 'sphurlconfs.community_urls', }
}

all named arguments of the regular expression are then put into a thread local so it can be used by views to further distinguish between the domains. you can see the implementation at http://yourhell.com/svn/root/django/communitytools/trunk/sphenecoll/sphene/community/middleware.py ('MultiHostMiddleware')

(i'm using 'Groups' which are similar to the concept of the 'Sites' object in django as they are used to build different sites with different configuration for my wiki and forum apps) - if something like this would be put into django the flatpages application could be easily rewritten to use a thread local to retrieve the current Site object instead of using the settings.

Replying to tzellman@gmail.com:

I noticed issue #4438, and it wasn't exactly what I wanted, or the right solution, so I started researching.

Note that I've put a new ticket up in #4438 which handles the issue a lot better.

A bit too special-purpose for inclusion in Django, but a good candidate for djangosnippets.org.