Source

djangofrdoc / misc / design-philosophies.txt

Full commit
==========================
Philosophies de conception
==========================

Ce document explique quelques unes des philosophies fondamentales suivies par
les développeurs de Django lors de la création du framework. Son objectif est
d'expliquer le passé et guider le futur.

Généralités
===========

.. _loose-coupling:

Faible couplage
---------------

.. index:: coupling; loose

`Le couplage faible et la forte cohésion`_ sont un objectif fondamental de la
pile de Django. Les différentes couches du framework ne devraient avoir une
connaissance entre elles qu'en cas de nécessité absolue.

Par exemple, le système de template ne connaît rien des requêtes web, la couche
base de données ne connaît rien au sujet de l'affichage des données, et le
système de vues ne se soucie pas du système de template utilisé par le
développeur.

Bien que Django soit constitué d'une pile complète, les couches de celles-ci
sont indépendantes les unes des autres autant que faire se peut.

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

.. _less-code:

Moins de code
-------------

Les applications Django devraient utiliser le moins de code possible. Django
tire profit au maximum des capacités dynamiques de Python, comme l'introspection.

.. _quick-development:

Développement rapide
--------------------

La raison d'être d'un framework Web au 21ème siècle est d'accélérer les aspects
fastidieux du développement Web. Django devrait permettre un développement Web
d'une rapidité incroyable.

.. _dry:

Don't repeat yourself (DRY)
---------------------------

.. index::
   single: DRY
   single: Don't repeat yourself

Chaque concept distinct et/ou élément de données doit résider en un, et un seul,
endroit. La redondance est mauvaise. La normalisation est bonne.

Le framework devrait être capable de déduire le plus possible à partir du moins
possible, dans des limites raisonnables.

.. seealso::

    La `discussion au sujet de DRY sur le Portland Pattern Repository`__

    __ http://c2.com/cgi/wiki?DontRepeatYourself
    
.. _explicit-is-better-than-implicit:

L'explicite est préférable à l'implicite
----------------------------------------

