Couplage faible

Un des buts fondamentaux de Django est le couplage faible et la forte cohésion. Les différentes couches du framework ne devraient pas "se connaître" les unes les autres à moins que cela soit absolument nécessaire.

Par exemple, le système de gabarit ne connaît rien à propos des requêtes Web, la couche de base de données ne connaît rien à propos de l'affichage des données et le système de vue ne soucie guère du système de gabarit que le programmeur utilise.

Bien que Django s'accompagne d'une pleine pile de fonctionnalités par commodité, les pièces de la pile sont indépendantes des autres autant que possible.

Moins de code

Les applications Django devraient utiliser aussi peu de code que possible; elles devraient rester agiles. Django devrait profiter pleinement des possibilités dynamiques de Python, tel que l'introspection.

Développement rapide

L'intérêt d'un framework du 21ème siècle est de rendre rapide les tâches fastidieuses du développement Web. Django devrait permettre un développement Web incroyablement rapide.

Ne vous répétez pas (DRY)

Chaque concept/portion de données distincts devrait résider en un, et un seul, endroit. La redondance est mal. La normalisation est bien.

Le framework, dans la limite du raisonnable, devrait déduire autant que possible à partir du minimum possible.

Explicite est meilleur qu'implicite

Ceci, un principe au coeur de Python, veut dire que Django ne devraient pas faire de choses trop "magiques". La magie ne devrait pas apparaître tant qu'il n'y a pas de raison valable pour cela. La magie vaut la peine d'être employée seulement si elle amène un grand confort, inaccessible d'une autre manière, et si elle n'est pas implémentée de manière à rendre confus les développeurs qui essayent d'apprendre à utiliser la fonctionnalité.

Cohérence

