Sortie de Django 1.3

Mercredi matin, 11 mois après la 1.2, est sortie la version 1.3 du framework Web Django, écrit en Python.

Ce framework, basé sur un concept [Modèle-Vue-Contrôleur], est conçu pour le développement rapide et reprend la plupart des grands principes de Python (« Explicit is better than implicit », notamment), ce qui en fait la plate-forme de développement Web idéale pour les perfectionnistes sous pression.

De plus en plus de sites utilisent Django (par exemple, Bitbucket.org, Libération.fr, Disqus, Century21, convore, instagram, threadless…) pour sa flexibilité et pour le nombre d’applications Django réutilisables, qui ne cesse de croître.

Je vous propose de découvrir les quelques nouveautés que vous offrent les développeurs Django et toute la communauté.

Sommaire

• Notes de version
  • Vues basées sur les classes
  • Journalisation
  • Meilleure gestion des fichiers statiques
  • Support de unittest2
  • Gestion des contextes transactionnels
  • Suppression en cascade configurable
  • Commentaires dans les chaînes de traduction
  • TemplateResponse
  • Le cache
  • Tout le reste
• Rétro‑compatibilité
• Dépréciations
  • Contribuer
• Communauté francophone
  • DjangoCong

Tout comme RoR, sa flexibilité en fait une bonne alternative à mi‑chemin entre le CMS et le langage pur pour la conception d’applications Web agiles.

Django commence à gagner les cœurs des développeurs Web. À tel point, d’ailleurs, que les développeurs de Wordpress, sûrement envieux de l’une des étoiles montantes du Web, avaient initialement nommé leur version 3.1 « Django », avant de la renommer Reinhardt.

Voici la traduction sommaire de quelques points que vous trouverez dans les notes de version :

Notes de version

Django 1.3 s’est concentré sur une quantité de petites modifications demandées depuis longtemps, cependant quelques gros ajouts sont notables :

• un framework pour écrire des vues basées sur des classes (class‑based views) ;
• l’utilisation des fonctionnalités de journalisation proposées par Python avec le module logging ;
• une contribution pour supporter facilement la gestion des fichiers statiques ;
• le framework de test de Django supporte maintenant (et est livré avec une copie de) la bibliothèque de tests unittest2.

Tous ces changements se sont faits dans un respect de la politique de stabilité d’API. C’est pourquoi Django 1.3 apporte son lot d’éléments mis en dépréciation.

Cependant, certains changements ne sont pas rétro‑compatibles et il faut consulter la documentation relative à ce sujet.

À noter également que c'est la dernière version à supporter Python 2.4, un document indiquant la future migration vers Python 3 sera annoncé sous peu.

Vues basées sur les classes

Django 1.3 offre la possibilité d'utiliser des vues génériques sous forme de classe.
Vous pouvez donc composer ces vues dans l'optique de les dériver et vous faire économiser quelques lignes de code.

Ces vues peuvent être utilisées d'une manière analogue aux précédentes vues génériques mais avec une capacité a être facilement réutilisées et modifiées.

Voir la documentation sur ce sujet et le moyen de convertir votre ancien code.

Journalisation

Fini les « print » cachés tout au long du code pour faire un semblant de débogage. Django permet une intégration plus fine du module Python logging en vous permettant de préciser dans le fichier de configuration de votre projet, la manière d’enregistrer les messages que vous enverra votre projet. Il rajoute en plus le handler AdminEmailHandler pour envoyer le message sous forme d’e-mail directement aux adresses listées comme administrateurs dans la configuration.

Meilleure gestion des fichiers statiques

Quand, avec Django, on avait une vingtaine d’applications tierces, en plus de celles de notre projet, il fallait gérer les fichiers statiques et créer des liens symboliques pour chacune de ces applications.

Grâce à une nouvelle bibliothèque en contribution appelée « staticfiles » et basée sur django-staticfiles, chaque application va pouvoir définir des fichiers statiques à inclure au projet. Ces fichiers seront collectés et centralisés dans un point. Celà permettra, par exemple, à un serveur Web classique de servir ces fichiers.

La commande : ./manage.py collectstatic suffira pour mettre à jour ces chemins.

Support de unittest2

Pour assurer une qualité de test identique pour tous, les développeurs Django ont retro‑porté le module unittest2 pour le rendre compatible avec Python 2.4.

