django-urlalternatives - Alternative Django views under same URL pattern
- Version: 0.1 (or corresponding Mercurial revision hash)
- Author: GW
- License: GPLv3+
- Short description: Django URL alternatives provides a way for dispatching one URL pattern to the first alternative view (callback function) in a list that returns success. (Some sort of view that calls alternative views until one doesn’t return an error status code.)
- Primary repository (to clone using Mercurial: hg clone http://gw.tnode.com/django/f/django-urlalternatives/)
- Alternative repository and issue tracker at BitBucket
- PyPI page
From time to time you get in the situation where you need to provide the same content under different domains or subdomains, but under different URL patterns. A common ugly workaround for this is to run multiple Django instances (one for each domain), but Django also supports a way to change the used URLconf (URL patterns) per-request (How Django processes a request).
For this a middleware that implements the
process_request() method and changes the
urlconf atribute depending on the request needs to be added. For example if you want to have URL patterns (also called URL routes) based on the domain:
class SwitchURLconfMiddleware(object): def process_request(self, request): request.urlconf = 'project.urls.%s' % request.get_host().replace(".", "_").replace(":", "_")
For a request with page at
www.example.com, this would set the used URLconf to the Python import path
project.urls.www_example_com_8080. The example here replaces dots and semicolons to underscores so that it becomes a valid file and Python module name. The problem with this example Python code is that all possible domains must be configured before being used, because it will return errors otherwise.
The solution could be to first check if the per-domain URL configuration file exists and only then use it, else the default is used. There could also be a conditional statement checking for special domains with different URLconf and set them only then. This could also be implemented as a dict in
settings.py mapping domains and subdomains to different URL configurations.
Every time I began to work on a new Django project I found myself wondering how various directories and files should organized. After some projects I came to the conclusion that a perfect Django setup should be built inside a Mercurial or Git repository, use Django 1.3+ with Static app and use South for migrations.
The example Abcproject (browse - note hidden .hg* entries are not shown) represents the recommended directory and files organization structure that suits many common projects. To find all places where you need to change anything use
grep -ir abc .. It also includes a SysV init script for Debian systems and an update script for pushing changes to a production server. It doesn’t suite all possible needs, so you will need to modify it, but it is good for an example.
Basic South migration tool usage for an Django app
./manage.py schemamigration abcapp –initial(first time after a fresh new app)
./manage.py schemamigration abcapp –auto(for other simple migrations if you change the app model)
./manage.py migrate abcapp(apply migration)
In case you have many dependencies on other modules it is recommended that you describe them in a requirements file (eg.
req-stable.list). To get versions of all installed Python modules (package python-pip) use
pip freeze > req-fullfreeze.list, but you need to filter out just the ones you really depend on. Pip usually stores modules in systems dist-packages, but using virtualenv it can be also stored in your project directory. The requirements list can then be used by users to quickly setup a working environment with pip (read more).
Some other tips (not same):