URL: https://linuxfr.org/news/sortie-de-django-13 Title: Sortie de Django 1.3 Authors: Johan Charpentier Date: 2011年03月23日T09:51:06+01:00 License: CC By-SA Tags: django, python et ruby Score: 42 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]] (MVC), 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_](http://bitbucket.org), [_Libération.fr_](http://liberation.fr), [_Disqus_](http://disqus.com/), _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é. ---- [Annonce de la sortie](http://www.djangoproject.com/weblog/2011/mar/23/13/) [Site web du projet](http://www.djangoproject.com/) [Notes de version](http://docs.djangoproject.com/en/dev/releases/1.3/) [Dépêche sur la 1.2](http://linuxfr.org/news/sortie-de-django-12) [Communauté francophone](http://www.django-fr.org/) [DjangoCong](http://rencontres.django-fr.org/2011/) ---- Tout comme [RoR](http://www.rubyonrails.org), sa flexibilité en fait une bonne alternative à mi‐chemin entre le [[CMS]] et le langage pur pour la conception d’applications Web [agiles](http://fr.wikipedia.org/wiki/M%C3%A9thode_agile). Django commence à gagner les cœurs des développeurs Web. À tel point, d’ailleurs, que les développeurs de [Wordpress](http://wordpress.org/), sûrement envieux de l’une des étoiles montantes du Web, avaient initialement nommé leur version 3.1 « Django », avant de la renommer [_Reinhardt_](http://wordpress.org/news/2011/02/threeone/). Voici la traduction sommaire de quelques points que vous trouverez dans les [notes de version](http://docs.djangoproject.com/en/dev/releases/1.3/) : # 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](http://docs.djangoproject.com/en/dev/misc/api-stability/). 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](http://docs.djangoproject.com/en/dev/releases/1.3/#backwards-incompatible-changes-1-3). À 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](http://docs.djangoproject.com/en/dev/topics/class-based-views/) ## 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](http://docs.djangoproject.com/en/dev/topics/class-based-views/) sur ce sujet et le moyen de [convertir votre ancien code](http://docs.djangoproject.com/en/dev/topics/generic-views-migration/). ## [Journalisation](http://docs.djangoproject.com/en/dev/topics/logging/) ## 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_](http://docs.python.org/library/logging.html) 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](http://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/) ## 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_](http://pypi.python.org/pypi/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_](http://docs.djangoproject.com/en/dev/releases/1.3/#unittest2-support) ## 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 : ```python from django.utils import unittest # Là où avant vous faisiez : import unittest ``` ## [Gestion des contextes transactionnels](http://docs.djangoproject.com/en/dev/topics/db/transactions/#transaction-management-functions) ## Les utilisateurs de Python 2.5 et supérieur pourront utiliser les contextes transactionnels comme : ```python 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](http://docs.djangoproject.com/en/dev/releases/1.3/#configurable-delete-cascade) ## 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`](http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.on_delete) » de modifier ce comportement. ## [Commentaires dans les chaînes de traduction](http://docs.djangoproject.com/en/dev/releases/1.3/#contextual-markers-and-comments-for-translatable-strings) ## 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: » : ```python 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_ : ```jinja {% comment %}Translators: This is a text of the base template {% endcomment %} ``` ## [TemplateResponse](http://docs.djangoproject.com/en/dev/ref/template-response/) ## 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`](http://docs.djangoproject.com/en/dev/ref/template-response/#django.template.response.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](http://docs.djangoproject.com/en/dev/topics/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](http://docs.djangoproject.com/en/dev/releases/1.3/#everything-else) ## 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 »`](http://docs.djangoproject.com/en/dev/ref/contrib/sites/) ; * une classe [`RequestFactory`](http://docs.djangoproject.com/en/dev/topics/testing/#django.test.client.RequestFactory) pour forger des requêtes dans les tests ; * une nouvelle fonction de test — [`assertNumQueries()`](http://docs.djangoproject.com/en/dev/topics/testing/#django.test.TestCase.assertNumQueries) — qui permet de contrôler le nombre de requêtes exécutées dans une vue ; * support des _cookies_ [HTTPOnly](http://www.owasp.org/index.php/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()`](http://docs.djangoproject.com/en/dev/topics/http/shortcuts/#django.shortcuts.render) — alternative à [`render_to_response()`](http://docs.djangoproject.com/en/dev/topics/http/shortcuts/#django.shortcuts.render_to_response) — incluant [`RequestContext`](http://docs.djangoproject.com/en/dev/ref/templates/api/#django.template.RequestContext) par défaut ; * possibilité de combiner les [expressions de type `F()`](http://docs.djangoproject.com/en/dev/topics/db/queries/#query-expressions) avec des objets Python `« timedelta »`. # Rétro‐compatibilité # La liste complète est visible sur [ce lien](http://docs.djangoproject.com/en/dev/releases/1.3/#backwards-incompatible-changes-in-1-3). Parmi cette liste, citons : * la protection [CSRF](http://docs.djangoproject.com/en/dev/ref/contrib/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](http://docs.djangoproject.com/en/dev/releases/1.3/#clearable-default-widget-for-filefield) ; * nouvel index sur la table session : pas de changement sur votre code mais [une petite astuce](http://docs.djangoproject.com/en/dev/releases/1.3/#new-index-on-database-session-table) pour « booster » votre application ; * dans le _contrib_ « `comments` », la liste de mots placés en liste noire [a été vidée](http://docs.djangoproject.com/en/dev/releases/1.3/#no-more-naughty-words) ; * [quelques changements concernant](http://docs.djangoproject.com/en/dev/releases/1.3/#localflavor-changes) le Canada, les États-Unis et l’Indonésie ; * changements dans les [`FormSet`](http://docs.djangoproject.com/en/dev/releases/1.3/#formset-updates) ; * [certaines méthodes dans les _templates_](http://docs.djangoproject.com/en/dev/releases/1.3/#callables-in-templates) ; * changement de la politique de [gestion du SQL personnalisé dans les tests](http://docs.djangoproject.com/en/dev/releases/1.3/#use-of-custom-sql-to-load-initial-data-in-tests) ; * changement de [l’ordre de chargement des chaînes traduites](http://docs.djangoproject.com/en/dev/releases/1.3/#changed-priority-of-translation-loading) ; * quelques changements dans la gestion des « [`Transactions`](http://docs.djangoproject.com/en/dev/releases/1.3/#transaction-management) » ; * 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](http://docs.djangoproject.com/en/dev/releases/1.3/#features-deprecated-in-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](http://docs.djangoproject.com/en/dev/releases/1.3/#id1) ; * `CompatCookie` est à remplacer par `SimpleCookie` ; * le répertoire de gestion des [traductions globales est déprécié](http://docs.djangoproject.com/en/dev/releases/1.3/#loading-of-project-level-translations) ; * `PermWrapper` a été déplacé dans `« django.contrib.auth.context_processors »` ; * `XMLField` [sera retiré à la 1.4](http://docs.djangoproject.com/en/dev/releases/1.3/#removal-of-xmlfield). Ne pas oublier de consulter la [liste des éléments dépréciés dans la version 1.2](http://docs.djangoproject.com/en/dev/releases/1.2/#features-deprecated-in-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](http://groups.google.com/group/django-developers/browse_thread/thread/9ebc3e57d539d1ff?pli=1) 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](http://docs.djangoproject.com/en/dev/internals/contributing/). # 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](http://rencontres.django-fr.org/2011/), 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.

AltStyle によって変換されたページ (->オリジナル) /