A Django 1.3 proposal. It is a pretty small feature/change in some ways, but needs some discussion.
= Motivation = This is intended to make it easier to cope with the distinction between user provided media and developer provided media. This is a significant pain point when it comes to source control/deployment/backup. For example, it would be much better when uploading my source if I could do 'rsync --delete', so that the files on the server are exactly what I expect - extra files can cause all kinds of bugs. But I can't do that, as it would delete all the user uploaded media (or at least the symlinks to it). Nor can I simply upload to a fresh directory - I would still need to mess around with symlinks or moving files to get user uploaded media where it is expected to be. Also, for security it would be good to have the whole source code directory (including templates, javascript etc) to be write protected from the point of the webserver. But user uploaded files mess that up. = Options = We could: 1) add 'STATIC_URL' and use it for widgets and all other media. 2) add 'USER_MEDIA_URL' and 'USER_MEDIA_ROOT' and use them for file storage. (using backwards compatible defaults either way). If 1), then, additionally, do we need 'STATIC_ROOT' as well? What for? It wouldn't be used anywhere in Django. I was going to go for 1), like the ticket suggests, but I now think that 2) is a much better idea. I strongly suspect that static media are far more common than user uploaded files, so doing 2) will require far fewer changes to existing apps. Also, I suspect that almost all direct use of MEDIA_URL in apps will be for static media: file fields provide a URL attribute which automatically includes MEDIA_URL, but it will be common to use MEDIA_URL for calculating URLs (e.g. in templates). Also, use of 'media' for static media is consistent with ADMIN_MEDIA_PREFIX, which is lost with option 1) If we go with 2), there is a good case for not adding USER_MEDIA_URL to the media context processor - I can't imagine know when it would be needed in the normal case. If you want to generate a URL to a file stored in a model, the only sensible way to do it is instance.somefile.url, which handles it for you. If we go for 1) we will need both STATIC_URL and MEDIA_URL in the media context processor for backwards compatibility. Are there any common uses cases I have not accounted for? Finally, once these things are sorted out, is this a small enough change that I should go ahead and commit it, or should I wait for voting on Django 1.3 features? Thanks, Luke -- "Oh, look. I appear to be lying at the bottom of a very deep, dark hole. That seems a familiar concept. What does it remind me of? Ah, I remember. Life." (Marvin the paranoid android) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
