Aymeric,
That's an interesting idea I hadn't considered -- perhaps storages could
also then be marked trusted and untrusted, and processing/display of those
files could take it into consideration. I agree the security requirements
are different.
Florian,
I agree that changing APIs would cause confusion. It may be possible to
provide an upgrade path as we did for DATABASES and CACHES, though.
The benefit I'm shooting for is to make media handling more modular and
clear, rather than seeming a special case.
As for instances, yes, I was using that as a shorthand -- even so, it
could be a dict with common interface (**kwargs) handed to the storage
backend. FileSystemStorage takes location=None, base_url=None, s3boto
takes acl=None, bucket=None, **settings. I doubt there will be much common
interface, but to me this supports the argument that aliases would be
useful -- right now it is hard to construct a storage backend dynamically
without coding to a specific store. connections['default'] is a powerful
abstraction.
This could be a migration path:
FILE_STORAGES = {} -> expands to
'static': {
'class': 'django.contrib.staticfiles.storage.StaticFilesStorage',
'trusted': True, # based on Aymeric's feedback
'OPTIONS': {
'location': settings.STATIC_ROOT,
'base_url': settings.STATIC_URL
},
},
'media': {
'class': 'django.core.files.storage.FileSystemStorage',
'trusted': False,
'OPTIONS': {
'location': settings.MEDIA_ROOT,
'base_url': settings.MEDIA_URL
}
}
}
On Mon, Sep 29, 2014 at 2:26 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> 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 <jdu...@gmail.com> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> 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
> <https://groups.google.com/d/msgid/django-developers/CAM0i3f6sMwgFxAVC4P6U9Z97zAd%2B%3DmDV837KbYZmBx3ycuu%2BMg%40mail.gmail.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 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
> <https://groups.google.com/d/msgid/django-developers/6C594E01-F946-4806-B569-2221832205A3%40polytechnique.org?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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAM0i3f4zEyNnTcYvySb6hwBRypgL6uMMA3K2KFUimuRRu%2B%3D7%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
