Attendue depuis des mois, la version 1.0 de Django est sortie en septembre dernier. Elle est le fruit d'une courageuse refactorisation de la précédente version stable (comprendre : reconnaître et corriger les erreurs de jeunesse), qui fait plus que jamais de Django un produit open-source de qualité, fiable et étonnement pérenne.

Django est un framework de développement Web dit « agile », dans ce sens qu'il permet de développer des sites d'une part très rapidement, et d'autre part en suivant certains convention qui rendent le résultat final très flexible.

Django encourage les bonnes pratiques

Si l'on en croit le slogan, Django a été conçu « pour les perfectionnistes sous pression » (for perfectionists with deadlines). Ses auteurs font en effet le pari que pour tenir des délais en développement Web, il vaut mieux prendre la peine de faire les choses proprement, produire du code réutilisable, flexible, concis et lisible, que de foncer tête baissée. Même si cela, au fond, dépend du développeur, Django dispose de plusieurs garde-fous qui l'amènent à réfléchir à long terme.

L'une des particularités du développement Web est que les détails de présentation (graphisme, formulations, etc.) ont beaucoup d'importance et sont souvent affinés tout au long d'un projet. S'il n'est pas possible de revenir facilement en arrière, il faudra renoncer à certaines améliorations ou alors perdre beaucoup de temps.

Éviter les répétitions

Les feuilles de styles CSS est l'une des technologies qui permet d'échapper à cette alternative. Les styles permettent par exemple de centraliser le code couleur des titres de telle partie d'un site, de façon à pouvoir le modifier facilement à un seul endroit. Ce standard a commencé à être introduit dans les années 90 avec Internet Explorer 3, mais n'est utilisé intelligemment que depuis quelques années.

Il y a de nombreux autres réglages que l'on aimerait pouvoir centraliser aussi simplement. Par exemple, si un champs de la base de donnée change de nom (nom d'utilisateur devient, mettons, pseudonyme à la demande du client), on aimerait pouvoir répercuter la modification sans avoir à vérifier toutes les pages.

