Progetto di progettazione/layout di FS per progetti di django di grandi dimensioni

Question

Qual è il modo migliore per impaginare un grande progetto di django? Le esercitazioni forniscono semplici istruzioni per l'impostazione di app, modelli e viste, ma ci sono meno informazioni su come app e progetti devono essere suddivisi, quanta condivisione è permessa/necessaria tra le app in un progetto tipico (ovviamente dipende in gran parte il progetto) e come/dove conservare i modelli generali.

Qualcuno ha esempi, suggerimenti e spiegazioni sul motivo per cui un determinato layout del progetto è migliore di un altro? Sono particolarmente interessato all'incorporazione di un gran numero di test di unità (2-5 volte la dimensione della base di codice effettiva) e estensioni/modelli di stringhe.

Answer 1

Le linee guida principali sono simili a qualsiasi altro progetto di codice di grandi dimensioni. Le app devono rispondere a una singola responsabilità chiaramente definita. Il nome "applicazione" è un termine improprio; Le app Django dovrebbero essere pensate più come componenti riutilizzabili che possono essere collegati per creare un'applicazione reale. I test per ogni app devono essere contenuti all'interno di quell'app. Le app dovrebbero essere disaccoppiate l'una dall'altra il più possibile, ma chiaramente ci saranno delle dipendenze, quindi l'obiettivo dovrebbe essere quello di mantenere il grafico delle dipendenze il più semplice e sano possibile.

Preferisco mantenere tutti i modelli per un progetto in una singola directory di modelli a livello di progetto, con una sottodirectory per ogni app (utilizzando una sottodirectory template per ogni app è una convenzione molto forte in Django, poiché evita il nome del modello collisioni tra app). Il motivo per una singola directory di modelli a livello di progetto è che i template, gli alberi di ereditarietà dei template e i nomi dei blocchi possono essere specifici del progetto, quindi è difficile fornire modelli di app "predefiniti" che possano essere collegati a qualsiasi progetto.Ci sono stati alcuni tentativi di stabilire convenzioni di denominazione standard per i modelli di base del sito e i blocchi che definiscono, ma non ho ancora visto uno standard emergere (il modo in cui fanno le cose su Pinax è probabilmente il più vicino a standard).

Per "esternalizzazione delle stringhe", se si intende i18n e l10n, Django ha un forte supporto per questo e le posizioni standard in cui inserisce i file .po - controllare lo docs.

Answer 2

Questa pagina fa un buon lavoro di affrontare alcune delle mie domande: http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/

In particolare:

1. Per definire i tag di template personalizzati o filtri, è necessario creare un sub-directory nella domanda di directory chiamata templatetags e deve contenere un file chiamato __init__.py in modo che possa essere importato come modulo Python.
2. Per definire i test di unità che verranno automaticamente rilevati dal framework di test di Django, inserirli in un modulo chiamato test (che può essere un file denominato tests.py o una directory denominata test). Il framework di test troverà anche qualsiasi doctest in quel modulo, ma il posto preferito per questi è, ovviamente, le docstring delle classi o delle funzioni che sono state progettate per testare.
3. Per fornire un SQL personalizzato che verrà eseguito immediatamente dopo l'installazione dell'applicazione, creare una sottodirectory denominata sql all'interno della directory dell'applicazione; i nomi dei file dovrebbero essere gli stessi dei nomi dei modelli su cui opereranno le tabelle; ad esempio, se si dispone di un'app denominata weblog contenente un modello denominato Entry, il file sql/entry.sql all'interno della directory dell'app può essere utilizzato per modificare o inserire dati nella tabella di voci non appena è stato creato.

La nota su tests.py e test (la directory) vale anche per i modelli, che aiuta a risolvere il problema di avere modo di molti test (o modelli) per un file.

Vorrei ancora vedere alcuni esempi/suggerimenti per l'interruzione di app/progetto e grandi siti di django che funzionano bene.

Answer 3

Il Pinax project è costruito attorno all'idea di piccole app riutilizzabili, che sono facilmente riunite in un progetto. Hanno utilizzato il progetto Cloud 27 come progetto dimostrativo.

Il progetto Django su cui sto lavorando (chiamato Basie. È pre-0.1, quindi nessun collegamento ancora.) Sta cercando di seguire il modello Pinax, e finora sta funzionando abbastanza bene.

Answer 4

Il layout corrente deriva dal fatto che voglio avere una versione di prova dei miei siti. Ciò significa avere due progetti per ogni sito, dal momento che hanno bisogno di configurazioni diverse e mi costringe a spostare tutte le applicazioni dai progetti.

Ho creato due cartelle: $ APP_ROOT/devel e $ APP_ROOT/prod. Questi contengono tutte le app. Usando il controllo del codice sorgente (nel mio caso git) ho le app in sviluppo alla revisione HEAD, mentre le app in prod sono bloccate sul tag PROD. I modelli hanno anche una propria cartella con lo stesso layout delle app.

Ora sono in grado di fare tutto il mio sviluppo nella cartella devel-apps e nella cartella modello corrispondente. Quando ho qualcosa di cui sono felice, contrassegno quella revisione e aggiorno i pungoli.

Answer 5

ho trovato il layout di Zachary molto utile Zachary Voase’s Blog » Django Project Conventions, Revisited.

Answer 6

mi piace molto Randall Degges' post su questo argomento. Lascia fuori le informazioni su come incollare i file delle impostazioni insieme, ma avrò un post su cui sarò in grado di collegarmi, ma per ora chiunque può controllare my repo dove includo qualche direzione nel readme.