Pourquoi j'ai choisi Django.

Dans Technique par Florian Strzelecki - 21:32 - 07.11.2009

Tags : Django, Python, Framework, Web, J'aime

Quand je dis "choisir", je parle du framework avec lequel j'aime le plus travailler, et celui avec lequel j'ai envie, d'un point de vue professionnel, de travailler.

En dehors de la part d'amour irraisonnée pour une boîte à outil développée en python (je suis un grand romantique par moment), je considère, pour mon choix, plusieurs arguments basés tant sur de la théorie et que de la pratique.

Après tout, il s'agit surtout de mon opinion, et je ne suis pas toujours objectif, il serait idiot de prétendre le contraire - ce qui constitue encore une fois un jugement de valeur... c'est terrible n'est-ce pas ?

Je souhaite partager avec vous mes impressions sur ce framework d'excellence, dans une vague présentation de l'ensemble, et un tour des fonctionnalités qui me rendent fou de joie (au moins tout ça, oui) à chaque fois que j'ai l'occasion de les utiliser.

Je ne vais cependant pas rentrer dans les détails pour chaque point, car la documentation officielle devrait vite vous convaincre de ce que je mets en lumière.

D'ailleurs, vous vous rendrez vite compte que la documentation de Django est tout bonnement excellente !

Présentation rapide

Le Framework (ou cadriciel)

Django, the Web framework for perfectionists with deadlines.

C'est ce qu'indique très sobrement le site officiel du projet Django. Et j'ai pu tester ce slogan qui s'est révélé tout à fait exact durant mes différentes expériences, personnelles ou professionnelles.

J'ai notamment pu constater à quel point mon temps était plus souvent dédié aux problèmes métiers qu'aux problèmes liés au framework, à sa configuration et à son installation. Ce qui est déjà un bon point, quand on sait le temps que j'ai perdu pour mettre en place un Zend Framework... (ceux qui me suivent sur Twitter voient de quoi je parle).

Django est un framework développé en Python (version 2.x), orienté vers le Web.