Le framework devrait être cohérent à tout niveau. La cohérence s'applique à tout élément depuis le bas niveau (les règles de codage Python utilisées) jusqu'au haut niveau ("l'expérience" d'utilisation de Django).

Explicite est meilleur qu'implicite

Les champs ne devraient pas adopter certains comportements basés uniquement sur le nom du champ. Ceci nécessite trop de connaissance du système et est source d'erreurs. Au lieu de cela, les comportements devraient être basés sur des arguments nommés et, dans certains cas, sur le type de champ.

Inclure toute la logique appropriée

Les modèles devraient encapsuler chaque aspect d'un "objet", selon le patron de conception Active Record de Martin Fowler.

C'est pour cette raison que les options d'administration spécifiques au modèle sont incluses dans le modèle lui même; les données relatives au modèle devraient être stockées dans le modèle.

Efficacité SQL

Elle devrait exécuter des requêtes SQL le moins souvent possible, et elle devrait optimiser les requêtes en interne.

C'est pour cette raison que les développeurs doivent appeler explicitement la méthode save(), au lieu que ses soit le framework qui gère la sauvegarde de manière silencieuse en coulisse.

C'est aussi pour cela que les méthodes select_related() QuerySet existent. C'est une amélioration optionnelle des performances pour la tâche courante de sélection de "chaque modèle associé".

Syntaxe succinte mais puissante

L'API de base de données devrait autoriser de riches et consistantes requêtes dans un minimum de syntaxe possible. Elle ne devrait pas s'appuyer sur l'import d'autres modules ou d'objets d'aide à la mise en forme.

Les jointures devraient être réalisées automatiquement, en coulisse, lorsque nécessaire.

Chaque objet devrait pouvoir accéder à chaque objet associé, dans tout le système. Cet accès devrait fonctionner dans les deux sens.

Une option pour exécuter une requête SQL facilement, lorsque nécessaire

L'API de base de données devrait réaliser qu'elle est un raccourci mais pas nécessairement un tout-en-un. Le framework devrait rendre facile l'écriture de SQL sur mesure -- des requêtes complètes, ou juste des clauses WHERE personnalisées en tant que paramètres pour les appels à l'API.

Couplage faible

Les URLs dans une application Django ne devraient pas être associées à un code Python sous-jacent. L'association d'URLs à des fonctions Python nommées est une Mauvaise et Vilaine Chose.

A travers ces lignes, le système d'URL Django devrait permettre aux URLs provenant de la même application d'être différentes dans des contextes différents. Par exemple, un site peut mettre les articles à /articles/, alors qu'un autre peut utiliser /nouvelles/.

Flexibilité infinie

Les URLs devraient aussi flexibles que possible. Toute conception d'URL imaginable devrait être permise.

Encourager les bonnes pratiques

Le framework devrait faire en sorte qu'il soit facile (ou plus facile) pour un développeur de concevoir de jolies URLs que des moches.

Les extensions de fichier dans les URLs des pages Web devraient être évités.

L'utilisation abusive de virgules dans les URLs est passible d'une sévère punition.

URLs permanentes

Techniquement, foo.com/bar et foo.com/bar/ sont deux URLs différentes, et les robots des moteurs de recherche (et quelques outils d'analyse du traffic) pourraient les traiter de manière séparées. Django devrait faire un effort pour "normaliser" les URLs afin ne pas permettre la confusion aux robots des moteurs de recherche.

Il s'agit du raisonnement derrière le paramètre de configuration APPEND_SLASH.

Séparer la logique de la présentation

Nous voyons un système de gabarit comme un outil contrôlant la présentation et la logique relative à la présentation -- et c'est tout. Le système de gabarit ne devrait pas supporter de fonctionnalités qui vont au delà de ces principes de base.

Si nous voulions tout mettre dans les gabarits, nous aurions utiliser PHP. Sachant cela, mettez vous au parfum.

Décourager la redondance

La majorité des sites Web dynamiques utilisent des parties entières et communes du design du site -- un entête, pied de page, barre de navigation, etc. communs. Le système de gabarit de Django devrait rendre facile le stockage de tels éléments en un seul endroit, supprimant les parties de code dupliquées.

C'est le concept derrière l'héritage de gabarit.

Etre dissocié du HTML

Le système de gabarit ne devraient pas être conçu pour seulement produire du HTML. Il devrait être également bon à générer d'autres formats basés sur du texte, ou juste du texte.

Le XML ne devrait pas être utiliser pour les langages de gabarit

L'utilisation d'un moteur de XML pour analyser les gabarits introduit tout un monde nouveau pour les erreurs humaines dans l'édition de gabarit -- et implique un niveau inacceptable de surcharge dans le traitement du gabarit.

Prendre en compte la compétence du designer

Le système de gabarit ne devrait pas être conçu de telle manière que les gabarits soient nécessairement bien affichés dans les éditeurs WYSIWYG tel que Dreamweaver. C'est une limitation trop importante et ne permettrait pas à la syntaxe d'être aussi aisée qu'elle l'est. Django pré-suppose que les auteurs de gabarit sont à l'aise avec l'édition HTML.

Traiter les espaces blancs de manière évidente

Le système de gabarit ne devrait pas faire de choses magiques avec les espaces blancs. Si un gabarit inclut des blancs, le système devrait traiter les blancs comme il le fait avec le texte -- juste l'afficher. Tout blanc qui ne fait pas partie d'un marqueur de gabarit devrait être affiché.

Ne pas inventer un langage de programmation

Intentionnellement, le système de gabarit ne permet pas ce qui suit :

• L'assignement des variables
• La logique avancée

Le but n'est pas d'inventer un langage de programmation. Le but est juste d'offrir une bonne fonctionnalité programmationnelle, tel que les conditions et les boucles, ce qui est essentiel pour produire des présentations dirigées par les décisions.

Le système de gabarit de Django postule que les gabarits sont plus souvent écrits par les designers, et non les programmeurs, et de ce fait ne nécessite pas de connaissance en Python.

Sûreté et sécurité

Le système de gabarit, nativement, devrait interdire l'inclusion de code malicieux -- tel que des commandes supprimant les données en base.

C'est une autre raison pour laquelle le système de gabarit ne permet pas l'ajout arbitraire de code Python.

Extensibilité

Le système de gabarit devrait prendre en compte le fait que les auteurs de gabarits de niveau avancé peuvent vouloir étendre cette technologie.

C'est le concept derrière les marqueurs et les filtres de gabarit personnalisés.

Simplicité

L'écriture d'une vue devrait être aussi simple que d'écrire une fonction Python. Les développeurs ne devraient pas avoir besoin d'instancier une classe quand une fonction suffit.

Utiliser les objets de requête

Les vues devrait avoir accès à un objet de requête -- un objet qui stocke les métadonnées relatives à la requête courante. L'objet devrait être passé directement à une fonction de vue, au lieu que ce soit la fonction de vue qui doivent accéder aux données de la requête à travers une variable globale. Ceci permet de tester de manière légère, propre et facile les vues en leur passant des "faux" objets de requête.

Couplage faible

Une vue ne devrait pas se soucier du système de gabarit que le développeur utilise -- ou même si un système de gabarit est utilisé ou non.

Différencier entre GET et POST

GET et POST sont distincts; les développeurs devraient explicitement utiliser l'un ou l'autre. Le framework devrait facilement distinguer les données GET et POST.