Il sera utilisable simplement avec l’importation :

from django.utils import unittest
# Là où avant vous faisiez :
import unittest

Gestion des contextes transactionnels

Les utilisateurs de Python 2.5 et supérieur pourront utiliser les contextes transactionnels comme :

with transaction.autocommit():
    # ...

Ce qui permet notamment de dérouler les opérations dans le bloc « with » et de n’enregistrer effectivement dans la base qu’uniquement si toutes les opérations ont été menées avec succès.

Suppression en cascade configurable

De base, quand on supprime un objet, Django supprime tous les autres objets le référençant par une clef étrangère.

Il est maintenant possible avec l’attribut « on_delete » de modifier ce comportement.

Commentaires dans les chaînes de traduction

Il est possible de laisser des commentaires dans les chaînes de traduction. Ces commentaires seront visibles pour les futurs traducteurs, il suffit pour cela de faire précéder notre chaîne par un commentaire Python commençant par « Translators:  » :

from django.utils.translation import ugettext as _

def my_view(request):
    # Translators: This message appears on the home page only
    output = _("Welcome to my site.")

Ou dans les templates :

{% comment %}Translators: This is a text of the base template {% endcomment %}

TemplateResponse

Une fois une réponse construite avec « HttpResponse », elle est stockée sous forme de texte. En effet, cet objet est assez basique et correspond à la réponse HTTP que Django va servir, avec les entêtes de la réponse via un dictionnaire et le contenu sous forme de chaîne de texte. Il est donc difficile d’opérer un changement plus fin, comme changer le template.

Django 1.3 propose une nouvelle classe appelée « TemplateResponse » qui sépare le contexte du template. Ainsi il est possible de changer dynamiquement le template utilisé. Le rendu final se faisant uniquement quand la réponse est envoyée.

Le cache

Un certain nombre de fonctionnalités ont étés ajoutées au cache :

