# Django 1.0, état des lieux

Les développeurs principaux ont l'habitude de dire que la version 1.0 sortira lorsqu'elle sera prête. Alors évidemment c'est frustrant... mais louable. Faisons le tour des fonctionnalités manquantes et/ou toujours en développement. Je rappelle que chacun peut bien entendu critiquer, tester, participer, la liste de diffusion de développement est ouverte et intéressante.

Disclaimer : je ne suis pas développeur Django donc ce billet reste de l'ordre de la supposition.

## Pour la 1.0

Le plus simple et de consulter le Django Book qui est en cours d'écriture. On constate que les chapitres restants sont les formulaires et les commentaires (d'autres sont incomplets bien sûr mais c'est assez significatif). Par ailleurs, les API définies comme étant non stables sont :

- les formulaires : ils sont actuellement en cours de debug et c'est très actif sur les deux listes de diffusion (utilisateurs et développement). Le problème est que la documentation n'est pas totalement écrite, heureusement qu'on trouve des exemples simples d'utilisation par ailleurs.
- les commentaires : l'objectif est de pouvoir étendre le système de commentaires au même titre que celui des utilisateurs avec l'implémentation récente de get_profile() (une bonne documentation sur b-list, enfin toute la catégorie django est exceptionnelle !). C'est le principal frein à la refonte de ce site, je ne veux pas jouer avec le feu concernant les commentaires.
- l'authentification : à ma connaissance, l'API est maintenant stable.
- les relations génériques : il n'y a aucune indication quant à leur migration future, c'est à mon avis une bonne chose de les avoir dans le cœur du framework car elles constituent un réel avantage et devraient être mises en avant au même titre que l'interface d'administration. Ça permet de gagner énormément de temps en très peu de lignes de code.
- la sérialisation : vu l'état de la documentation c'est toujours en cours de développement. Je n'ai pas de gros besoins en AJAX pour le moment donc ça ne me dérange pas trop.
- le support d'Oracle : ce n'est pas mentionné mais il y a eu un énorme travail de réalisé et c'est actuellement en phase de debug donc ça sera normalement opérationnel pour la 1.0, c'est d'ailleurs ce qui est annoncé dans le livre. C'est vraiment une bonne nouvelle car je vais en avoir professionnellement besoin.

Conclusion, je pense que la 1.0 sortira avec le livre (soit vers début mars à mon avis). J'étais plus pessimiste lors de l'annonce de l'agenda d'écriture du livre qui était pour moi intenable mais force est de constater qu'ils tiennent le rythme ! Perfectionists with deadlines, ok.

## Le meilleur est à venir

Je ne pense pas que les branches actuellement en développement seront finalisées d'ici la version 1.0 (et c'est bien dommage mais bon il faut en garder sous le coude pour la suite). Voici celles que je trouve les plus intéressantes :