Django encourage à « ne pas se répêter » (principe DRY - Don't Repeat Yourself). Si l'on reprend l'exemple de la base de données, cela signifie que le nom d'un champ, même s'il apparaît sur toutes les pages, ne devrait être saisi, en tout et pour tout, qu'à un seul endroit dans le projet - de façon à pouvoir le changer globalement et en une seule modification si besoin. Pas toujours facile à prévoir : selon l'environnement, cela peut peut même représenter un surcroit de travail rédhibitoire. Avec Django, cela se fait naturellement et inévitablement lors de la définition du modèle de données, sans effort particulier.

Ce n'est qu'un exemple parmi d'autres. Django propose un certain nombre de mécanisme simples et bien huilé pour : centraliser les paramètres (settings), définir des filtres de données(template tags, méthodes de modèles), automatiser la gestion des formulaires (newforms, admin) ou créer des composants réutilisables (applications, héritage des templates) - pour ne citer que ceux-là.

Modèle, Vue, Controlleur

Un autre grand principe omniprésent dans Django est la séparation des données, logique et présentation. L'architecture de Django est librement inspirée du célèbre « Modèle-Vue-Controlleur » et peut se résumer ainsi : le développeur ne devrait pas avoir à se soucier ni de la représentation, ni de l'origine des données, de même que le graphiste n'a pas à se soucier de ce qui se passe sous le capot.

Cette séparation a de multiples avantages pratiques : en réduisant les interdépendances des tâches, en permettant aux intervenants de se concentrer sur un seul aspect du projet à la fois ou en facilitant le recyclage des briques créées.

Elle est assurée en Django selon les concepts principaux de modèle, vue et template.

Concepts clés

Un projet django s'articule autour de une ou plusieurs applications, comportant en général chacune un modèle de données, des templates et des vues. Concrètement, ce ne sont que de bêtes fichiers sources et répertoires faciles à manipuler.

Ces applications sont ensuites « branchées » sur le site, selon des motifs d'urls prédéfinis. Par exemple :

# extrait de urls.py, qui connecte l'application Journal au présent 
# site web
urlpatterns = patterns('',
# (...)
  (r'^journal/', include('Journal.urls')),

Les vues réalises des opérations pour extraires les données selon le modèle, et les présentent à l'utilisateur en HTML selon les templates correspondantes.

Le modèle de données

La structure de la base de données se présentent sous la forme de classes python, correspondant à des tables, dont les attributs représentent les champs et leurs types. Tout comme une classe standard, il est possible d'y attacher des méthodes pour effectuer toutes sortes de manipulations sur les données, ou encore d'utiliser les mécanismes d'héritage.

Voici par exemple la définition des catégories de notre Journal, dans le fichier Journal/models.py :

class Category(models.Model):
   name = models.CharField('name', max_length=30)
   slug = models.SlugField('identifier')
   description = models.TextField()

   class Meta:
       verbose_name_plural = 'categories'

   # pour créer un lien vers la catégorie
   def get_absolute_url(self):
       return "/journal/%s/" % (self.slug)

   # représentation par défaut de l'objet
   def __unicode__(self):
       return self.name

Une fois les modèles créés, Django donne automatiquement accès à une couche d'abstraction permettant de créer, retrouver, modifier et supprimer des objets de façon simplifiée. Pour les opérations plus complexes, il existe divers moyen d'attaquer la base de données directement, au moyen de requêtes SQL par exemple.

Django est également capable d'initialiser la base de données pour vous, en suivant les modèles. Les moteurs les plus courantes sont supportées nativement (SQLite, MySQL, Postgres et Oracle).

Les vues (views)

Le système de vue fait la jointure entre les données et le moteur de templates. Généralement une vue effectue une requête vers la base de données en fonction de paramètres (soit prédéfinis, soit passés par l'utilisateurs), charge une template et lui passe le contenu extrait de la base de données.

Voici par exemple la vue qui affiche une catégorie de notre Journal (définie dans Journal/views.py) :

def index(request, category=None):
   c = RequestContext(request, processors=[journal_categories,
                                           _cms_context_processor])
   posts = Post.objects.all_published() # méthode personalisée
   # catégorie passée (ou pas) dans l'url
   # par exemple /journal/actualites/
   if category: 
       category = get_object_or_404(Category, slug=category)

       # on restreint le champs des articles le cas échéant
       posts = posts.filter(categories=category)
       c['category'] = category
   # le contexte contenant la catégorie et
   # les articles est passé à la template :
   c['posts'] = posts[:5]
   return render_to_response("Journal/index.html", c)

Moteur de templates

Le code ci-dessus charge la template index du journal. Celle-ci contient toutes les informations relatives à la façon de présenter les données, généralement exprimées en code HTML assorti de feuilles de styles.

Voici un autre exemple (extrait de templates/Journal/index.html), utilisant des données communes à plusieurs vues :

{% block column_left %}
(...)
<h3>Rubriques</h3>
<ul>

{% for category in journal_categories %}
  <li><a href="{{ category.get_absolute_url }}">{{ category }}</a>
    ({{ category.posts.all_published.count }} 
     article{{ category.posts.all_published.count|pluralize }})</li>
{% endfor %}

<li><a href="/journal/">Tous les articles</a></li>
</ul>

{% endblock %}

Ici les catégories sont présentées dans la colone de gauche sous forme de liste, à l'aide d'une boucle qui répète le motif pour chacune d'elles. Entre {{ }} sont les données extraites de la base, dans un format propre au moteur de tempates.

On notera avec quelle facilité on peut récupérer le nombre d'article publiés par catégorie, et mettre le mot « article » au singulier ou au pluriel selon qu'il y en a un ou plusieurs.

Une interface admin automatique

Les principales opérations à faire sur la base de données peuvent être réalisées rapidement et de façon intuitive grâce au panneau d'administration fournit avec Django - sous la forme d'une application auxiliaire.

Il s'agit d'une interface complète, crée dynamiquement à partir de la définition des modèles de données, et qui peut être activée en un éclair. Par défaut, elle permet d'ajouter, de modifier, et de supprimer des objets dans la base, mais peut-être étendue à d'autres opérations et peut être personalisée dans les moindres détails.

Il n'est donc plus nécessaire de se débattre avec phpMyAdmin ou de devoir créer un panneau d'administration maison pour pouvoir effectuer ces opérations simple, notamment au commencement du projet.

Pour ne pas réinventer la roue

Django intégre de série des bibliothèques spécialisées et conçue pour fonctionner ensemble, couvrant les besoin vitaux du développeur web : pour gérer les sessions et l'autentification des utilisateurs, pour contrôler la mise en cache des pages et des données, pour administrer du contenu multi-sites ou multi-langues, ou encore pour intégrer facilement des commentaires, des flux rss ou des sitemaps en xml.

À cela s'ajoute les contributions de la communauté d'utilisateurs du framework qui, depuis la publication de Django sous licence libre en 2005, a accumulé une collection impresionnante de code réutilisable (le plus souvent des applications aisément intégrables) : étiquetage générique d'objets (tags), enregistrement de compte utilisateur, votes, moteur de blog, forum, réseau sociaux, ou encore openid [lien vers le précédent article]. La majorité de ces projets sont hébergé sur Google Code.

Enfin, il ne faut pas oublier que Django est écrit en Python et que ce langage possède une communauté d'utilisateurs encore plus large. Une myirade de bibliothèques et de « recettes » sont disponible pour gérer à peu près n'importe quel protocole ou format de fichier usuel (emails, pdfs, traitement d'image, de son ou de vidéo, crypto, compression, RPC, ...). Cette ouverture permet de connecter, souvent très facilement, un site avec d'autres composants logiciels.

Déploiement

Pour faciliter les tests, Django est livré avec une mini serveur de développement qui permet de faire tourner une version locale du site. Cela rend superflue l'utilisation d'Apache ou d'IIS sur des machines dédiées au développement et non à la production. Combiné avec le moteur de base de données SQLite, cela rend possible le déploiement d'un environnement de développement ou de démonstration en quelque secondes.

La mise en ligne sur un serveur de production n'est pas tellement plus compliquée, si ce n'est qu'on préfèrera une moteur de base de données plus lourd, tel que MySQL. Django s'intègre facilement à de nombreuses architectures Web (Apache mod_python/FastCGI, lighthttpd, ou même IIS) et est particulièrement adapté à un déploiement à large échelle. En effet, le framework a été développé à la base pour le site à fort trafic d'un grand quotidien américain. La gestion des fichiers statiques ou de la cache sont en effet facilités.

Conclusion

Django n'est certes pas la solution magique pour tous les projets Web, la concurence est là pour en attester. Les « éléphants » de la programmation web - nommément PHP, ainsi que les autres java, asp, etc. - ont encore quelques années devant eux, mais la conquête des nouvelles générations de développeurs est loin d'être acquise (Google a choisi Python et de nombreux concepts empruntés à Django pour faire la démonstration de son App Engine). Les autres frameworks « agiles » ou « Web 2.0 » - dont Ruby on Rails - continuent à faire parler d'eux, mais n'ont pas atteint pour autant le degré de simplicité de Django dans beaucoup de domaines.

À notre sens, c'est l'outil idéal - du moins le meilleur que nous connaissons - pour la réalisation de projets de taille moyenne à grande, en particulier lorsque le cahier des charges n'est pas très précis. Nous l'utilisons également volontiers pour créer des prototypes ou pour des intranet à petit budget.

Pour vous faire une opinion :

• http://www.djangoproject.com - Site officiel
• http://www.django-fr.com - Communauté francophone d'utilisateurs
• http://docs.djangoproject.com/ - Documentation de référence
• http://code.djangoproject.com/ - Wiki du projet (développeurs)
• http://code.google.com/search/#q=django - Projets Django sur Google Code