Avant de commencer à te faire perdre ton temps, je tiens à te prévenir cher lecteur. Si tu as lu la release note de django 1.2 alpha 1, tu n’apprendras rien de plus en lisant ce petit billet.

Pourquoi alors l’écrire ?

Au cas où tu n’aurais pas encore lu la release note et que lire du français t’amuse plus que lire de l’anglais. Et puis comme ça, en plus, tu as le lien vers la release note.

1- Les trucs nouveaux

1.1- protection contre les attaques CSRF.

Les attaques CSRF (Cross-Site Request Foregery) sont rendus  possible par le partage des données de login/session entre les différents onglets d’un navigateur. Du coup, si vous êtes logués sur un site quelconque (prenons facebook comme exemple) et que vous allez sur le site d’un vilain méchant pirate, le vilain méchant pirate pourrait faire des actions sur Facebook, comme si c’était vous qui les faisiez. (Bon pour pouvoir faire cela, il faut que vous cliquiez sur un lien du site du vilain pirate, ou que vous soumettiez un formulaire ou que vous executiez du js).

Django implémente maintenant une façon cool de s’en protéger. (avant il existait un middleware pour le faire). Moralité, si Facebook était en django 1.2, les attaques CSRF ne seraient pas possible.

1.2- Backends des emails

On peut maintenant configurer la façon que django aura d’envoyer des emails. Sympa pour pouvoir debugger et tester les envois d’emails, ça évitera d’avoir à passer par des simulateurs de SMTP.

1.3- Le framework d’envoi de messages

Il remplacera l’ancienne API d’envoi de message et apparemment, il va être juste terrible. Les users authentifiés ou anonyme pourront en envoyer, on pourra les stocket en session ou en cookie, gérer des levels, des tags, que du bon quoi

1.4- Support des multiples bases de données

Alors ça, je l’attendais avec une impatience extrême. On pourra maintenant dire à django de se connecter à X bd différentes, choisir pour chaque requête bd sur quelle base on veut la faire ou où est ce que l’on veut sauver une instance de modèle. Que du bon quoi. Pour ne pas dire de la tuerie

1.5- Un tag if coolos

Là on peut résumer en une phrase : ‘Fini le ifnotequal a b et vive le if a != b’.

Les opérateurs de comparaisons sont enfin supporté. On pourra donc utiliser :

• ==
• !=
• <
• >
• <=
• >=
• in
• et and or et not (qui fonctionnaient déjà).

Et en plus, on pourra utiliser des filtres en même temps. Avec un {% if  inst1.var1|bla == inst2.var2|tut %}

Le pied je vous dis.

1.6- Gestion du cache des templates

On pourra configurer un truc de gestion de cache des templates. Et ça, c’est bien.

1.7- Clés en BD

On peut maintenant utiliser les naturals keys dans les fixtures (j’ai pas trouvé de traduction française qui me convenait). Ce qui peut-être bien sympa quand par exemple on a des fixtures qui bossent avec des content types (au hasard hein )

Et on peut maintenant utiliser des int de 64 bits avec le BigIntegerField .

1.8- En vrac

• une commande en plus sur le runtest qui permet de faire sortir le lanceur de test dés qu’il y a une erreur.
• Une amélioration de la localisation pour les dates et les nombres qui seront affichés (si l’option est activée) de la façon qui va bien en fonction de la locale.
• L’ajout de la  propriété readonly_fields pour les champs non éditable (enfin)
• la possibilité de customiser les couleurs pour les highlight dans la parti admin.

2- Les trucs  obsolètes ou incompatibles

Bon alors déjà, une nouvelle qui va faire que tout le monde va respirer, dans le 1.2 les trucs obsolètes seront encore supportés. Le support n’en sera supprimé que dans la version 1.4.  Ça laisse donc un peu de temps pour organiser ses migrations.

2.1- Le middleware CSRF

Forcément si la protection anti CSRF est refait d’une manière mieux, l’ancienne manière devient obsolète.

2.2- SMTPConnection

Ceux qui utilisaient la classe SMTPConnection pour envoyer des mails devront changer leur code. Heureusement les modifs sont légère (il suffit apparemment de remplacer l’appel au constructeur de la classe par un appel a get_connection () )

2.3- La configuration de la base de données

Forcément ça change. Faudra passer dans la syntaxe multidb, même si on a qu’une seule db.

2.4- L’API d’envoi de message.

Là encore, faut passer à la nouvelle version. Mais ça n’a pas l’air super compliqué. Du replace de nom de fonction et ça devrait le faire.

2.5- Les helpers de formatage de date.

Les fonctions django.utils.translation.get_date_formats() et django.utils.translation.get_partial_date_formats() sont obsolètes et il faudra les remplacer par django.utils.formats.get_format()

2.6- En vrac

• Du fait des nouvelles fonctionnalités du if, appeler des variable ‘and’, ‘or’ ou ‘not’ est encore moins une bonne idée, vu que vous allez vous manger des TemplateSyntaxError. Bon de toute façon, c’était déjà une très très mauvaise idée d’appeler des variables ‘and’, ‘or’ ou ‘not’, donc …
• Le LazyObject. Ceux qui utilisaient cette classe non documentée vont devoir modifier leur façon de l’utiliser.
• Modification de ce que contient le __dict__ dans les instances de Model : Jusqu’à présent le __dict__ ne contenait que les attributs qui correspondaient au champ du modèle. Maintenant il contient un attribut _state qui sert à gérer les db multiple. Ceux qui itere sur le __dict__ de Model devront faire attention à filtrer le _state
• les fonction get_db_prep_* des Fields ont changé de signature (et il y en a 2 de plus get_db_prep_save et get_prep_lookup )
• du fait de l’utilisation du cache loader, il faut bien vérifier que les templates tags utilisés sont bien thread-safe (je sais pas pourquoi je sens que ce point là va être le point de départ de dizaines de touffes de cheveux de geeks arrachées).
• Code de retour du lanceur de test : Le code de retour du lanceur de test ne correspond plus au nombre de test raté. C’est maintenant 0 si aucun test n’a merdé, 1 si il y a eu des merdes.

3- Conclusion

Que du bon dans cette nouvelle version donc. Et en plus pas spécialement beaucoup de modifications à faire pour profiter des nouvelles améliorations. Vivement le 9 mars que la stable sorte quoi. 🙂