Design di filosofie¶
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.
!!Complessivamente¶
Accoppiamento lasco¶
Uno 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.
For example, the template system knows nothing about web requests, the database layer knows nothing about data display and the view system doesn’t care which template system a programmer uses.
Sebbene Django venga fornito come full stack per convenienza, i pezzi dello stack sono indipendenti uno dall’altro quando possibile.
Meno codice¶
Le applicazioni Django dovrebbero usare meno codice possibile; non dovrebbero esserci boilerplate. Django dovrebbe trarre pieno vantaggio delle capacità dinamiche di Python, come l’introspezione.
Sviluppo rapido¶
The point of a web framework in the 21st century is to make the tedious aspects of web development fast. Django should allow for incredibly quick web development.
Non ti ripetere! (DRY – Don’t repeat yourself)¶
Ogni 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.
Il framework, entro limiti ragionevoli, dovrebbe dedurre il più possibile dal meno possibile.
Vedi anche
Esplicito è meglio di implicito¶
Questo è 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.
Consistenza¶
Il 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.)
Modelli¶
Esplicito è meglio di implicito¶
I 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.
Includere tutte le logiche di dominio rilevanti¶
I modelli dovrebbero incapsulare ogni aspetto di un «oggetto» seguendo il pattern design Active Record definito da Martin Fowler
Per 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.
Database API¶
I principali obiettivi delle API del database sono:
Efficenza SQL¶
Dovrebbe eseguire dichiarazioni SQL il minor numero di volte possibile, ed ottimizzare le dichiarazioni internamente.
Per 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».
Sintassi potente e concisa¶
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.
Le Join dovrebbero essere eseguite automaticamente, in background, quando necessario.
Ogni oggetto dovrebbe essere capace di accedere ad ogni oggetto relazionato, globalmente. Questo tipo di accesso dovrebbe funzionare in entrambi i sensi.
Opzioni da usare nelle query SQL grezze, quando necessario.¶
La 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.
Design dell’URL¶
Accoppiamento lasco¶
Le 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.
In 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/.
Flessibilità infinita¶
Le URL dovrebbero essere il più flessibili possibile. Qualsiasi URL design che possa essere concepito, dovrebbe essere permesso.
Incoraggiare le best practices¶
Il framework dovrebbe rendere semplice (o perfino semplicissima), per uno sviluppatore, la creazione di URL belle piuttosto che brutte.
File extensions in web-page URLs should be avoided.
Le virgolette in stile «vignetta» nelle URL meritano di essere punite severamente.
URL definitive¶
Technically, foo.com/bar and foo.com/bar/ are two different URLs, and
search-engine robots (and some web traffic-analyzing tools) would treat them as
separate pages. Django should make an effort to «normalize» URLs so that
search-engine robots don’t get confused.
Questa è il ragionamento che sta alla base dell’impostazione APPEND_SLASH.
Sistema dei template¶
Dividere la logica dalla presentazione¶
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.
Scoraggiare la ridondanza¶
La 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.
Questa è la filosofia dietro all” ereditarietà dei template.
Essere disaccoppiato dall’HTML¶
Il 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.
XML non dovrebbe essere usato per linguaggi di template¶
L’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.
Ingaggia designer competenti¶
Il 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.
Trattare gli spazi bianchi ovviamente¶
Il 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.
Non inventare un linguaggio di programmazione¶
La 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.
Il sistema di template di Django riconosce che i template sono spesso scritti da designers, non da programmatori e quindi non dovrebbero dare per scontata la conoscenza di Python.
Sicurezza e security¶
Il sistema di template, out of the box, dovrebbe vietare l’iniezione di codice malevolo – come per esempio un comando che cancella record del database.
Questo è un altro motivo per il quale il sistema di template non permette l’utilizzo di codice Python arbitrario.
Estensibilità¶
Il sistema di template dovrebbe riconoscere che autori di template avanzati potrebbero voler estendere la sua tecnologia.
Questa è la filosofia che sta dietro ai filtri ed ai template tag personalizzati.
View¶
Semplicità¶
Scrivere 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.
Usare oggetti per le richieste¶
Le 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.
Accoppiamento lasco¶
Una 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.
Distinguere tra GET e POST¶
GET 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.
Cache Framework¶
Gli obbiettivi primari di Django cache framework sono :
Meno codice¶
Una cache dovrebbe essere il più veloce possibile. Quindi, tutto il codice del framework che sta attorno al backend della cache dovrebbe essere assolutamente minimale, specialmente per quanto riguarda le operazioni get().
Consistenza¶
La API della cache dovrebbe offrire una interfaccia consistente per tutti i differenti backend di cache.
Estensibilità¶
La API della cache dovrebbe essere estendibile al livello di applicazione a seconda delle esigenze dello sviluppatore (per esempio, vedi Cache key transformation)
