Questo documento spiega alcuni concetti fondamentali della filosofia Django che gli sviluppatori hanno usato nella creazione del framework. Lo scopo primario è quello di spiegare il passato e guidare verso il futuro.
\nUno degli obiettivi primari dello stack di Django è loose coupling and tight cohesion. I vari layer del framework non dovrebbero «essere a conoscenza» l’uno dell’altro se non strettamente necessario.
\nPer esempio, il sistema di template non sa nulla delle richieste web, il layer di database non sa nulla di come vengano mostrati i dati ed il sistema delle views non si interessa di quale sistema di template il programmatore utilizzi.
\nSebbene Django venga fornito come full stack per convenienza, i pezzi dello stack sono indipendenti uno dall’altro quando possibile.
\nLe applicazioni Django dovrebbero usare meno codice possibile; non dovrebbero esserci boilerplate. Django dovrebbe trarre pieno vantaggio delle capacità dinamiche di Python, come l’introspezione.
\nIl punto di utilizzare un framework web nel ventunesimo secolo è rendere gli aspetti noiosi dello sviluppo web veloci. Django dovrebbe permettere uno sviluppo web incredibilmente rapido.
\nOgni singolo concetto e/o pezzo di dato dovrebbe vivere in uno ed un solo posto solo. La ridondanza è una cattiva abitudine. La normalizzazione è una buona abitudine.
\nIl framework, entro limiti ragionevoli, dovrebbe dedurre il più possibile dal meno possibile.
\n\nQuesto è un principio primario di Python presente in PEP 20, e significa che Django non dovrebbe essere troppo «magico». La magia non dovrebbe esserci a meno che non ci siano delle valide ragioni. La magia merita di essere usata solo se crea grandi vantaggi non raggiungibili in altri modi, e non è implementata in modo da confondere gli sviluppatori che tentano di imparare come usare una feature.
\nIl framework dovrebbe essere consistente a tutti i livelli. La consistenza si applica a tutto, dal low-level (lo stile di codice Python usato) all” high-level («l’esperienza» di uso di Django.)
\nI campi non dovrebbero dare per scontati certi comportamenti basati solo sul nome del campo. Questo richiederebbe troppa conoscenza del sistema ed è incline ad errori. Invece, i comportamenti dovrebbero essere basati su argomenti chiave e, in alcuni casi, sul tipo del campo.
\nI modelli dovrebbero incapsulare ogni aspetto di un «oggetto» seguendo il pattern design Active Record definito da Martin Fowler
\nPer questo motivo, i dati sono rappresentati da un modello e dalle informazioni su di essi (un nome di facile lettura, opzioni come l’ordinamento di default, ecc…) sono definiti nella classe modello; tutte le informazioni necessarie per comprendere un modello dovrebbero trovarsi nel modello.
\nI principali obiettivi delle API del database sono:
\nDovrebbe eseguire dichiarazioni SQL il minor numero di volte possibile, ed ottimizzare le dichiarazioni internamente.
\nPer questo è necessario che gli sviluppatori chiamino save() esplicitamente, piuttosto che lasciare al framework il compito di salvarle in background.
Anche per questo motivo esistono i metodi select_related() di QuerySet. È un booster di performance opzionale per i casi più comuni di selezioni di «ogni oggetto correlato».
Le API del database dovrebbero permettere dichiarazioni ricche ed espressive con la minima sintassi possibile. Non dovrebbero fare affidamento sulle importazioni di altri moduli o su oggetti helper.
\nLe Join dovrebbero essere eseguite automaticamente, in background, quando necessario.
\nOgni oggetto dovrebbe essere capace di accedere ad ogni oggetto relazionato, globalmente. Questo tipo di accesso dovrebbe funzionare in entrambi i sensi.
\nLa API per il database dovrebbe capire che è una scorciatoia ma non necessariamente qualcosa di estremamente importante. Il framework dovrebbe rendere semplice scrivere dell” SQL personalizzato - intere espressioni o semplicemente clausole «WHERE» come parametri custom delle chiamate API.
\nLe URL in una app Django non dovrebbero essere accoppiate al codice Python sottostante. Legare le URL ai nomi di funzioni Python è una cosa brutta e cattiva.
\nIn tal senso, il sistema di URL di Django dovrebbe permettere che URL nella stessa app siano differenti per contesti differenti. Per esempio, un sito potrebbe collocare le storie in /stories/, mentre un’altro potrebbe usare /news/.
Le URL dovrebbero essere il più flessibili possibile. Qualsiasi URL design che possa essere concepito, dovrebbe essere permesso.
\nIl framework dovrebbe rendere semplice (o perfino semplicissima), per uno sviluppatore, la creazione di URL belle piuttosto che brutte.
\nLe estensioni dei file nelle URL delle pagine web dovrebbero essere evitate.
\nLe virgolette in stile «vignetta» nelle URL meritano di essere punite severamente.
\nTecnicamente, foo.com/bar e foo.com/bar/ sono due URL differenti ed i robot dei motori di ricerca (ed alcuni tool di analisi del traffico) li tratterebbero come pagine diverse. Django dovrebbe fare uno sforzo per «normalizzare» le URL in modo che i robot dei motori di ricerca non cadano in confusione.
Questa è il ragionamento che sta alla base dell’impostazione APPEND_SLASH.
Noi vediamo un sistema di template come un tool che controlla la presentazione e le logiche correlate alla presentazione – e questo è quanto. Il sistema di template non dovrebbe gestire funzionalità che vanno oltre questo obiettivo di base.
\nLa maggior parte dei siti dinamici utilizza uno stile comune a tutto il sito - una intestazione comune, un piè di pagina, una barra di navigazione, ecc. Il sistema di template di Django dovrebbe rendere facile mettere questi elementi in un unico posto, eliminando il codice duplicato.
\nQuesta è la filosofia dietro all” ereditarietà dei template.
\nIl sistema template non dovrebbe essere strutturato in modo tale da ottenere solo HTML. Dovrebbe essere ugualmente valido per generare anche altri formati basati sul testo o anche solo plain text.
\nL’utilizzo di un motore XML per fare il parse dei template introduce nuovi errori umani nell’editing dei template – ed introduce un livello inaccettabile di overhead nel processamento dei template.
\nIl sistema di template non dovrebbe essere progettato in modo da poter mostrare bene i template negli editor WYSIWYG, come ad esempio Dreamweaver. Sarebbe una limitazione troppo grande e non permette alla sintassi di essere bella come è. Django si aspetta che gli autori dei template siano in grado di fare editing direttamente sull’HTML.
\nIl sistema di template non dovrebbe fare magie con gli spazi bianchi. Se un template include spazi bianchi, il sistema dovrebbe trattarli così come tratta il testo – mostrandoli. Ogni spazio bianco che non si trova in un template tag dovrebbe essere mostrato.
\nLa finalità non è quella di inventare un linguaggio di programmazione. Il fine è quello di offrire un buon numero di funzionalità «da programmazione», come il branching ed il looping, essenziali per le decisioni a livello di presentazione. Il :ref:`Linguaggio dei Template di Django (DTL)<template-language-intro> mira ad evitare la logica avanzata.
\nIl sistema di template, out of the box, dovrebbe vietare l’iniezione di codice malevolo – come per esempio un comando che cancella record del database.
\nQuesto è un altro motivo per il quale il sistema di template non permette l’utilizzo di codice Python arbitrario.
\nIl sistema di template dovrebbe riconoscere che autori di template avanzati potrebbero voler estendere la sua tecnologia.
\nQuesta è la filosofia che sta dietro ai filtri ed ai template tag personalizzati.
\nScrivere una vista/view dovrebbe essere semplice come scrivere una funzione Python. Gli sviluppatori non dovrebbero preoccuparsi di istanziare una classe quando potrebbe andare bene una funzione.
\nLe viste/views dovrebbero avere accesso ad un oggetto “request” – un oggetto che fornisce metadati sulla richiesta attuale. L’oggetto dovrebbe essere passato direttamente ad una funzione view, piuttosto che lasciare che la funzione view abbia accesso ad una variabile globale con i dati richiesti. Questo rende semplice, pulito e facile, testare la view passando un oggetto request fittizio.
\nUna view non si dovrebbe curare di quale sistema di template utilizza lo sviluppatore - e nemmeno del fatto che si utilizzi o meno un sistema di template.
\nGET e POST sono distinti; gli sviluppatori dovrebbero espressamente usare l’uno o l’altro. Il framework dovrebbe rendere facile la distinzione di dati GET e POST.
\nGli obbiettivi primari di Django cache framework sono :
\nA cache should be as fast as possible. Hence, all framework code surrounding\nthe cache backend should be kept to the absolute minimum, especially for\nget() operations.
La API della cache dovrebbe offrire una interfaccia consistente per tutti i differenti backend di cache.
\nLa API della cache dovrebbe essere estendibile al livello di applicazione a seconda delle esigenze dello sviluppatore (per esempio, vedi Cache key transformation)
\n