FAQ : généralités

Pourquoi ce projet existe-t-il ?

Django a grandi à partir de besoins très concrets : World Online, un éditeur de journal Web, a la charge de construire des applications Web avec des impératifs temporels hérités du journalisme. Dans le rythme soutenu de la salle de presse, World Online ne dispose généralement que de quelques heures pour délivrer une application Web de sa phase d’ébauche jusqu’à sa mise à disposition publique.

Dans le même temps, les développeurs de World Online ont toujours été perfectionnistes quant au suivi des bonnes pratiques de développement Web.

À l’automne 2003, les développeurs de World Online (Adrian Holovaty et Simon Willison) ont abandonné PHP au profit de Python pour développer leurs sites Web. Tout en développant intensément des sites interactifs riches tels que Lawrence.com, ils commencèrent à composer un environnement Web générique leur permettant de construire des applications Web de plus rapidement. Il l’améliorèrent constamment pendant deux ans.

En été 2005, World Online accepta de libérer le logiciel ainsi réalisé, Django. Django n’aurait pas pu exister sans un ensemble de projets libres, Apache, Python et PostgreSQL pour n’en nommer que quelques-uns. Nous sommes ravis de pouvoir reverser quelque chose à la communauté du libre.

Que signifie « Django », et comment le prononcer ?

Django est nommé en hommage à Django Reinhardt, un guitariste de jazz d’origine gitane des années 1930 jusqu’au début des années 1950. À ce jour, il est considéré comme l’un des meilleurs guitaristes de tous les temps.

Écoutez sa musique. Vous apprécierez.

Django se prononce JANG-oh. Cela rime avec FANG-oh. Le « D » est silencieux.

Nous avons également enregistré une séquence audio de la prononciation.

Est-ce que Django est stable ?

Oui, c’est stable. Des entreprises comme Disqus, Instagram, Pinterest et Mozilla utilisent Django depuis plusieurs années. Les sites construits avec Django ont essuyé des pics de trafic allant jusqu’à 50 milles hits par seconde.

Est-ce que Django a la capacité de monter en charge ?

Oui. Comparé au temps de développement, le matériel est bon marché, donc Django est conçu pour profiter au maximum du matériel que vous lui mettez à disposition.

Django utilise une architecture « shared-nothing » (« rien de partagé »), ce qui signifie que vous pouvez ajouter du matériel à n’importe quel niveau – serveurs de bases de données, serveurs de cache ou serveurs Web/applicatifs.

Django sépare proprement les composants tels que la couche de base de données et la couche applicative. Et il est livré avec une infrastructure de cache simple mais puissante.

Qui est derrière cela ?

Django fut initialement développé à World Online, le département Web d’un journal à Lawrence, Kansas, USA. Django est maintenant géré par une équipe internationale de volontaires.

Quels sites utilisent Django ?

DjangoSites.org propose une liste constamment enrichie de sites bâtis avec Django.

Django apparaît comme un système MVC, mais vous appelez le contrôleur la « vue », et la vue le « gabarit » (template). Pourquoi n’utilisez-vous pas les noms standards ?

Et bien, les noms standards sont discutables.

Dans notre interprétation du MVC, la « vue » décrit les données qui sont présentées à l’utilisateur. Ce n’est pas nécessairement comment les données se présentent, mais quelles données sont présentées. La vue décrit quelles données vous voyez, pas comment vous les voyez. C’est une distinction subtile.

Donc, dans notre cas, une « vue » est la fonction de rappel Python pour une URL donnée, car la fonction de rappel détermine quelles données sont présentées.

De plus, il est sensé de séparer le contenu de la présentation – c’est là que les gabarits entrent en jeu. Dans Django, une « vue » décrit quelles données sont présentées, mais une vue délègue normalement la suite à un gabarit, qui décrit comment les données sont présentées.

Où se place alors le « contrôleur » ? Dans le cas de Django, il s’agit probablement du système en lui-même : la machinerie qui envoie une requête à la vue appropriée, selon la configuration d’URL de Django.

Si vous êtes friand d’acronymes, vous pourriez dire que Django est un système « MTV » – à savoir « modèle », « template » (gabarit) et « vue ». Cette décomposition fait davantage sens.

