I should probably finish off my toy working on the same lines... but
introducing my earlier comments about per-source paths and permissions
mixins...
Very much a WIP, but I'm sure you'll see the idea:
https://gist.github.com/funkybob/a89c10e24716a4ce55cf
--
C
On 18/01/16 09:58, Gordon wrote:
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
<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
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to django-developers@googlegroups.com
<mailto: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
<https://groups.google.com/d/msgid/django-developers/c2b85443-4d50-425d-8b33-a05a048d3957%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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/569C1D70.5070300%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.
