Okay, I've been working with django for a little while, and I thought I'd share my experience and point out some things that bugged/confused me at first. Looking at settings.py:
MEDIA_* is poorly named since they overload the meaning of 'media' which otherwise relates back to the static css/img/js content. MEDIA_UPLOAD, or something else would be clearer. If this is not changed then the description needs to be made more obvious. MEDIA_URL is basically invalid if left blank - it resolves to a file in the root server directory. It seems like it should work with relative urls (so not to specify the domain name - great for debugging from local sources). It might be beneficial to remind the user that they need to do two things to make the configuration work: 1) add the exception to their .htaccess file (if media_url is a child of the django root) to let their httpd find their directory 2) add the 'if DEBUG..." conditional and urls.py mapping if they want to use the local test server. There should be some mention about that here.. I'm sure it would make the configuration process more clear. Perhaps: "MEDIA_UPLOAD_ROOT: absolute location to store uploaded content on the local file system. This directory needs to be writable by the server process." "MEDIA_UPLOAD_URL: Absolute URL (http://whatever.com/media/) or relative to the host url (/media/) from which to serve uploaded media" Supporting the Built-in and Production server in the General Case ================================================================ -MEDIA_UPLOAD is a special case for django, since it is necessary for the django process to receive files (can't be delegated to remote server, without much more work [I suppose you could have a form submit to another server, but then you'd lose any benefit]) For all other static content serving, django avoids making any commitments as to location. I think it is a smart idea to separate the concerns of the dynamic and static content. Django shouldn't be responsible for locating or serving these files. That being said, the current setup (especially when using the built-in server) makes this task more difficult than it needs to be. At the moment, anything non-django being served by the same host must be specified as an exception in both the .htaccess file (to prevent urls.py lookup, please correct me if I'm wrong), and in urls.py (for the local test server, again as recommended in a "if debug" conditional [also maybe it should be an if "debug_server"]). This is duplication. The separation of concerns becomes a hindrance to flexibility - I'm not sure how Adrian implemented it, but when he moved his static hosting to the Amazon service I'm sure he would have liked to have a STATIC_URL setting which would have allowed him to simply insert a new base url, and have requests automatically redirected to the remote server transparently. No matter how easy it is to modify the template, or add in dynamic references is (say by prepending {{media_host_root}}) this is still bound to be more error prone and require thought on the part of the media producer. This is nothing that can't be handled with exclusively in mod_rewrite, at least in production. And in the urls.py for testing. The problem, and obvious downside to just doing it that way: 1) two different configs to keep in sync 2) all requests are still made to the django host, so there is still the overhead of dealing with each redirect (but not serving content!) The solution I'd recommend is to extend urls.py to emit the redirects. If .htaccess has been fixed, they should never be reached anyway. That way, both testing and production configuration can be unified in one place. This is a hard issue. I know this decision was not made lightly. I agree that it is doesn't make sense to have django be responsible for actually serving static media. But a middle ground solution would be easier to maintain. Gil Pinheiro --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