Je dis "orienté", car je me suis rendu compte que je pouvais en utiliser certaine partie pour totalement autre chose (comme un outil d'import / export vers une base de données).

Il dispose de fonctionnalités aussi puissantes que simples et pratiques à utiliser.

La communauté

Dans un récent billet de Jacob Kaplan-Moss intitulé The Django community in 2009, il indique une augmentation de la taille de la communauté :

Based on these numbers (1 million to 4.7 million hits; 500 voluntarily registered sites to about 2,700), we could guess at roughly a 5-fold increase in the size of the Django user community since March 2007. Not very scientific, to be sure. But it's clear that the user community is much larger now.

Le fait est que, depuis que je suis inscrit à la mailing-list des utilisateurs de Django, j'ai bien du mal à lire tous les échanges : plus d'une centaine d'emails envoyés chaque jour.

J'ai eu, plusieurs fois, l'occasion de répondre à des utilisateurs (principalement en anglais évidement), et de lire les pères de Django répondre et participer. Et ce après quelques jours d'utilisation de Django d'ailleurs, car la prise en main est simple elle aussi.

C'est assez plaisant, d'ailleurs, de constater que cette communauté qui grossie sans cesse est si vivante, si active, et où il est tout à fait possible d'entamer le dialogue avec les créateurs et mainteneurs du projet Django.

Pour la partie française maintenant, je ne peux que vous conseiller le site django-fr, porté en grande partie par David Larlet.

Je ne peux que vous conseiller aussi de passer sur le channel IRC de freenode : #django-fr. Pour le reste, je pourrais en faire un article entier, ce qui sera peut-être le cas plus tard.

A noter que je tente, à l'occasion, de participer à la traduction de la documentation anglaise vers le français. Je n'ai cependant pas un excellent niveau d'anglais, et je suis souvent fâché avec l'orthographe. Mais c'est un travail intéressant, long, mais formateur.

Les modèles et les types de champs

Voici le premier point qui me tient à coeur avec Django : son système de modèle, permettant d'abstraire totalement toute la partie SGBD, et de retirer toutes les requêtes SQL du code métier.

Le principe est le suivant : si on considère une classe Livre, cette classe devra étendre la classe Models de Django. Pour cette classe, on va définir des attributs de classes en utilisant des types de champs.

Les types de champs sont nombreux, dont CharField, TextField, IntegerField, ForeignKey, ImageField, DatetimeField (la liste complète des types de champs), et il est tout à fait possible de créer ses propres types de champs.

Car Django est Python, et les types de champs étant des classes Python, il suffit d'étendre la bonne classe, de surcharger une ou deux méthodes, et le tour est vite joué - et de manière très propre en prime (le côté perfectionniste, vous voyez le genre).

Ensuite, il existe toute une API pour créer, enregistrer, modifier, supprimer, une instance de ce modèle, dans la base de données. Et ce, bien évidement, sans une seule ligne de SQL.

Je ne parle pas ici de faire que des petites requêtes, mais bel et bien des requêtes complexes (avec des liens vers d'autres tables), avec beaucoup de paramètre à prendre en compte : condition OR, relation d'objet, ordonnancement, limite, groupement, jointure, etc...

De manière totalement empirique, je dirais que la plupart des cas, même complexes, peuvent être résolus avec l'API fourni. Dans les quelques cas restant, je doute que l'on puisse faire autrement qu'y aller à la main.

On peut d'ailleurs considérer que les performances sont une complexité supplémentaires, mais lorsqu'il s'agit de ça, alors je considère comme acquis que le spécifique sera toujours plus puissant que le générique.

Pour la partie requête (QuerySet) vous pouvez en lire les détails dans la documentation.

Découper son projet en applications.

Lorsque l'on souhaite développer une application web avec Django, on commence par démarrer un projet.

Ensuite, dans ce projet, pour lequel on modifie les settings (base de données, chemin vers les templates, etc...) on créé les applications spécifiques dont on va avoir besoin pour le projet.

Enfin, pour toutes les autres applications, qui viennent d'autres projets, voir ne sont dans aucun projet, il suffit de les ajouter à la variable de configuration "INSTALLED_APPS".

Simple et efficace !

Pour plus d'information, n'hésitez pas à suivre le très bon tutoriel d'introduction à Django.

La réutilisation des applications n'est pas un mythe !

Un mot clé parfait pour les réunions inutiles qui font saliver des personnes trop peu compétente, c'est la "réutilisabilité". En dehors du fait que ce n'est pas un terme très français (mais j'ai peut-être un mauvais dictionnaire) c'est aussi un terme qui n'a pas voulu dire grand chose dans mon quotidien de développeur web.

Jusqu'à l'arrivé de Django dans ma vie.

Je pourrais romancer cette découverte de mille façon, mais la méthode la plus simple pour vous convaincre c'est de vous expliquer quelles sont les applications que ce blog utilise :

• l'application "syndication" de Django
• l'application "commentaire" de Django
• l'application "link" du site principal (http://exirel.me)
• l'application "mind" de mon site de réflexion (http://reflexion.exirel.me)
• les applications "blog" et "tag" développée pour moi-même et mes besoins spécifiques

Ainsi, j'ai utilisé des applications faites par quelqu'un d'autre, et que j'ai même déjà utilisées sur d'autres projets, pour ce blog. Je pense d'ailleurs ajouter prochainement d'autres applications externes, comme haystack.

Ce découpage, et cette intelligence dans la construction de chaque brique, fait que ce concept devient concret. Cela ne se fait pas sans quelques petits efforts, mais c'est à la porté de tout bon développeur.

Les formulaires et l'interface d'administration

Jacob Kaplan-Moss est un homme plein d'humour, et il a écrit ceci :

Web development sucks.

Introduction de son billet "Snakes on the Web", et je vous en conseille très vivement la lecture.

Deux choses formidables avec Django, basé sur un principe récurrent : tout ce qui est pénible à faire, et à refaire, Django s'en occupe pour vous. C'est exactement le cas avec les formulaires, et avec l'interface d'administration.

Formulaire : ce dont j'ai toujours rêvé

Et il faut bien le dire : développer un formulaire, écrire la validation du formulaire, gérer les erreurs, les types de champs, et tout le reste... c'est pénible et totalement ingrat.

Et le pire, c'est que l'on doit sans cesse en faire, pour les sites webs, que ce soit pour l'inscription, le backoffice, et tous les autres formulaires de jeux-concours, de contacts, ou de "regardez comme elle est trop bien mon application web".

Heureusement, la partie formulaire de Django est très pratique, et permet de mettre de côté toute la partie pénible des formulaires.

Comme pour les modèles, il suffit de définir une classe, d'en définir les attributs avec des types de champs de formulaire, et d'utiliser les divines méthodes "is_valid()" et "as_p()", respectivement pour valider le formulaire, et pour afficher le formulaire.

Comme pour tout le reste, on peut soit utiliser la partie bas-niveau comme haut-niveau, en fonction de son besoin, plus ou moins spécifique.

Dans le détail, vous pouvez, là encore, lire la documentation fournie par Django.

Interface d'administration : quelques lignes de configuration seulement

Ce n'est pas tout à fait exact : il faut parfois plus de quelques lignes de configuration (en réalité, il s'agit de définir des classes d'Admin), mais c'est très vrai dans une très large partie des cas que j'ai eu à rencontrer - et c'est toujours vrai dans les cas répétitifs qu'il faut refaire 50 fois par ans.

Dans les "contrib" de Django se trouve l'application "admin", qu'il suffit d'ajouter à la liste des applications de votre projet.

En indiquant par une ligne quels sont les modèles qui seront gérés par l'application, vous laissez Django vous construire toute une interface d'administration, au design sobre et efficace. Pour chaque modèle choisi, on va pouvoir en ajouter, en modifier, en supprimer...

Et bien évidement, cette interface repose en grande partie sur les formulaires de Django.

Deux cas se présentent alors à vous : soit vous l'utiliser telle qu'elle existe, soit vous avez besoin d'en étendre les fonctionnaliter, d'en changer l'interface, le design, ou autre.

Dans le premier cas, une simple lecture de la documentation vous aidera. Cependant, voici ce que vous pourrez facilement faire :

• choisir la liste des champs à afficher dans la liste des objets créés (titre ? url ? l'id ? autre ?)
• choisir les filtres que vous souhaitez pouvoir appliquer à cette liste
• choisir les champs sur lequel on peut faire une recherche
• les groupes de champs à afficher ensemble dans le formulaire d'ajout / d'édition
• la présentation de tel ou tel champ (liste, bouton radio, autre...)

Dans le second cas, je ne peux que vous conseiller de lire le livre "Pro Django", et de regarder les slides de la présentation Customizing the django admin.

Pour conclure : qualité et simplicité

C'est ce qui ressort le plus de mes expériences avec Django : un framework simple à utiliser, et qui ne néglige pas la qualité.

Qualité lorsqu'il s'agit d'écrire une application métier spécifique à ses besoins. Qualité lorsqu'il s'agit d'étendre des fonctionnalités déjà existantes. Qualité lorsqu'il s'agit de fournir des moyens de s'abstraire des tâches répétitives et roboratives.

Qualité, enfin, lorsqu'il s'agit de la documentation : claire, détaillée, et fournie. Je ne connais pas beaucoup de projets open-source qui puissent se targuer d'avoir une documentation aussi bien réalisée.

Et ce qui n'est pas dans la documentation, on peut très facilement aller le découvrir soit-même dans le code : vous vous souvenez, Django, c'est du Python.

Et il respecte la philosophie de Python, c'est aussi pour ça que je l'aime.

RSS des commentaires - Commenter - Haut de page