OT...just writing down this which came to me on the train this morning as I
read this thread
Does anyone else foresee the practice of having an "appconfig.py" full of
subclasses of AppConfigs becoming common?
Seems like a nice parallel to settings, allowing a project to specify
per-app config overrides in a central location. And lets us dispense with
per-app settings with faux namespaces...
--
C
On 3 July 2014 07:17, Andre Terra <andrete...@gmail.com> wrote:
>
> On Wed, Jul 2, 2014 at 5:14 PM, Tomas Ehrlich <tomas.ehrl...@gmail.com>
> wrote:
>
>> I would really like to see app configs with app-specific settings.
>> Personally, I don't like flat settings where namespaces are created
>> with prefixes (eg. STATICFILES_ ).
>>
>> The idea of overriding class attributes in AppConfig seems promising.
>>
>
> I wholeheartedly agree. Flat settings in faux namespaces seems very
> unpythonic to me. Even though it should prove slightly more cumbersome to
> have to edit settings in many different files during development, having
> the correct place for each setting makes for a much more organized
> structure.
>
> Forgive me if this question sounds silly, but how would settings for, say,
> staticfiles be accessed from third-party apps? Would we still use from
> django.conf import settings? If not, then how would we know to look for
> 'acme.apps.AcmeStaticFilesConfig' or 'staticfiles'?
>
> Also, shouldn't something like the ignore_patterns list be included in a
> wrapper settings attribute of StaticFilesConfig? This way we could easily
> access settings through
> apps.get_app_config('some_app').settings['ignore_patterns'].
>
> Based on Thomas' proposal:
>
>
> class Command(BaseCommand):
> # ...
> def set_options(self, **options):
> # ...
> staticfiles_config = apps.get_app_config('staticfiles')
>
>
> - self.ignore_patterns = staticfiles_config.ignore_patterns
>
>
> + self.ignore_patterns = staticfiles_config.settings['ignore_patterns']
>
>
>
> Sorry if this is completely wrong! I'm a long time lurker and hobbyist,
> but not a developer by occupation.
>
> Cheers,
> AT
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/CAKBiv3ygq-s7E2UkySW7ZEXEKZe5q1jOz9bhzy32ZCfc8316DQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAKBiv3ygq-s7E2UkySW7ZEXEKZe5q1jOz9bhzy32ZCfc8316DQ%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" 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/CAG_XiSD5k7r8qSH3micGgHXwEwkJvHyg_y4FmYA-vfW-vj-fzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
