Ça sera bien la première fois que je ne fais pas de jeux de mots dans le titre d’un billet la Django-app du mois. Mais là, je n’ai vraiment pas d’inspiration et comme je suis sur un timing plutôt serré (le billet devant être publié d’ici au plus tard 4h20 pour pouvoir prétendre à être un billet de novembre), je ne vais pas trop attendre qu’elle n’arrive. Je me rattraperai le mois prochain (je pense parler de piston le mois prochain, tout un poème…).
Django-ROA donc, cette jolie app est développée par David Larlet que j’ai déjà cité dans mes précédents billets. Il permet de gérer des ressources distantes normalement accessibles en REST, en passant à travers l’ORM de django (et donc les modèles Django).
Et oui, ça permet, d’une façon plus que facile de faire comme si des modèles distants étaient des modèles locaux.
Le petit schéma suivant (que j’ai très vilainement récupéré du site de David, sur le billet parlant de Django-ROA) explique tout, bien mieux que ne le ferraient mille de mes mots.
Bien entendu, on est pas obligé de se limiter à faire communiquer notre Django à un autre Django distant. On peut se connecter à tout ce qui a une interface HTTP. Op timeline de Twitter, Op n’importe quelle BD discutant le HTTP…
Je vois à vos sourires béats que vous êtes en train de comprendre combien Django-ROA peut être utile. Et vous avez raison.
1- Où on le trouve, comment on l’installe, tout ça quoi ?
Alors on le trouve sur la page bitbucket qui lui est consacré. Pour l’installation, il y a deux possibilités :
- soit avec hg et op on récupère la dernière version des sources
- soit avec easy_install
Attention toutefois, le package easy_install contient une version du trunk Django 1.2. Si vous ne voulez pas l’utiliser, il faudra penser à supprimer le répertoire en question.
Dans les deux cas Django-roa vient avec une version de restkit et une version de Django-piston. Si vous avez déjà ces deux librairies là, là aussi il faudra penser à faire le nettoyage.
Enfin, c’est important, si vous êtes en Django < trunk, il vous faudra patcher votre Django pour pouvoir utiliser les many to many en distant. Si vous êtes en Django SVN, il vous faudra attendre que David ait rendu Django-ROA compatible Django 1.2 (c’est peut-être déjà le cas d’ailleurs).
2- Niveau documentation
Il y a le wiki du bitbucket ainsi que l’article du blog de David dont j’ai déjà donné le lien (mais je le redonne pour les étourdis). Il y a également le code source des tests, qui permet de bien comprendre comment tout fonctionne. Et je vous recommande vraiment de lire le code des tests si vous voulez comprendre.
3- Qu’est-ce qu’on fait et comment on le fait ?
Qu’est-ce qu’on fait, je vous l’ai déjà dit. Faut suivre un peu. On connecte notre Django à notre Django (ou d’autre base distante, voir l’exemple avec Twitter). Mais ce qu’il faut savoir c’est que Django-ROA permet de gérer la partie serveur et la partie client, dans le cas où vous développez vous même la partie ‘Django distante’.
Maintenant Django-ROA est encore en dev, et il peut être utile de connaître quelques petits tuyaux, que bien entendu, je vais vous donner.
4- Les tuyaux de Jmad…
4.1- Erreur 500 côté serveur
Sur la partie serveur, il se peut que vous vous trouviez avec des erreurs 500 assez silencieuses. C’est moi ce que j’ai eu. Il se trouve que c’est dû au logging.debug et à un problème (allez savoir pourquoi) d’encodage UTF-8. Enlevez les logging et tout roule. Je n’ai pas eu le temps de chercher et faire remonter à David le pourquoi du comment de ce problème, mais comme je me suis creusé la tête quelques temps avant de trouver le problème, je préfère vous informer.
4.2- Sérialisation…
Par défaut, on peut sérialiser les objets de trois façons :
- en JSON,
- en XML,
- en utilisant le sérialiseur fait par David pour les tests qui est un sérialiseur XML un peu modifié.
Allez savoir pourquoi, mais pour moi, seul le troisième daignait fonctionner.
4.3- Authentification
Pour l’instant l’authentification sur les services distants n’est pas gérée. Si vous en avez absolument besoin, n’hésitez pas à envoyer un mail à David.
5- Conclusion
Django-ROA est encore un module en dev, il manque quelques fonctionnalités qui pourraient le faire passer du statut d’app intéressante et utile à celui d’app complétement indispensable. Mais il est d’ors est déjà bien utile, quand des problématiques de communication entre bases distantes se mettent à apparaître.
Il me semble juste que l’on devrait changer son nom, pour par exemple Django-CROA. Ça m’aurait permis d’avoir un bien meilleur titre du genre Django-CROA et le crapaud est en toi, ou alors Django-CROA , l’app qui voulait devenir aussi grosse qu’un bœuf…) enfin, tant pis.