2016-06-28 7 views
16

Questa domanda è stato chiesto in precedenza: oggetti What is the purpose of apps.py in Django 1.9?Qual è lo scopo di apps.py in Django?

configurazione dell'applicazione metadati per un'applicazione. Alcuni attributi possono essere configurati nelle sottoclassi di AppConfig. Altri sono impostati da Django e di sola lettura.

Tuttavia, che cosa significa per i metadati per l'applicazione? È limitato solo a quelli AppConfig metadata:name, verbose_name, path, label, module, models_module?

Oppure ha senso per estende beyonds i metadati predefinita, in particolare per l'applicazione dei metadati specifico, ad esempio in blog applicazioni che abbiamo una configurazione formato della data, di solito definita come segue:

# File: settings.py 
BLOG = { 
    'DATE_FORMAT': 'ddMMYYY', 
} 

A quel viene utilizzato come segue:

# File: blog/<...>.py 
from django.conf import settings 
date_format = settings.BLOG['DATE_FORMAT'] 

Al contrario, si potrebbe spostare questa configurazione informazione su blog/apps.py come BlogConfig?

class BlogConfig(AppConfig): 
    name = 'blog' 
    verbose_name = 'Awesome Blog' 
    date_format = 'ddMMYYYY' 

In modo che tutto il codice dell'applicazione, date_format viene utilizzato da:

# File: blog/<...>.py 
from django.apps import apps 
date_format = apps.get_app_config('blog').date_format 

Sembra a me che settings.py è progetto impostazioni, ma non un impostazioni dell'applicazione. Quindi è più suoni mettere tutte le impostazioni dell'applicazione all'interno di apps.py quindi settings.py. Quindi, questa è un'assunzione/argomento/convenzione valida per me per inserire la configurazione dell'applicazione all'interno di apps.py anziché settings.py?

risposta

3

Un progetto è univoco per installazione di django, mentre un'app dovrebbe essere riutilizzabile.

Se si inseriscono le impostazioni delle app personalizzate nel settings.py del progetto, si suppone che siano modificabili, specialmente se (o altri) riutilizzate questa app per un altro progetto.

Ora, se si inseriscono queste impostazioni personalizzate nell'app apps.py, ciò significa che non saranno modificabili in base al progetto. In questo caso non c'è motivo di inserirli in apps.py piuttosto che in un sottomodulo constants. A meno che non si desidera fornire un insieme limitato di possibili configurazioni:

class BlogConfig(AppConfig): 
    name = 'blog' 
    verbose_name = "Blog" 
    date_format = 'ddMMYYYY' 


class CustomizableDateFormatBlogConfig(BlogConfig): 
    date_format = getattr(settings, 'BLOG_DATE_FORMAT', BlogConfig.date_format) 


class I18nBlogConfig(BlogConfig) 
    verbose_name = _("Blog") 

Il default_app_config sarebbe BlogConfig ma il progetto utilizzando l'applicazione sarebbe in grado di scegliere CustomizableDateFormatBlogConfig o I18nBlogConfig pure.

Tuttavia questo rende app molto poco personalizzabili.Nell'esempio di cui sopra, se si vuole lasciare che gli utenti app usano sia CustomizableDateFormatBlogConfig e I18nBlogConfig, si avrebbe bisogno di fare qualcosa di simile:

class BlogConfig(AppConfig): 
    name = 'blog' 
    verbose_name = "Blog" 
    date_format = 'ddMMYYYY' 


class CustomizableDateFormatMixin: 
    date_format = getattr(settings, 'BLOG_DATE_FORMAT', BlogConfig.date_format) 


class I18nMixin: 
    verbose_name = _("Blog") 


class CustomizableDateFormatBlogConfig(CustomizableDateFormatMixin, BlogConfig): 
    pass 


class I18nBlogConfig(I18nMixin, BlogConfig): 
    pass 


class I18nCustomizableDateFormatBlogConfig(I18nMixin, CustomizableDateFormatMixin, BlogConfig): 
    pass 

casi Quindi, a parte specifici in cui è necessario fornire un insieme di alcuni differenti configurazioni di app, è meglio mettere le impostazioni delle app personalizzate nel settings.py del progetto.