- l'héritage des modèles : c'était implémenté avant qu'il y ait l'étape « Magic Removal » et c'était vraiment pratique selon les objets manipulés. Apparemment c'est plus complexe à implémenter maintenant, toujours est-il que ça avance. C'est un des développeurs principaux qui s'occupe de la branche mais il était très occupé ces derniers temps. C'est à mon avis la branche la plus proche d'être intégrée dans la 1.0.
- l'évolution du schéma : c'est l'un des gros défauts actuels de django. Enfin pour d'autres c'est un avantage car lorsqu'on touche aux données on n'est jamais trop prudent et il vaut mieux le faire à la main. Mais ce serait tellement plus facile d'utiliser django pour modifier des tables à la volée ! C'est en cours de développement mais c'est complexe et les beta-testeurs se font rares ;-).
- le contrôle des accès : c'est aussi un défaut actuel. Les droits ne peuvent être décernés aux utilisateurs de l'interface d'administration que par type d'objet et non par instance d'objet. C'est assez réducteur mais le livre est très clair sur le but de l'interface d'administration (et il était temps) : elle sert à rendre éditable un contenu structuré par des utilisateurs de confiance. Donc ce n'est en aucun cas une alternative à une interface utilisateur classique, c'est pour les administrateurs du site (d'où le de confiance).

Ces deux dernières branches avaient été initiées lors de Google Summer of Code mais ne sont jamais arrivées à terme. Je ne sais pas s'il faut remettre en cause la qualité des développeurs ou l'ampleur de la tâche mais c'est bien dommage.

En conclusion, la 1.0 devrait arriver rapidement maintenant et c'est une bonne chose, autant du point de vue de la stabilité que de celui des décideurs se basant sur les numéros de version. Je rappelle que la version de développement est considérée comme stable pour permettre de disposer des dernières fonctionnalités sans mettre en péril les sites en production. Pouvoir arrêter le code à un instant t sera tout de même intéressant pour les gros projets de façon à être sûr que chacun travaille avec la même version du code.

[edit du 13] : j'ai doublé Jacob de quelques jours :-). N'hésitez pas à aller lire son résumé bien plus complet, commenté et surtout qui corrige certaines de mes affirmations.

### Articles peut-être en rapport

- Sortie de Django 1.0, une année de nouveautés
- ★ Astuces et bonnes pratiques Django
- Des vacances et des liens

### Commentaires

kib2 le 08/01/2007 :

Très bon récapitulatif David, et je suis tout à fait d'accord avec toi sur l'évolution du schéma notamment. Changer son modèle de façon dynamique serait pour moi un plus appréciable, tout le monde ne maîtrise pas les languages des bases de données, et il faut reconnaître que la première fois qu'on y est confronté, on a un peu peur de tout casser.
En ce qui te concerne, quel est le problème avec les commentaires ? L'implémentation m'a l'air assez souple là-dessus, tu utilises les simples freecomments, très simples à manier ou les comments beaucoup plus étendus, qui te permettent, à ton niveau, d'éviter le spam si c'est bien implémenté. Mais était-ce bien le problème de la sécurité qui te dérangeait ?
A +:
Kib²

David, biologeek le 08/01/2007 :

@Kib2 :
> En ce qui te concerne, quel est le problème avec les commentaires ?
L'API des formulaires et des commentaires va changer, ce serait dommage de développer deux fois la même chose... surtout si l'évolution du schéma n'est pas encore opérationnelle ;-).
Mais bon c'est un détail et surtout une excuse, tout part du modèle de données et des URL.

kib2 le 08/01/2007 :

Ah bon ?
Mince, est-ce que tu sais si il y aura une compatibilité ascendente ? Ca m'arrangerait de ne pas avoir à tout recoder :)

NiCoS le 09/01/2007 :

Faut vraiment que je me mette à lire le book, j'ai vraiment l'impression de passer à coté de pas mal de choses (et ça m'éviterait peut être de recoder des choses comme les commentaires par ex :-P )
C'est vrai que l'évolution de schéma serait vraiment bien - c'est pénible de tout devoir "casser" et tout relancer alors qu'on a ajouté un champ à une table... (surtout quand c'est par ex pour un avatar :-D )
D'ailleurs, je ne sais pas s'ils pourront sortir une 1.0 sans cette feature, ou alors va falloir qu'elle arrive vite après ;-)

NiCoS le 09/01/2007 :

Pour les commentaires modérés + akismet, tu as ce tuto de James :
www.b-list.org/weblog/200...

David, biologeek le 09/01/2007 :

@Kib2 : pour les formulaires, ça va être progressif mais je te conseille de lire la documentation sur les newforms : www.djangoproject.com/doc... c'est expliqué en en-tête.
@NiCoS : tant que tu n'as pas de données c'est simple, après c'est vrai qu'il faut un peu mettre les mains dans le cambouis et j'aime pas trop ça ;-)
Pour la modération je verrais ensuite oui. Mais j'y pense vu la façon dont je me fais spammer en ce moment :/.