URL: https://linuxfr.org/news/django-1-7-le-framework-web-pour-les-perfectionnistes-sous-pression Title: Django 1.7, « le framework web pour les perfectionnistes sous pression » Authors: redgriff Nÿco, Benoît Sibaud, BAud, palm123, Xavier Teyssier, ZeroHeure, alendroi, mathgl et Nicolas Boulay Date: 2014年04月15日T22:02:23+02:00 License: CC By-SA Tags: python, django, développement_web et web Score: 33 D'après Wikipedia : « Django est un framework open-source de développement web en Python. Il a pour but de rendre le développement web 2.0 simple et rapide. Pour cette raison, le projet a pour slogan « Le framework web pour les perfectionnistes sous pression ». Développé au départ pour les sites de la ville de Lawrence (Kansas), Django a été publié sous licence BSD à partir de juillet 2005. » ![Django](https://www.djangoproject.com/s/img/site/hdr_logo.b19c5e60269d.gif) La version 1.7 du framework web Django est sortie le 2 septembre 2014. La principale nouvelle fonctionnalité est la gestion intégrée des migrations de schéma. On notera la publication de la version 1.7.5 le 25 février 2015, et en même temps, la première bêta de la version 1.8. ---- [Notes de version](https://docs.djangoproject.com/en/1.7/releases/1.7/) ---- # Nouveautés ## Migrations des schémas de base de données Django inclut, enfin, une gestion des migrations des bases de données. Jusqu'ici, la plupart des projets utilisaient [South](http://south.aeracode.org/). L'auteur de cette application, Andrew Godwin, a pu financer l'intégration d'une refonte de South au sein de Django via une [campagne Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django). Pour les curieux, Andrew Godwin a présenté lors de la dernière PyCon US les choix opérés lors du développement. La vidéo est disponible sur [YouTube](http://youtu.be/a-_GAHfpk1Y#t=13). ## Refactoring du chargement des applications Le chargement des applications a été réécrit. Cette réécriture permet d'améliorer les points suivants : * Une application qui n'utilise pas de modèle n'est plus obligée d'inclure un fichier `models.py` vide. * Une application peut définir sa configuration. Cette configuration permet notamment de donner un nom verbeux à l'application (ce nom est utilisé par l'interface d'administration) et une méthode `ready()` qui est appelée au lancement. * L'ordre des imports est plus déterministe et permet de mieux diagnostiquer les problèmes d'imports circulaires. Ce changement peut entraîner des incompatibilités avec du code existant. ## Simplification des QuerySetManager Dans Django, lorsque l'on souhaite définir des requêtes réutilisables, il est recommandé d'étendre la classe QuerySet et d'y définir ses propres méthodes. Cette méthode fonctionne bien, mais elle pose problème quand l'on définit un QuerySetManager (raccourci dans l'écriture de requêtes). En effet, si l'on souhaite réutiliser les méthodes d'un QuerySet sur un QuerySetManager, il est nécessaire de redéfinir chaque méthode. Par exemple : ```python class MouleQuerySet(models.QuerySet): def pas_fraiches(self): return self.filter(dlc_gte=datetime.datetime.utcnow()) def bretonnes(self): return self.filter(bassin='XXX') class MouleQuerySetManager(models.QuerySetManager): def get_queryset(self): return MouleQuerySet(self) def pas_fraiches(self): return self.get_queryset().pas_fraiches() def bretonnes(self): return self.get_queryset().bretonnes() class Moule(models.Model): bassin = models.CharField(max_length=50) dlc = models.DateTimeField() objects = MouleQuerySetManager() # utilisation # Moules bretonnes pas fraiches Moule.objects.bretonnes().pas_fraiches() ``` Avec Django 1.7, il n'est plus nécessaire d'écrire de classe héritant de QuerySetManager. À la place, il suffit d'appeler la méthode QuerySet.as\_manager() : ```python # la classe MouleQuerySet ne change pas class Moule(models.Model): bassin = models.CharField(max_length=50) dlc = models.DateTimeField() objects = MouleQuerySet.as_manager() # l'utilisation ne change pas Moule.objects.bretonnes().pas_fraiches() ``` ## Framework de vérification Un nouveau framework est disponible pour détecter les problèmes. Il remplace la simple validation des modèles (avec la commande `validate`) et permet de détecter : * les modèles invalides * l'utilisation de fonctionnalités dépréciées * les _settings_ manquants ou invalides * les traductions à mettre à jour. Ce framework est extensible et chaque application peut définir ses propres contrôles. ## Moteur de templates Pas de grands changements : * Un nouveau filtre `truncatechars\_html` qui tronque une chaîne en tenant compte des balises HTML. * Les exceptions de type TypeError ne sont plus ignorées silencieusement. * D'autres modifications... ## Versions de Python supportées Le support de Python 2.6 a été retiré. Django est compatible avec les versions 2.7, 3.3 et suivantes. Plusieurs modules inclus pour assurer la compatibilité avec Python 2.6 sont dépréciés : * django.utils.dictconfig * django.utils.importlib * django.utils.unittest * django.utils.datastructures.SortedDict ## Autres changements La commande `runserver` exploite pyinotify sous Linux au lieu d'un polling bête et méchant. Le rechargement du serveur est donc plus rapide et consomme moins de ressources. De même, il se relance automatiquement après la compilation d'une traduction. ### JSON La nouvelle sous-classe JsonResponse facilite la création de réponses renvoyant du JSON. Les erreurs d'un formulaire peuvent être converties en JSON avec la méthode as\_json().

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