Au final bien sûr, il s’agit surtout de faire le boulot. Et peu importe comment les choses sont appelées, Django fait son travail d’une manière qui nous semble la plus logique.

Le <Système X> contient la <fonctionnalité Y> – pourquoi Django ne le fait-il pas ?

Nous sommes bien conscients qu’il existe d’autres applicatifs Web géniaux, et nous ne sommes pas opposés à l’idée d’emprunter des idées lorsque c’est approprié. Cependant, Django fut développé précisément car nous étions mécontents du status quo, soyez donc conscient que « parce que le <Système X> le fait » n’est pas une raison suffisante pour ajouter une fonctionnalité donnée à Django.

Pourquoi avoir écrit Django de zéro, au lieu d’utiliser d’autres bibliothèques Python ?

Lorsque Django a été écrit, Adrian et Simon ont passé un bout de temps à explorer les divers applicatifs Web Python disponibles.

À notre avis, aucun d’entre eux ne correspondait à ce qui était attendu.

Nous sommes pointilleux. Vous pourriez même nous traiter de perfectionnistes (avec des délais à tenir).

Au fil du temps, nous sommes tombés sur des bibliothèques libres qui faisaient des choses que nous avions déjà implémentées. Cela était rassurant de voir d’autre personnes résoudre des problèmes similaires avec des méthodes similaires, mais il était trop tard pour intégrer du code extérieur : nous avions déjà écrit, testé et implémenté nos propres morceaux du système dans plusieurs environnements de production – et notre propre code satisfaisait grandement nos besoins.

Dans la plupart des cas cependant, nous avons constaté que les applicatifs/outils existants présentaient inévitablement certains défauts fondamentaux et critiques qui nous laissaient sur notre faim. Aucun outil ne correspondait à notre philosophie à 100 %.

Comme dit précédemment : nous sommes pointilleux.

Nous avons détaillé notre philosophie sur la page de la philosophie de conception.

Django est-il un système de gestion de contenus (CMS) ?

Non, Django n’est pas en soi un CMS, ou n’importe quelle autre sorte de « produit clé-en-main ». C’est un applicatif Web ; un outil de programmation qui vous permet de construire des sites Web.

Par exemple, cela n’a pas beaucoup de sens de comparer Django à quelque chose comme Drupal, parce que Django est utilisé pour créer des systèmes comme Drupal.

Évidemment, l’administration automatique de Django est fantastique et fait gagner du temps – mais le site d’administration n’est qu’un module du système Django. De plus, bien que Django offre des commodités pour construire des applications de type CMS, ça ne signifie pas qu’il n’est pas approprié à la construction d’applications autres que des CMS (si cette distinction à un sens !).

Comment puis-je télécharger la documentation Django pour la lire hors ligne ?

La documentation de Django est disponible dans le répertoire docs de chaque version empaquetée de Django. Cette documentation est écrite au format reST (reStructuredText), et chaque fichier texte correspond à une page Web sur le site officiel de Django.

Grâce au fait que la documentation est versionnée, vous pouvez naviguer à travers les modifications de la documentation tout comme vous le feriez avec le code.

Techniquement, la documentation du site de Django est générée à partir de la toute dernière version en cours de développement de ses documents reST, il se peut donc qu’elle contienne plus d’informations que la documentation livrée avec la dernière version de Django.

Comment dois-je citer Django ?

Il est difficile de donner un format officiel de citation, pour deux raisons : les formats de citation peuvent varier énormément entre les publications, et les normes de citation pour les logiciels sont encore un sujet de débat.

Par exemple, le style APA imposerait quelque chose comme :

Django (Version 1.5) [Computer Software]. (2013). Retrieved from https://djangoproject.com.

Cependant, le seul vrai guide est celui que votre éditeur acceptera, donc munissez-vous d’une copie de ses règles et comblez les lacunes de votre mieux.

Si votre guide stylistique de référence nécessite un nom d’éditeur, utilisez « Django Software Foundation ».

Si vous avez besoin d’une adresse d’édition, utilisez « Lawrence, Kansas ».

Si vous avez besoin d’une adresse Web, utilisez https://djangoproject.com.

Si vous avez besoin d’un nom, utilisez simplement « Django », sans le slogan.

Si vous avez besoin d’une date de publication, utilisez l’année de publication de la version que vous référencez (par ex. 2013 pour la version 1.5).

Back to Top