Cela signifie que Django ne doit pas être trop "magique". C'est un `principe
de base de Python`_. La magie ne doit opérer que s'il y a une bonne raison pour
ça. Il n'est intéressant de l'employer que si cela crée un confort que l'on ne
peut atteindre autrement, et si son implémentation n'apporte pas de confusion
aux développeurs souhaitant apprendre l'usage de cette fonctionnalité.

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

.. _consistency:

Cohérence
---------

Le framework doit être cohérent à tous les niveaux. La cohérence s'applique
à tous les niveaux, du plus bas (le style de codage Python utilisé) au plus haut
(au niveau de l'"expérience" d'utilisation de Django)

Modèles
=======

L'explicite est préférable à l'implicite
----------------------------------------

Les champs ne doivent pas présumer de certains comportements en se basant
uniquement sur le nom du champ. Ceci nécessite trop de connaissance de la part
du système et est sujet aux erreurs. Au lieu de cela, les comportements doivent
se baser sur les arguments mots-clés et, dans certains cas, sur le type du champ.

Inclure toute la logique d'un même domaine
------------------------------------------

Les modèles doivent encapsuler tous les aspects d'un "objet", en suivant le
patron de conception (design pattern) enregistrement actif (`Active record`_) de
Martin Fowler's.

C'est la raison pour laquelle les données représentées par un modèle ainsi que
les informations le concernant (son nom sous une forme lisible, ses options
comme les critères de tri, etc.) sont définies dans la classe du modèle; toutes
les informations nécessaires à la compréhension du modèle doivent être stockées
*dans* le modèle.

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

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

Les objectifs de base de l'interface de programmation (API) de base de données
sont:

Efficacité SQL
--------------

Elle doit exécuter les commandes SQL le moins de fois possibles, et les
commandes doivent être optimisées en interne.

C'est la raison pour laquelle les développeurs doivent appeler ``save()`` de
manière explicite, plutôt que de laisser le framework faire des sauvegardes
de manière silencieuse.

C'est aussi la raison pour laquelle la méthode ``select_related()`` de l'objet
``QuerySet`` existe. Il s'agit d'un booster de performances optionnel pour le
cas fréquent où il s'agit de sélectionner "tous les objets relatifs" à un objet.

Une syntaxe concise et puissante
--------------------------------

L'API de base de données doit permettre la réalisation de commandes riches en
employant une syntaxe la plus minimale possible. Elle ne doit pas se baser sur
l'importation d'autres modules ou d'objets helper.

Les jointures doivent être exécutées automatiquement et de manière invisible
lorsque nécessaire.

Chaque objet doit pouvoir accéder à chacun des objets liés dans tout le système.
Cet accès doit être bidirectionnel.

Pouvoir exécuter du code SQL brut, en cas de besoin
---------------------------------------------------

L'API de base de données doit être un raccourci mais pas l'unique moyen
d'accéder à la base de données. Le framework doit permettre l'écriture de
commandes SQL personnalisées de manière simple -- que ce soit des commandes
complètes, ou des clauses ``WHERE`` en tant que paramètres d'appel à l'API.

Conception d'URL
================

Faible couplage
---------------

Les URLs d'une application Django ne doivent pas être couplées au code Python
sous-jacent. Lier des URLs à des noms de fonctions Python est une très mauvaise
chose.

Le système d'URL de Django doit permettre aux URLs d'une même application d'être
différentes en fonction du contexte. Par exemple, un site pourrait placer les
histoires à l'adresse ``/histoires/``, alors qu'un autre utiliserait
``/nouvelles/``

Flexibilité infinie
-------------------

Les URLs doivent être aussi flexibles que possible. Toute conception d'URL
imaginable doit être possible.

Encourager les bonnes pratiques
-------------------------------

Le framework doit rentre la conception de bonnes URLs aussi facile que les
mauvaises URLs, si ce n'est plus.

Les extensions de fichiers dans les URLs de pages Web doivent être évitées.

Les URLs bardées de virgules méritent une punition sévère.

.. _definitive-urls:

URLs définitives
----------------

.. index:: urls; definitive

Techniquement, ``foo.com/bar`` et ``foo.com/bar/`` sont deux URLs différentes,
et les robots de moteurs de recherche (ainsi que certains outils d'analyse de
trafic Web) les traiteront comme deux pages distinctes. Django doit s'appliquer
à "normaliser" les URLs pour ne pas semer de confusion auprès des robots de
moteurs de recherche.

C'est le raisonnement qui régit le paramètre :setting:`APPEND_SLASH`.

Le système de template
======================

.. _separation-of-logic-and-presentation:

Séparer la logique de la présentation
-------------------------------------

Nous considérons un système de template tel un outil contrôlant la présentation
et la logique liée à la présentation -- et rien d'autre. Le système de template
ne doit pas mettre à disposition des fonctionnalités qui iraient plus loin que
cet objectif de base.

Si nous voulions tout mettre au sein des templates, nous utiliserions PHP. Nous
sommes passés par là, l'avons fait, et avons mûri.

Décourager l'usage de la redondance
-----------------------------------

La majorité des sites Web dynamiques utilisent une sorte de design commun à tout
le site -- un en-tête commun, un pied de page, une barre de navigation, etc.
Le système de template de Django doit faciliter le stockage de ces différents
éléments en un même endroit, en éliminant le code dupliqué.

C'est la philosophie derrière l':ref:`héritage de templates
<template-inheritance>`.

Ne pas être couplé au code HTML
-------------------------------

Un système de template ne doit pas être conçu pour produire uniquement de l'HTML.
Il doit être aussi bon pour générer d'autres formats basés sur le texte, ou
simplement du texte.

XML ne doit pas être utilisé pour les langages de template
----------------------------------------------------------

.. index:: xml; suckiness of

Utiliser un moteur XML pour analyser les templates ouvre le champ à une
multitude d'erreurs humaines lors de l'édition des templates -- et introduit un
coût du traitement des templates d'un niveau inacceptable.

Supposer les compétences du designer
------------------------------------

Le systèmes de template ne doit pas être conçu pour que les templates produits
soient affichées proprement dans les éditeurs WYSIWYG comme Dreamweaver. Ceci
est trop contraignant et ne permettrait pas d'avoir une aussi belle syntaxe.
Django attend des auteurs de templates une certaine capacité à éditer du code
HTML directement.

Gérer les espaces
-----------------

Le système de template ne doit pas faire de choses magiques avec les espaces. Si
un template contient un espace, le système le traitera de la même manière qu'il
traite le texte -- il l'affichera. Chaque espace qui n'est pas présent dans un
template tag devra être affiché.

Ne pas inventer un langage de programmation
-------------------------------------------

Le système de template interdit volontairement:

    * toute assignation à une variable
    * toute logique avancée

L'objectif n'est pas d'inventer un langage de programmation. L'objectif est
uniquement d'offrir suffisamment de fonctionnalités issues des langages de
programmation, comme les embranchements conditionnels et les boucles, pour
permettre des décisions liées à la présentation.

Le système de template de Django conçoit que les templates sont écrits par des
*designers*, et non des *développeurs* la plupart du temps. Il ne doit donc pas
supposer la connaissance de Python.

Sûreté et sécurité
------------------

Le système de templates, tel qu'il est livré, doit interdire l'inclusion de tout
code malicieux -- comme des commandes supprimant des données de la base de
données.

C'est aussi une des raisons pour lesquelles le système de template ne permet pas
l'exécution de code Python.

Extensibilité
-------------

Le système de template doit prendre en compte le fait que les auteurs de
templates voudront peut-être étendre ses possibilités.

C'est l'idée derrière les filtres et template tags personnalisés.

Vues
====

Simplicité
----------

L'écriture d'une vue devrait être aussi simple que l'écriture d'une fonction
Python. Les développeurs ne devraient pas avoir à instancier une classe alors
que la fonction le fait.

Utiliser des objets de requête
------------------------------

Les vues doivent avoir accès à un objet de requête (request) -- un objet
stockant les métadonnées liées à la requête courante. L'objet doit être
directement passé à la vue, plutôt que la vue n'accède aux données de requête
via une variable globale. Cela constitue un moyen léger, clair et facile
de tester les vues en leur passant de "faux" objets de requêtes.

Couplage faible
---------------

Une vue ne doit pas se soucier du système de template utilisé par le développeur
-- ni même de l'utilisation d'un système de template de manière générale.

Différencier GET et POST
------------------------

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