Am 27.05.2010 um 17:23 schrieb Luke Plant: > 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.
Couldn't agree more. > = 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 also prefer 2), the ambiguity of MEDIA_* strikes me as unfortunate and the Django core seems like the right place to fix this. For django-staticfiles I used STATIC_* for the media files included in apps (et al) which is of course only slightly better. > 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) Yeah, good point. > 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? I'd like to extend this proposal after having talked to a few people at the sprints to include the following features of django-staticfiles [1]: - a media files path resolver -- following a similar directory structure as the app templates loader (<app>/media/<app> vs. <app>/templates/<app>) - build_static -- a mangement command that'll collect media files from apps from various locations using the media files path resolver and uses a file storage backend to copy (or link to) the found files (file storage backend by default), used during deployment - an extended media file serving view that uses the media files path resolver (in debug mode), backwards compatible replacement for django.core.servers.basehttp.AdminMediaHandler I'd be happy to commit myself to that feature which proved itself invaluable in real projects. Jannis 1: http://pypi.python.org/pypi/django-staticfiles -- 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.
