Re: Provide a way to pass kwargs when initializing the storage class

[Jarosław Wygoda]

 I'd like to introduce a file storage registry similar to 
BaseConnectionHandler (django/utils/connection.py) and EngineHandler 
(django/template/utils.py).

Example settings.py snippet:

STORAGES = {  # rename to FILE_STORAGES to make it more explictit?
'example': {
'BACKEND': 'django.core.files.storage.FileSystemStorage',
'OPTIONS': {
'location': '/example',
'base_url': '/example/',
},
},
}

Changes introduced by this pr are backward compatible. Users can still use 
existing settings to configure static and media storages.

Currently storages can be retrieved from the following objects:

django/core/files/storage.py:

get_storage_class
DefaultStorage
default_storage 

django/contrib/staticfiles/storage.py:

ConfiguredStorage
staticfiles_storage 

What do you think about deprecating them?

​https://github.com/django/django/pull/15610

FileField can be tackled in a separate pr.

czwartek, 12 listopada 2015 o 11:25:57 UTC+1 ja...@tartarus.org napisał(a):

> On 8 Nov 2015, at 08:31, Marc Tamlyn  wrote:
>
> > I'm definitely in favour of a format allowing multiple storage back ends 
> referred to by name. For larger sites it is not unusual to manage files 
> across multiple locations (eg several S3 buckets). The storage param to 
> FileField would be allowed to be the key, and there would be a get_storage 
> function like get_cache.
>
> It would remove the assymetry between the default backends and per-field 
> ones, which does feel a little odd. However I don’t think that’s a strong 
> enough reason to go for more complicated. Ballooning dictionaries can feel 
> overwhelming when looking at modern Django settings (for instance, the new 
> templates configuration is more daunting than it used to be), and as 
> pointed out, overriding is more fiddly.
>
> For testing, you need to be explicit per-field no matter what, so it’s a 
> change from an instance to a symbolic reference. The instance is probably a 
> variable anyway by declaration of the test model, which I suspect is 
> slightly easier to chase.
>
> So I’d be slightly more in favour of the terse, tuple-based syntax.
>
> J
>
> -- 
> James Aylett
> I make: devfort.com, spacelog.org
> Films: talktorex.co.uk
> Everything else: tartarus.org/james/
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7b11a017-b1c9-4277-aa1f-fb3b8a26ae18n%40googlegroups.com.

Re: For discussion: JSON-aware views for error responses

['Adam Johnson' via Django developers (Contributions to Django itself)]

+1 from me

- At least for 400, 500, and CSRF errors, send JSON (or empty response)
> back instead of HTML if the request is xhr or has JSON headers
>

It's possible to detect requests for JSON with request.accepts() , which
the previous PR from vanadium23 predates.

There's no way to detect "if the request is xhr" - we removed
request.is_ajax because it only detected requests made with jQuery and some
other libraries.


> - Make it easy to override the JSON like we can do with HTML
>

I think we don't need to add new extension points. If you want custom JSON
or HTML, you can provide your own views. These views can always "return
custom JSON *or* call Django's built-in views".

On Sat, Apr 23, 2022 at 6:16 AM vanadium23  wrote:

> I've done some work long ago. May be will help for someone.
> https://github.com/django/django/pull/8947
>
> On Friday, 22 April 2022 at 08:53:56 UTC+3 Tobias Bengfort wrote:
>
>> +1 from me.
>>
>> On 14/04/2022 11.03, Ville Säävuori wrote:
>> > And to be clear, I understand we already have middleware APIs and
>> > various settings to handle this but my point is that I think handling
>> > this in Django core (even as an optional setting or middleware) would
>> be
>> > most useful and right way to do this for the community.
>>
>> Can you provide some examples? I support the general idea, but having
>> some concrete APIs to discuss might be helpful.
>>
>> thanks
>> tobias
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/744c3b96-4c42-4eac-a451-5c6f6da446fdn%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0inQhY3q6oVZEV-ELmSYHKtHrHm53wJ2OQ68mq1JTpew%40mail.gmail.com.