root/docs/trunk/design_philosophies.txt

==========================
Philosophies de conception
==========================

Ce document décrit les concepts fondamentaux que les développeurs de Django ont
suivis pour la création de ce framework. Son but est d'expliquer le passé et de
guider le futur.

Vue d'ensemble
==============

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.

.. _`le couplage faible et la forte cohésion`: http://c2.com/cgi/wiki?CouplingAndCohesion

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é.

.. _`principe au coeur de Python`: http://www.python.org/dev/peps/pep-0020/

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).

ModÚles
=======

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.

.. _`Active Record`: http://www.martinfowler.com/eaaCatalog/activeRecord.html

API de la base de données
=========================

Les principes clés de l'API de la base de données sont :

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.

Conception des URLs
===================

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``.

SystÚme de gabarit
==================

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`_.

.. _l'héritage de gabarit: ../templates/#template-inheritance

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.

Vues
====

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.