Commits

Amine Chraibi  committed 3f423d6

misc/design-philosophies.txt : #1 traduction terminée

  • Participants
  • Parent commits 9b119ec

Comments (0)

Files changed (1)

File misc/design-philosophies.txt

+==========================
+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 implementation 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
+traffic 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 controllant 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 éléminant 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 templates 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 suffisament 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 écrites 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 sytè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 objects 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'utilsation d'un système de template de manière générale.
+
+Différencier GET et POST
+------------------------
+
+GET et POST sont distincts; les developpeurs doivent explicitement utiliser l'un
+ou l'autre. Le framework doit permettre de distinguer facilement les données GET
+et POST.