URL: https://linuxfr.org/news/retour-sur-django-1-5 Title: Retour sur Django 1.5 Authors: Johan Charpentier redgriff, Nÿco, Atem18, claudex, RoPP, tuiu pol, Benoît Sibaud, Thomas Debesse et jcr83 Date: 2012年11月29日T00:52:56+01:00 License: CC By-SA Tags: django Score: 35 Le mardi 26 février, 11 mois après la 1.4, est sortie la version 1.5 du _framework_ web Django, écrit en Python. Ce framework, basé sur un concept Modèle-Gabarit-Vue (MGV, à rapprocher du 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, 20minutes, 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é. _NdM : le 28 mars la version 1.5.1 de Django est sortie. Il s'agit d'une version de maintenance corrigeant quelques bogues mineurs et un problème de fuite de mémoire introduit par la version 1.5._ ---- [Notes de version](https://docs.djangoproject.com/en/1.5/releases/1.5/) [Annonce de la sortie](https://www.djangoproject.com/weblog/2013/feb/26/15/) [Annonce de la sortie de la 1.4 sur LinuxFR.org](https://linuxfr.org/news/sortie-de-django-1-4) ---- # Notes de version # ## Principales nouveautés ## * Configuration du modèle _User_ * Compatibilité « expérimentale » avec Python 3 * Meilleure gestion des _streaming responses_ * Sélection des champs mis à jour lors de la sauvegarde d'un modèle * Prise en charge de l'enregistrement d'un sous-ensemble des champs du modèle * Mise en cache des instances liées au modèle * {% verbatim %} template tag * Récupération des instances associées ContentType avec des modèles de proxy * Nouvelle variable view dans le contexte des vues basées sur des classes * GeoDjango ## Détails ## ### Modèle _User_ configurable ### Les versions précédentes imposent un modèle d'utilisateur. Ce modèle sert notamment à authentifier les utilisateurs et gérer les permissions. Pour étendre ce modèle il faut définir un autre modèle (nommé profile) qui contient les champs supplémentaires. Cette solution présente plusieurs inconvénients. Une requête SQL supplémentaire ou une jointure est nécessaire pour obtenir les autres champs et il n'est pas possible de modifier le champs _username_.e La version 1.5 introduit la prise en charge des modèles utilisateurs configurable ([_Configurable User model_](https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#auth-custom-user)). Il est donc possible de remplacer le modèle par défaut. Plusieurs classes abstraites sont disponibles pour faciliter l'intégration de son modèle avec le reste du framework (gestion des permissions) ou étendre le modèle User existant. L'utilisation des profiles est toujours prise en charge mais la méthode get\_profile du modèle User sera supprimée dans la version 1.7. Pour ceux qui souhaitent migrer vers ces nouveaux modèles d'utilisateurs, [south](http://south.aeracode.org/) devrait faciliter la migration de la base de données. Cette [question](http://stackoverflow.com/questions/14904046/migrating-existing-auth-user-data-to-new-django-1-5-custom-user-model) sur Stack Overflow donne quelques pistes. ### Python 3 ### Il y a du changement sur les versions de Python prises en charge. Le support de Python 3 (en version 3.2) est de la partie. Pour le moment ce support est expérimental et certaines fonctionnalités dépendant de bibliothèques externes ne sont pas disponible avec Python 3. De plus, il faudra attendre que les applications les plus populaires soient également compatibles. À noter que la [même base de code](https://docs.djangoproject.com/en/1.5/topics/python3/) tourne sous Python 2 et Python 3. Le support de Python 2.5 est quant à lui passé à la trappe. Cela devrait surtout impacter les utilisateurs de Jython qui peuvent se rabattre sur la version alpha de Jython 2.7 (supportée par Django). ### Gestion améliorée des streamings responses ### Avant Django 1.5, il était possible de créer des réponses de type « _streaming_ » en passant un itérateur au constructeur `HttpResponse`. Malheureusement, ce comportement complique l'écriture des _middlewares_ qui risquent de consommer l'itérateur. Pour palier ce problème, une nouvelle classe (`StreamingHttpResponse`) est disponible. Les _middlewares_ peuvent dorénavant adapter leur comportement suivant le type des réponses reçues. ### Améliorations de l'ORM ### Plusieurs nouvelles fonctionnalités peuvent améliorées les performances de l'ORM. Lors de l'enregistrement d'une instance (méthode `.save()` en base de données, il est désormais possible de limiter les champs sauvegardés. Cela permet de limiter les risques d'écrasement lors d'accès concurrents. Les instances différées (obtenues via les méthodes `.only()` et `.differ()`) limitent automatiquement aux champs pré-chargés et à ceux qui ont été explicitement modifiés. Lors du parcours des relations, l'ORM évitera de récupérer les objets précédemment chargés. Par exemple, dans l'exemple suivant : ```python>>> first_poll = Poll.objects.all()[0]>>> first_choice = first_poll.choice_set.all()[0]>>> first_choice.poll is first_poll True ``` Avec Django 1.5, la troisième ligne n'exécute plus de requête SQL pour récupérer first_choice.poll puisqu'il a été défini par la deuxième ligne. Cette amélioration peut s'avérer très utile en combinaison de la méthode `prefetch_related` introduite dans Django 1.4. La suppression d'un ou plusieurs objets est accélérée quand il n'y a ni signaux enregistrés ni suppressions en cascade. Les modèles peuvent définir des [index multi-colonnes](https://docs.djangoproject.com/en/1.5/ref/models/options/#django.db.models.Options.index_together). ### Améliorations de la documentation ### Les djangonautes auront l'agréable surprise de découvrir une nouvelle page d'accueil de la documentation mieux structurée. Plusieurs nouveaux tutoriels ont été écris dont l'un sur l'écriture d'applications réutilisables et un autre sur l'écriture de tests. ### Template tag {% verbatim %} ### Les templates javascript devenant de plus en plus populaire il fallait une solution pour éviter leur collision avec la syntaxe de template de Django. Vous pouvez maintenant utiliser la balise de bloc verbatim afin d'éviter l'analyse du contenu de la balise. ### Récupération des instances associées ContentType avec des modèles de proxy ### Les méthodes `ContentTypeManager.get_for_model()` et `ContentTypeManager.get_for_models()` ont un nouveau mot-clé comme argument- respectivement `for_concrete_model` et `for_concrete_models`. En passant `False` en utilisant cet argument, il est désormais possible de récupérer le ContentType associé à des modèles de proxy. ## Autres changements ## * La commande `dumpdata` retourne les données lignes par ligne pour éviter les congestions de mémoire lors de l'export d'un grand nombre de données * `LOGIN_URL` et `LOGIN_REDIRECT_URL` accepte désormais [les chemins de vues ou les noms de chemin d'URL](https://docs.djangoproject.com/en/1.5/ref/settings/#std:setting-LOGIN_URL) tels que l'on puisse désormais écrire `LOGIN_URL="testapp.mavue"`ou `LOGIN_URL="mylogin"` * Fini les erreurs bien moches si l'on a oublié d'avoir des templates `404.html` ou `500.html` : Django affiche désormais des pages génériques pour ces situations si les templates correspondants ne sont pas présents. Les codeurs consciencieux que sont les developeurs Python s'assureront tout de même de que ces templates soient présents. * Un [signal](https://docs.djangoproject.com/en/1.5/ref/contrib/auth/#django.contrib.auth.signals.user_login_failed) existe si un utilisateur n'a pas réussi a s'authentifier. * Abandon du module _simplejson_ pour le module standard _json_ * La commande `loaddata` possède un argument `ignorenonexistent` pour ignorer les champs présents dans le fichier qui n'existent plus dans vos modèles * Possibilité de [filtrer par requête](https://docs.djangoproject.com/en/1.5/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_list_filter) dans l'administration ## Quelques statistiques ## Le projet django a migré de subversion vers git en avril 2012. Entre la version 1.4 et la version 1.5, il y a eu 13513 commits (`git log --no-merges --pretty=oneline 1.4 1.5 | wc -l`) ``` $ git diff --shortstat 1.4 1.5 3758 files changed, 164853 insertions(+), 153265 deletions(-) ``` # Modules utiles # On compense le retard de l'annonce de la sortie de Django en parlant de modules sympas sortis ou ayant une utilité particulière entre la 1.4 et 1.5 : * Le tueur de [Wordpress](http://www.wordpress.org/) : [Mezzanine](http://mezzanine.jupo.org/) (CMS) * Le destructeur de [Piston](https://django-piston.readthedocs.org/en/latest/documentation.html) : [Django REST Framework](http://django-rest-framework.org/) (API) * L'altérateur de l'Escuelle : [South](http://south.aeracode.org/) (DB) ## Mezzanine ## Mezzanine est un [Système de gestion de contenu](http://fr.wikipedia.org/wiki/Système de gestion de contenu "Définition Wikipédia") (Content Management System ou CMS) distribué sous licence BSD. Basé sur Django, il se veut être une alternative à Wordpress. Il fournit un CMS complet qui peut être déployé sans écrire une seule ligne de code. Il propose de nombreuses fonctionnalités, telles que : * navigation hiérarchique * une interface d'administration complète (édition des pages, gestion des redirections, des médias, des formulaires) * éditeur WYSISWYG (via TinyMCE, remplaçable par du Markdown) * moteur de blog * gestion des tags * intégration avec plusieurs services externes (Disqus, Gravatar, Twitter, bit.ly, Askimet...) * une boutique en ligne [Cartridge](http://cartridge.jupo.org/) * [et beaucoup d'autres fonctionnalités](http://mezzanine.jupo.org/docs/overview.html#features) Ces fonctionnalités sont intégrées de manière cohérente. Par exemple, le thème par défaut (basé sur Twitter Bootstrap) active le service de commentaires Disqus si celui-ci est configuré. Si Mezzanine propose un CMS complet, il reste facilement personnalisable. Les _templates_ sont plutôt bien découpés et il est assez simple d'intégrer ses propres modèles de pages. Mezzanine est un bon choix pour les débutants qui veulent déployer un CMS tout en découvrant Django. La version 1.4.3 est sortie le 27 février et est compatible avec Django 1.5. ## Django REST Framework ## Dans ce joli monde des frameworks Javascript la nécéssité de représenter ses modèles via une interface CRUD devient de plus en plus impérative. Plusieurs applications Django existent dans ce sens comme : * [Tastypie](http://tastypieapi.org/) * [Django REST Framework](http://django-rest-framework.org/) Ce dernier à l'avantage de possèder une syntaxe se rapprochant du système de vues objet naturel de Django [Class based views](https://docs.djangoproject.com/en/1.5/topics/class-based-views/) La jolie n'image présente en page d'accueil du site de Django REST Framework est la représentation en HTML de l'API. Toute requête sur la même url avec par exemple le content-type application/json ou le paramètre `format=json` l'affichera en `JSON`. Pour reprendre l'exemple voici ce que donnerai l'exposition du modèle `User` de base de Django : Tout d'abord, on configure un serialiseur qui s'occupera de déterminer comment traiter les données : `testapp/serializers.py` ```python from rest_framework import serializers class UserSerializer(serializers.ModelSerializer): class Meta: model = User fields = ('url', 'username', 'email') ``` Une vue pour présenter ces données : `testapp/views.py` ```python from django.contrib.auth.models import User from testapp.serializers import UserSerializer from rest_framework import generics class UserList(generics.ListCreateAPIView): model = User serializer_class = UserSerializer ``` Et enfin les urls associées : `testapp/urls.py` ```python from django.conf.urls import patterns, url from rest_framework.urlpatterns import format_suffix_patterns from testapp import views urlpatterns = patterns('', url(r'^users/$', views.UserList.as_view(), name='user-list'), url(r'^users/(?P[0-9]+)/$', views.UserDetail.as_view(), name='user-detail') ) ``` Pour jouer avec vous avez un joli [bac à sable](http://restframework.herokuapp.com/) ## south ## South est une application qui se révèle rapidement indispensable puisqu'elle apporte la gestion des migrations des bases de données. La dernière version de south (0.7.6) est en grande partie compatible avec Django 1.5 à l'exception de : * la prise en charge des index multi-colonnes [ticket correspondant](http://south.aeracode.org/ticket/1217) * le changement simple du modèle User (voir [cette discussion](https://groups.google.com/forum/?fromgroups=#!topic/south-users/CTpNthRf9Kc) sur les problèmes à résoudre)

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