Hi Jeremy, That could be useful for any website that gets some of its assets from the code (JS, CSS), others from a CDN (eg. product photos), others from another CDN (eg. tutorial illustrations), etc. However we'd have to make sure it beats the common solution of having a model instance for each file and a method that generates the URL.
Even though the documentation has improved a lot, static files still tend to confuse beginners. On one hand, making them less of a special case could help. On the other hand changing the APIs will create confusion again. Finally, static and media (user-uploaded) file have different requirements, especially in terms of security. I think it's useful to keep the concepts separate, even if they ultimately depend on the same APIs -- basically the Storage base class that defines the usual file APIs plus an URL. -- Aymeric. On 29 sept. 2014, at 22:46, Jeremy Dunck <[email protected]> wrote: > 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. -- 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/6C594E01-F946-4806-B569-2221832205A3%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
