Right now, I think that static/media handling is fairly confused in the
documentation, and a bit confused in the code itself.
We have a few special-cases floating around:
default_storage (needed for legacy before storage backends)
staticfiles_storage (needed for collectstatic/handling)
{% static %} handles mapping relative URLs to absolute URLs, but does
not allow using a storage engine other than {% STATIC_URL %}
or staticfiles_storage.
I was surprised to find that
django.contrib.staticfiles.templatetags
and
django.templatetags.static
both have implementations of {% static %} with slightly different semantics
(one based on STATIC_URL, one based on staticfiles_storage).
It seems to me that it might be useful to introduce aliases (as in CACHES
and DATABASES) in order to allow referring to storage engines in a
less-coupled way.
{% static %} could then take a storage engine alias, and the special-case
of repo-static file handling and user-uploaded file handling could mostly
go away.
MEDIA_URL/MEDIA_ROOT and STATIC_URL/STATIC_ROOT as special cases could
(after a deprecation process) go away in favor of these storage aliases.
The syntax I'll hazard as a proposal could be:
FILE_STORES = {
'static': <Storage instance>,
'dynamic': <Storage instance>,
....
'alias1': 'alias2' # possibly map aliases to satisfy app-required
aliases.
}
{% file relative-url storage-alias %}
Would do people think of this idea?
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAM0i3f6sMwgFxAVC4P6U9Z97zAd%2B%3DmDV837KbYZmBx3ycuu%2BMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
