Amit Upadhyay wrote:
> Static files are best served by basic http servers and not django.
> Django tries to support serving static files, but that is only for
> convenience in development. Just now I finished deploying a django
> project under mod_pythong/apache, and my approach was to setup a /static
> url pointing to a directory containing static files and I setup django's
> static file serving view for that, I did that till the development
> lasted, and then I moved it to apache, and put a:
>
> <Location "static">
> SetHandler None
> </Location>
>
This is the exact approach that I use, but it doesn't avoid the issue
that Greg is talking about. That is; a series of static-file URLs are
likely to be associated with any given application, and the path to them
isn't necessarily going to be the same for each installation of that
application (because, amongst other reasons, there are many different
ways they could be deployed - as you've just shown).
Personally, I'm happy using root-relative URLs for the moment. The
resulting directory structure isn't overly complicated, so could be
easily replicated. However, I can think of a couple of approaches to
ease the problem:
1) Make it a standards that your apps will have all their media in
/static/appname/. This isn't hard to do, and produces an easily portable
directory tree. Root-relative (or absolute) again, though.
2) Create all your templates so that static media urls look like
"{{base_url}}/image.png". Define a constant at the top of the file
defining your views, and store the appropriate base URL in it. Pass this
constant into your template renderer. This means that where you are
storing your static files is only hardcoded once, and can easily be changed.
In fact, I think I've seen a couple of people write function decorators
and other nifty tricks specifically to do things like render templates
with additional variables... just a thought.
The problem with both of these approaches is that if you're
using an app (or several) that you haven't written yourself, they won't
necessarily follow this standard, and could conflict.
-Andy