• Django 1.2 à donné la possibilité d'utiliser plusieurs bases de données, Django 1.3 donnera la possibilité d'utiliser plusieurs sources de cache.
• Possibilité de versionner les objets mis en cache
• Possibilité de préfixer les clefs à l'échelle d'un projet (utile sur un serveur mutualisé hébergeant plusieurs instances d'un même projet par exemple)
• Support de pylibmc pour memcached

Tout le reste

Django 1.1 et 1.2 ont apporté des modifications conséquentes, ce qui a été en défaveur de fonctionnalités plus simples. Django 1.3 s’est donc d’avantage concentré sur ces petits ajouts qui font beaucoup :

• meilleure gestion de « Site » ;
• une classe RequestFactory pour forger des requêtes dans les tests ;
• une nouvelle fonction de test — assertNumQueries() — qui permet de contrôler le nombre de requêtes exécutées dans une vue ;
• support des cookies HTTPOnly ;
• mail_admins() et mail_managers() permettent d’attacher du HTML aux messages envoyés ;
• EmailMessage permet de rajouter des adresses en copie (CC) ;
• les mails d'erreur se rapprochent de la page d'erreur affichée sur un site en mode DEBUG ;
• amélioration de simple_tag() pour rendre plus facile l’écriture de tags ;
• une méthode render() — alternative à render_to_response() — incluant RequestContext par défaut ;
• possibilité de combiner les expressions de type F() avec des objets Python « timedelta ».

Rétro‑compatibilité

La liste complète est visible sur ce lien. Parmi cette liste, citons :

• la protection CSRF s’applique désormais aux requêtes AJAX ;
• la manipulation des filtres dans l’interface d’administration ne pourra se faire qu’uniquement avec « list_filter » ;
• la suppression d’un « FileField » ne surprime plus le fichier associé ;
• PasswordInput a maintenant un attribut « render_value » qui contrôle si, oui ou non, la donnée contenue doit être renvoyée au navigateur ;
• les « FileField » possèdent désormais par défaut un widget pour supprimer la valeur du champ. Pour revenir au rendu précédent, il faut appliquer quelques changements sur son code ;
• nouvel index sur la table session : pas de changement sur votre code mais une petite astuce pour « booster » votre application ;
• dans le contrib « comments », la liste de mots placés en liste noire a été vidée ;
• quelques changements concernant le Canada, les États-Unis et l’Indonésie ;
• changements dans les FormSet ;
• certaines méthodes dans les templates ;
• changement de la politique de gestion du SQL personnalisé dans les tests ;
• changement de l’ordre de chargement des chaînes traduites ;
• quelques changements dans la gestion des « Transactions » ;
• les utilisateurs inactifs ne pourront plus changer leur mot de passe.

Dépréciations

La politique de Django stipule qu’un élément qui devra être retiré passera par un certain nombre d’étapes (exemple pour Django 1.3) :

• Django 1.3 : PendingDeprecationWarning : avertissement silencieux qui peut être affiché via l'option « -Wd » de l’interpréteur.
• Django 1.4 : DeprecationWarning : avertissement visible.
• Django 1.5 : retrait.

Voici une liste non‑exhaustive des nouveaux éléments dépréciés dans Django 1.3 :

• le support de mod_python sera retiré dans Django 1.5 ;
• vues génériques basées sur les fonctions suivantes :
  • django.views.generic.create_update,
  • django.views.generic.date_based,
  • django.views.generic.list_detail,
  • django.views.generic.simple ;
• utilisation de response.template dans les tests (remplacé par response.templates) ;
• avec l’utilisation de unittest2, DjangoTestRunner, qui ajoutait les options « failfast » et la gestion du « ctrl-C », n’est plus utile ;
• les tags « url » et « ssi » utiliseront la notation entre apostrophes ;
• la méthode d’authentification de la page d’administration utilise les mécanismes de base du contrib « auth », au lieu d’implémentations personnalisées ;
• « ./manage.py reset » et « ./manage.pysqlreset » sont dépréciées, utiliser plutôt « flush » et « sqlflush » pour vider vos tables ;
• quelques dépréciations sur GeoDjango  ;
• CompatCookie est à remplacer par SimpleCookie ;
• le répertoire de gestion des traductions globales est déprécié ;
• PermWrapper a été déplacé dans « django.contrib.auth.context_processors » ;
• XMLField sera retiré à la 1.4.

Ne pas oublier de consulter la liste des éléments dépréciés dans la version 1.2 pour connaître les futurs éléments retirés dans Django 1.4.

Contribuer

Django a souvent été désigné comme un projet fermé où très peu de contributions étaient acceptées. Le nombre de tickets (y compris de simples bogues) en attente d’inclusion ou de validation par l’équipe Django était déprimant et ne poussait pas à de nouvelles collaborations.

Un message a été envoyé en septembre indiquant que l’équipe était consciente de ces problèmes et allait tenter de réduire le nombre de goulots d’étranglement et ajouter de nouveaux commiters.

Vous êtes donc, et de manière plus ouverte qu’avant, conviés à participer au projet.

Communauté francophone

Toutes les bonnes volontés sont demandées pour faire vivre le site de la communauté francophone de Django. Rendez‑vous sur la liste de diffusion que vous trouverez sur le site, ou mieux : passez nous voir sur le canal IRC « #django-fr » de Freenode.

DjangoCong

Le 16 et 17 avril se déroulera à Marseille la DjangoCong, rencontre de la communauté de développeurs Django francophones.

Cette rencontre est possible grâce aux différents sponsors :

• PilotSystems ;
• Hybird ;
• Biologeek ;
• Evolix ;
• Semio ;
• Alwaysdata ;
• Akei.

Mais il est encore possible d’aider dans cette aventure la toute jeune association Django-fr. Les niveaux de sponsoration sont les suivants :

• 200 € : poney motivé (mention + deux places + logo avec lien sur le site) ;
• 400 € : poney généreux (mention + trois places + logo avec lien sur le site + possibilité de passer une offre d’emploi sur la liste des inscrits).

En devenant sponsor, vous serez mentionné dans les communications autour de l’évènement, ainsi qu’en début et fin d’évènement.

NdA : merci à Alexis Metaireau et Davy Defaud pour l’aide apportée à la réalisation de cette dépêche.

Aller plus loin

• Annonce de la sortie (120 clics)
• Site web du projet (237 clics)
• Notes de version (50 clics)
• Dépêche sur la 1.2 (40 clics)
• Communauté francophone (198 clics)
• DjangoCong (140 clics)