2012-05-29 14 views
5

Ho un 1.3 progetto Django con queste opzioni in settings.pyDjango 1.4 (root_supporto, STATIC_ROOT, TEMPLATE_DIRS)

SITE_ROOT = os.path.dirname (os.path.realpath (__ file di __))

STATIC_ROOT = os.path.join (SITE_ROOT, 'statica')

root_supporto = os.path.join (SITE_R OOT, 'media')

TEMPLATE_DIRS = ( os.path.join (SITE_ROOT, 'modelli'),)

Ma in Django 1.4 di default settings.py viene spostato in sottodirectory con nome uguale al nome del progetto. A causa di quello statico, media e modelli le directory ora devono essere spostate nella stessa sottodirectory?

È questo che devo fare o semplicemente modificare le opzioni STATIC_ROOT, MEDIA_ROOT e TEMPLATE_DIRS?

So che entrambe le varianti sono OK, ma qual è la migliore pratica per questo in Django 1.4?

E so anche che ogni app può avere i propri modelli e directory statiche.

Ed è meglio mettere tutte le altre directory dell'applicazione all'interno della stessa sottodirectory? Questo non è ciò che sta accadendo per default utilizzando startApp manage.py

+0

Vedere https://docs.djangoproject.com/en/1.4/ref/django-admin/#startapp-appname-destination e https://docs.djangoproject.com/en/1.4/releases/1.4/# updated-default-project-layout-and-manage-py – rantanplan

+0

Ho visto questo ma non credo che risponda alle mie domande. Dicono solo che è possibile utilizzarlo con entrambi i modi –

+1

Oh ok. Bene sarebbe meglio mettere tutto il codice * operativo * rilevante sotto 'myproject/myproject' e poi avere' myproject/tests', 'myproject/docs' ecc. Per quanto riguarda lo static/media, dipende, di solito voglio il mio le app sono autonome/collegabili, quindi ogni mia app ha una propria cartella 'statica'. – rantanplan

risposta

7

OK lo schema che seguo è questo:

myproject/requirements.txt - pip pacchetti installabili

myproject/deployment - roba di distribuzione come i file di configurazione del server, infissi (dati fittizio), ecc

myproject/docs - docs del progetto

myproject/tests - test del progetto

myproject/myproject - Codice operativa del progetto (e settings.py, urls.py)

Espansionemyproject/myproject cartella:

myproject/myproject/app1 - un'applicazione normale (che comprende i suoi modelli specifici file/static)

myproject/myproject/app2 - un'altra app regolare (come sopra)

myproject/myproject/website - app semi speciale, per convenzione.

Questo website case app fondamentalmente 4 cose:

1) un vuoto models.py (in modo che Django lo considererà come un app valida)

2) un views.py con il punto di ingresso index vista. Forse alcune altre visualizzazioni che non si adattano ad altre app specifiche.

3) a management dir con personalizzato django commands che si applicano all'intero progetto.

4) a templates dir che contiene 404.html e 505.html. Inoltre ha una sottodir denominata website che include modelli html universali/base che ogni altra app extends, più il index.html.

5) a static dir con subdir successivi denominati css, js e media per file statici globali.

Niente di esotico, immagino. Penso che la maggior parte delle persone segua uno schema simile, ma mi piacerebbe qui qualche inefficienza con questo, se esiste.

EDIT: per quanto riguarda le impostazioni per la produzione VS sviluppo Io uso il modello settings_local popolare, che potete leggere here e alla fine sarà piombo si here, che descrive un modello migliore.

+0

Cosa si fa per le diverse impostazioni per locali/dev/test/QA/UAT/ambienti di produzione, utilizzando questa configurazione? Hai pensato di inserire impostazioni separate sotto la directory di implementazione? – Jordan

+0

@Jordan Faccio ciò che la maggior parte delle persone ha fatto fino a poco tempo fa. Ho un settings_local.py sullo stesso livello di settings.py. Quindi settings.py esegue 'try: from settings_local import * tranne: pass'. settings_local.py è ovviamente ignorato dal mio VCS. Penso che ci siano soluzioni alternative e migliori là fuori, anche se oggi. È un argomento intero a sé stante. – rantanplan

+0

Anche io faccio lo stesso di rantanplan –

Problemi correlati