I put together a simple django middleware based off the functionality of whitenoise except that it uses the staticfiles storage for finding/serving files. I am sure there are lots of improvements to be made on it but it demonstrates using the filestorage api to accommodate remote static files. It is roughly 100 lines. https://gist.github.com/thenewguy/a92e05a3568fb6f1cc7c
On Saturday, January 16, 2016 at 6:11:46 PM UTC-5, Gordon wrote: > > Apologies if this has already been mentioned but I read this thread in > full awhile ago and now everything is collapsed. > > If staticfiles serving is brought into django proper it would be nice if > the storage api was used so that staticfiles can be stored remotely. I > just ran into this looking at whitenoise so I figured I would mention it > here to be taken into consideration when putting an implementation together. > > On Friday, January 8, 2016 at 12:11:12 PM UTC-5, David Evans wrote: >> >> I've just pushed a simple middleware wrapper that lets you install >> WhiteNoise by adding: >> >> MIDDLEWARE_CLASSES = ( >> ... >> 'whitenoise.middleware.StaticFilesMiddleware', >> ... >> ) >> >> >> See: >> https://github.com/evansd/whitenoise/blob/master/whitenoise/middleware.py >> >> No messing with wsgi.py! >> >> This approach will be marginally less efficient than handling things at >> the WSGI layer, but the integration is much cleaner. >> >> On Tuesday, 29 December 2015 17:31:02 UTC, David Evans wrote: >>> >>> I'd be very happy to help with this. Two things to mention: >>> >>> 1. When I first wrote WhiteNoise the FileResponse class didn't exist and >>> so the only way I could access `wsgi.file_wrapper` was by wrapping the wsgi >>> application directly and bypassing Django. Now we have the FileResponse >>> class it would be possible to implement WhiteNoise as standard Django >>> middleware without having to edit wsgi.py. I think this would be a much >>> cleaner approach, and I don't think it will be too much work to implement. >>> I should have time to look at this next week. >>> >>> 2. Serving media files is a slightly different case. WhiteNoise was >>> designed around the assumption that it's serving a set of >>> developer-supplied, public files which remain unchanged during the lifetime >>> of the process. This simplifies a lot of performance and security concerns >>> that come with serving mutable, user-supplied files. At present, if you use >>> `add_files(settings.MEDIA_ROOT, prefix=settings.MEDIA_URL)` as you >>> suggested then WhiteNoise won't pick up any files that were uploaded after >>> the application was started -- at least, not unless you enable the >>> "autorefresh" setting which I explicitly don't recommend for production. >>> >>> Obviously it's possible to support this if we decide this is an >>> important goal but it will need more thought and will definitely be more >>> work than just supporting static files. >>> >>> On Tuesday, 29 December 2015 00:36:06 UTC, Tim Graham wrote: >>>> >>>> I'd like to work together with Dave to develop a proof of concept that >>>> integrates whitenoise into Django. I spent about an hour looking through >>>> whitenoise and our own static file serving code, and I think integrating >>>> whitenoise will yield a simpler user experience with about the same amount >>>> of code as have now. >>>> >>>> Essentially, we'd recommend adding something like this to existing >>>> wsgi.py files (it would be in the default startproject template) >>>> >>>> from whitenoise.django import DjangoWhiteNoise >>>> application = DjangoWhiteNoise(application) >>>> application.add_files(settings.MEDIA_ROOT, prefix=settings.MEDIA_URL) >>>> >>>> which would have the benefit of working out of the box in production >>>> too, I think. Of course, you could disable that based on settings.DEBUG or >>>> some other toggle. >>>> >>>> We could then deprecate: >>>> >>>> * django/contrib/staticfiles/views.py >>>> * django/contrib/staticfiles/management/commands/runserver.py >>>> * django/contrib/staticfiles/handlers.py >>>> * django/views/static.py >>>> >>>> Any objections to doing further investigation in this area? >>>> >>> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c2b85443-4d50-425d-8b33-a05a048d3957%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
