On Thu, Oct 21, 2010 at 12:25 PM, Jannis Leidel <jan...@leidel.info> wrote:
> Ian, > > > I thought about this too and had a long thread on Twitter with jezdez > about staticfiles. It occurred to me that adding more apps to contrib was > kind of a bad idea. I know "everyone" uses admin etc. but I was of the > understanding that contrib apps are optional apps for django but staticfiles > doesn't seem to be that way. > > Repeating what I said briefly on Twitter, the reason to extend this ability > was to give a better answer to "How does Django help me to manage and deploy > static files?" In that sense, the contrib staticfiles app is really just an > extension of the tools that Django already provides, the media context > processor, the static view and the WSGI Middleware for runserver -- plus a > few optional helpers like a template tag, management commands and extensible > file finders that work similar to template loaders. All of which are not > required to run a Django site. > > > The core 'django.views.static.serve' and > 'django.core.context_processors.media' are deprecated in favor of the > staticfiles equivalents in contrib. Is the idea that the contrib app is a > stepping stone to providing core functionality? i.e. It was put in contrib > to maintain backwards compatibility for at least enough time to satisfy the > deprecation policy? I'm also getting worried in general about adding more > and more functionality to Django that doesn't really *need* to be there. > > Moving pieces of code arund is part of the development process and hasn't > really been done just for the sake of it. Personally, I don't share your > worry about added functionality, as long as it solves real world problems, > which staticfiles certainly did for me, as well as for the hundreds of other > users, too. > I certainly agree it's useful. I use it for my projects. I just don't think it needs to be in core. Anyone that needed this functionality could simply install and use django-staticfiles. For me, adding everything and the kitchen sink to Django with no clear scope is worrysome. Anyway, this part of the conversation at least isn't productive so it's the last you'll hear from me on it. > > On a seperate topic, it occurred to me that if you wanted to use the same > backend for your STATIC_STORAGE as you use for DEFAULT_STORAGE then you'll > run into problems if you want to use different options for each. The docs > mention django_storages but you'll be hard pressed if you want to store your > static and user media in different buckets. It's one of the reasons I added > options to the constructor for the s3boto backend (I'm the current > maintainer) in django_storages and added a STATIC_STORAGE_KWARGS in my > branch of staticfiles on bitbucket. Not sure it was the best solution, but > it works. > > I would like to stress that using the same storage backend for static files > and user generated files is considered bad practice, which is also why I > haven't applied your changes in the staticfiles app. It was a distinct > design decission to have both kinds of files in different locations and to > provide the STATICFILES_STORAGE next to the DEFAUL_STORAGE setting for > further extension. I can imagine situations where you would want to store uploaded data and static files in S3 (but in different buckets or directories) to take advantage of the Cloudfront CDN. That just one example but I'm sure there are others such as storing static media in a normal directory and uploaded media on a shared NFS mount (some people do that). I suppose subclassing the backend simply to provide different options would be doable but didn't seem as nice at I need to support it in code rather than just changing some settings. That said, the StaticFilesStorage seems to do exactly what you described so if it's discouraged for some reason (which I'm still not sure I understand) then I'll respect your API. > I can't comment on the backends in django-storages much since I'm not very > familiar with the code, but I assume that it's possible to subclass those > storage backends to change the options, as needed. An extended example on > djangosnippets.org or in the django-storages docs would cetainly be useful > to have of course. If you have any suggestions regarding the staticfiles > docs with regard to using other storage backends, I'd appreciate your help. > For the S3BotoBackend at least, you would just need to subclass and override the __init__() method to call super() with the options you need, which would mostly likely be environment specific and set in the settings.py anyway. -- Ian http://www.ianlewis.org/ -- 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.
