La pluie ayant décidé d’être l’invité surprise du week-end, j’ai donc une bonne excuse pour ne pas aller prendre des coups de soleil à la plage mais rester bien tranquillement sur mon clavier. Autant donc en profiter pour vous parler de l’application django du mois, j’ai nommé django-improved-inlines. Oui, je sais, elle a un nom à rallonge. Django-improved-inlines est en fait une version légèrement dopé de django-inlines (d’où le improved) qui fait elle même parti du package django-basic-apps. Oui je sais, ça commence à faire un arbre généalogique digne d’une série américaine (ou du trône de fer).

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Vous le trouverez sur sa page github. C’est d’ailleurs là que vous pourrez apprendre que cette sympathique petite app est une version modifiée de l’app inlines de django-basic-apps.

Pour l’installation deux méthodes :
directement en clonant le repository git de github
avec un petit easy_install bien de chez nous.

Attention, l’application pour fonctionner à besoin de BeautifulSoup mais l’installation par easy_install ne vous l’installera pas automatiquement. Un petit easy_install beautifulsoup sera donc de rigueur. Et oui.

Quand à la doc, elle tient dans un mouchoir de poche, à savoir le fichier readme mais au vu de la simplicité de l’app, ce n’est pas vraiment dérangeant.

2- Mais au fait, à quoi ça sert ?

En fait c’est tout simple. Cela vous permet, lorsque vous rédigez des contenus, d’insérer à l’intérieur d’autre contenu gérer par votre django. Et en les mettant en forme avec des templates spécifiques.

Imaginons par exemple que vous voulez insérez des images d’une manière simple dans un billet de blog, ou des blocks de texte ou ce que vous voulez en fait. Et cela, sans modifier le template de votre contenu principal. Et oui. Mais non, ce n’est pas de la magie.

3- Comment ça marche ?

En fait, cela marche en deux temps. Tout d’abord dans le template d’affichage de votre contenu principal, il faut déclarer et utiliser le template de django-improved-inlines, comme ceci :

Ensuite, tout va se jouer dans votre contenu, ici le body de votre post. Vous allez parsemer celui si de bouts d’xml qui seront process par BeautifulSoup et Improved-Inlines et qui seront transformés en html (grâce à un template).

L’exemple le plus simple est :

qui affichera l’objet de pk 1 qui est modélisé par la classe photo contenu dans l’app media.

Mais vous pourrez également utiliser les attributs xml suivant :
ids pour afficher plusieurs id, séparées par des virgules.
filter pour passer un filtre django
template pour choisir le template django qui sera utilisé (par défault l’app utilise inlines/app_model.html)
class qui permet de passer une class au template

ce qui donnerait :

ou encore :

4-Conclusion

Je n’ai pas encore eu l’occasion de m’amuser, ‘pour de vrai’ avec cette appli toute simple, ce n’est pas l’envie qui m’en manque parce que je pense lui trouver une foule d’application qui me faciliteront grandement la vie.
J’ai une seule petite appréhension que le process par BeautifulSoup ne ralentisse pas quelque peu le rendering des pages. Ca serait d’ailleurs un ralentissement à évaluer. En tout cas, amusez vous bien avec cette appli aussi simple, qu’utile.

Le mois de mai est toujours un mois compliqué. Normalement c’est à cause de tout ces jours fériés qui sont autant d’obstacle au travail et qui nous oblige à être tout le temps en retard en mai. Pourtant, cette année, malgré que deux des jours fériés de mai tombent un samedi et que le dernier (demain) soit un jour travaillé pour moi, la malédiction du mois de mai a encore frappé et je n’ai de temps pour rien… A croire que c’est le mois de mai lui-même qui a pour conséquence que l’on soit en retard. La malédiction sanglante du mois de mai … (tiens on pourrait faire un bon film de série B avec ça). Enfin, tout ça pour expliquer le fait que l’application du mois que j’ai choisi est une toute petite application, que je n’ai en fait pas eu l’occasion d’essayer ‘en vrai’. (et puis bon, je n’allais pas cracher sur la possibilité de faire un jeu de mot coolos en parlant d’un film que j’adore …)

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

On le trouve sur la page github qui va bien et c’est tout. Quand à la doc, elle est, elle aussi uniquement sur le github

La doc se découpe d’ailleurs entre :

• le Readme
• le Install
• les commentaires dans le code.

C’est peu vous aller me dire, mais vu que l’app fait, en tout et pour tout, moins de 200 lignes, c’est suffisant.

2- A quoi ca sert ?

A remplacer le model django.contrib.auth.models.User par un des siens, d’une façon propre. Pour aider encore plus, des models spéciaux de M2M, de OnetoOne et de FK sont fournis pour quand on voudra créer des références vers nos nouveaux users.

3- Comment ça marche ?

Il y a deux façons possibles de le faire marcher.

En l’installant puis en l’utilisant. Tout simplement.. On créé son model, on utilise la fonction get_user_model() qui est fournit avec django-samaritain (ou en utilisant directement notre model d’ailleurs). Et on utilise les spécialisations des FK,OtO et M2M.

En utilisant la méthode de Monkey Patching pour injecter à la volée le comportement de django-samaritan dans un projet existant. Cette deuxième méthode est déconseillée pour une utilisation à long terme,dixit l’auteur de l’app lui même.

3- Retour ?

Et oui, je sais, c’est un comble. Mais bon, c’est mes billets, alors je fais ce que je veux. Donc, si l’un de vous a des retours sur l’utilisation de cette app, je suis bien entendu preneur, ne vous gênez surtout pas.

Et non, vous ne rêvez pas, on est même pas le 15 avril et déjà, déjà, le billet de l’app django du mois est là. Mais bon, les rencontres django ayant lieu dans maintenant 14 jours et n’ayant pas encore commencer à préparer ma conf, même pas le premier mot (enfin si, bonjour), ce qui fait que je suis ‘dans la banade’, comme l’a fait si justement remarquer il y a peu @daks_

Donc, je préfère me ‘débarrasser’ tout de suite de l’app du mois, comme ça, ça sera au moins une chose de faite.

Ce mois-ci, je vais donc vous présenter django-request, une app pour faire des stats sur la fréquentation de votre django. Oui je sais il y a google analytics pour ça. Mais bon, on sait jamais, ça peut être utile quand même.

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

On le trouve à deux endroits :

• sur le github qui va bien
• sur les pages dédiées sur le site de son auteur.

A noter que quasiment toute la doc se trouve être sur la partie dédiée à django-request sur le site de son auteur.

Pour l’installation, facile, un git clone, un téléchargement de source ou alors pip et easy_install.

Quand à la doc, elle est vraiment très fournie et complète, permettant d’installer, de configurer, d’utiliser, la totale quoi.

2- A quoi ca sert ?

Ben à faire des stats, je l’ai déjà dit. Qui ne seront visibles que dans la partie admin.

On peut avoir de jolis graphiques concernant :

• les visiteurs uniques
• les visites basées sur des referrer différents
• les requêtes reçues par le serveur
• les requêtes venant des moteur de recherches
• les requêtes provenant du javascript
• les requêtes en SSL
• les requêtes faites par un utilisateur
• le nombre d’erreur 404
• le nombre d’erreur, toutes erreurs comprises
• le nombre d’utilisateur enregistré sur le site qui ont fait des requêtes

Par défaut les calculs seront fait pour les visiteurs uniques, les visites en fonctions des referrers et le nombre global de requêtes.

On obtient ensuite un joli petit graphique qui nous donne tout plein d’infos. Et plein de petits tableaux pour en avoir encore plus.

Et on peut même avoir, des petits templates tags pour voir les users actifs sur le site

3- Comment ça marche ?

Il suffit d’ajouter ‘request’ dans ses installed_apps et d’ajouter le middleware qui va bien. (Attention suivant les middlewares déjà installés, la position du middleware de django-request, dans le tuple des middleware est importantt, mais c’est bien expliqué dans la doc).

Ensuite, tout ce passe dans l’interface d’admin

4- Tips de chez Jmad.

Quand j’ai installé le tout avec easy_install, j’ai oublié de rajouter les chemins pour avoir les templates admins de l’app. Résultat je n’avais rien dans l’admin. Faites y attention ou alors installez request directement dans votre projet django, comme une de vos apps.

Le model Request présente un champ language qui est modélisé en bd par un varchar de 25. Avec mes tests, cette longueur était bien trop petite pour mon firefox. Du coup boum une erreur BD a base de ‘machin qui a été truncated’. J’ai passé la taille du champ à 200 pour être tranquille.

Les différents fichiers js qui sont utilisés sont bien entendu fournis. Pourtant par défaut, les templates vont utilisés ceux hostés ailleurs (sur le site web de l’auteur par exemple). N’oubliez pas de changer cette option si cela vous dérange.

C’est expliqué dans la doc, mais je le redis ici. Une fois que tout est bien configuré, pour aller voir ces stats, vous allez dans l’admin, vous cliquez sur la ligne Request de l’app Request. Là vous avez la liste de toutes les requêtes. (pas très utile là comme ça, vous me direz). Levez les yeux, en haut à droie, à coté du bouton Add Request, vous avez un bouton Overview. Et voilà, cliquez, vous avez vos stats.

Vous aimez mon titre ? Parce que moi, j’en suis super fier en fait. Et oui, il m’en faut peu. Bon donc pour la django-app du mois de février, j’avais choisi django-transmeta qui permettait de traduire facilement son contenu. Mais un site n’est pas fait que de contenu, il est aussi fait de label, de menu, de tout plein de truc qu’il faut internationaliser à coup de .po et de .mo. Ce qui est, il faut bien le dire, un poil chiant. Limite je pourrais dire, qu’à vouloir traduire tout ces mots, on pourrait bien finir par y laisser notre peau.

C’est là que django-rosetta intervient.

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Comme bien souvent, sur la page qui lui est destiné, qui est, un google code. Pour l’installation, rosetta fait dans le rustique : tar.gz ou svn checkout. Brut mais efficace.

Ensuite il suffira de rajouter django-rosetta dans les INSTALLED_APPS  et de rajouter ses urls dans l’urlpattern qui va bien. Et c’est tout, après roule ma poule (ou ma pierre, de rosette HA HA).

Pour la doc, la encore, il n’y a que la page home du google code. Mais l’app est suffisament bien faite, pour que la doc présente soit amplement suffisante.

2- Comment ça marche ?

Django-rosetta vous permet de rendre la rédaction des .po moins chiante que dans un simple gedit. Mais du coup, cela veut dire que l’application a besoin d’avoir les permissions d’écritures sur certains des fichiers de votre arborescence.

Du coup, elle n’est utilisable que de l’admin django. C’est un choix qui me semble, en fait, très logique. Et puis est ce que cela existe des gens qui n’utilisent pas du tout la partie admin de django ?

Ensuite, c’est tout simple, on a une liste des fichiers po, avec les pourcentages de traduction effectuées. On en choisit un et on se met au boulot. On peut même choisir si l’on veut afficher toute s les chaines ou que celle que l’on n’a pas encore traduite.

Allez op, deux petites images pour vous montrer le truc, parce que je suis gentil. (Et puis que je ne me suis pas trop fatigué, je reprend honteusement celles du google code officiel).

Voilà, avec cette deuxième app, j’en ai fini de parler, en tout cas pour un temps, d’internationalisation. A bientôt (dans un mois) pour de nouvelles découvertes dans le merveilleux pays des app django.

Et oui, vous ne rêvez pas, malgré le fait que le mois de février soit ridiculement court, je trouve tout de même le temps d’écrire mon billet de l’app django du mois. Comme quoi, tout arrive.

Bon il faut dire, que j’ai du coup sélectionné une app assez petite, que j’ai découvert grâce à #django-fr (merci les gars) et avec une doc très bien conçu que je vais donc pouvoir honteusement recopier en parti pour vous expliquer comment cela fonctionne.

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Sur la page qui lui est dédiée sur google code. Et pour l’installer, point de tar.gz, de easy_install ou de pip. Le seul moyen de l’installer consistera à faire un bon vieux svn checkout des familles.

Au niveau de la doc, il n’y a que la page du project home du google code. Mais par contre, elle est super bien foutue.

Rendre heureux aussi, ceux qui ne parlent pas français (personne n’est parfait ).

Django-transmeta tente de répondre à un besoin tout con, comment traduire efficacement son contenu, lorsqu’on a un site multi langue. Parmi tout les moyens imaginables pour faire cela (j’en reparlerais en fin de billet), transmeta a choisi de modifier directement les tables des modeles à contenu traduisible.

2- Comment ça marche ?

Je vais reprendre, texto, les exemples donnés par la page web de transmeta, parce qu’ils très clairs. Prenons l’exemple d’un model qui décrit un bouquin.

Tel que :

Là, rien n’est traduisible. Imaginons que l’on veuille traduire la description et le body. Rien de plus simple, le code du model devient alors :

On rajoute une metaclass et on défini dans la classe méta, les champs que l’on veut traduire.

Il faut ensuite, dans le settings.py, définir les langues que l’on veut gérer, par exemple :

Et qu’est ce que cela fait ?
Un petit manage.py sqlall va vous le dire :

apparaît ici la solution utilisé pour transmeta. Chaque champ qui est défini comme traduisible donne lieu à n champs en bd, pour n langues.

Là vous allez me dire : ‘Ok, bien cool, mais comment on fait quand on rajouter une langue ou que l’on veut faire en sorte qu’un champ existant qui n’était pas traduisible le soit ?’
Forcément, c’est prévu. Sinon, je n’aurais pas osé faire de billet. Donc il y des commandes manage.py spécial pour altérer les tables déjà existantes et permettre de rajouter soit des langues, soit des champs traduisibles.
Dernière chose, il y a tout ce qu’il faut de prévu pour pouvoir gérer ses champs dans l’admin.

3- Retour sur la méthode

Le principe de fonctionnement de transmeta implique de devoir utiliser des alter table à chaque fois que l’on veut rajouter une langue ou un champ. J’avoue que je n’ai jamais aimé les alter table sur du sql. Est ce un tort que j’ai ? Je ne sais pas.
Vous me direz que si l’on utilise pas d’alter table, on se retrouve presque les mains liées et qu’il ne reste que peu de solution, à part des grosses tables sous la forme ‘langue code’, ‘field name’, ‘trad’. Il est vrai. Mais bon, j’aime pas les alter table.

4- Retour sur le titre du billet :

Tout le monde aura compris, bien entendu, le jeux de mot. C’est une référence directe à transmeta, l’entreprise américaine qui faisait des processeurs ni ne chauffaient que très peu et qui donc n’avait pas besoin de ventilo. D’où le sans suer. C’est nul, je sais.

Oui, je sais, je devrais renouveler un peu mon stock de blagues. Parce que mettre des cong à la fin de tout et n’importe quoi, pour singer l’accent marseillais, ça commence à …. Je sais. (j’en profite pour vous rappeler que le 24 et 25 avril, il va y avoir la DjangoCong à Marseille, une super convention fr où ça va parler django, encore et encore).

Et, oui, la django-app du mois de janvier arrive vraiment sur le fil, à quelques heures du dépassement de délai. Mais faudra dire ça au crétin qui a décidé qu’une journée ça ne serait que 24h et qu’il fallait obligatoirement dormir chaque nuit, ou presque … (bordeille comment je vais faire en février moi..)

Enfin, je reste dans les délais, c’est le principal. Et pour le deuxième mois consécutif, je fais une petit entorse au principe de cette catégorie, vue que ce mois-ci, encore une fois, ce n’est pas une vrai django-app que je présente, mais un ’simple’ module python.

0- Et ça sert à quoi  ?

En fait tagcon est ‘inutile’ (donc indispensable vous allez me dire… ne niez pas, je vous ai tous entendu le dire…). Il sert simplement à faciliter l’écriture des templatetags (et surtout des templates tags à argument). On pourrait se dire que c’est assez inutile. Mais en fait, ça permet de gagner un peu de temps et de réduire d’une façon assez intéressante la taille de son code. Donc..

Un petit exemple, tiré de la doc, parce que comme me l’a fait remarquer daks (dont je conseille le blog, qui vient d’arriver dans mes RSS) , ça manque :

1- Où on le trouve, comment on l’installe, tout ça quoi ?

Alors alors, sur le github qui va bien. (une petite remarque qui a rien à voir, je préfère de loin bitbucket à github … et pas juste parce que mercurial c’est mieux que git).

Une fois qu’on a récupérer le package (par fork si on a un compte github ou avec un petit tar.gz), il y a deux façon de l’installer:

• un petit python setup.py install
• en copiant directement le fichier base.py qui se trouve dans tagcon.tagcon (dans ce cas là on pourra renommer base.py en tagcon.py).

2- La documentation.

Alors là… Il n’y a pas grand chose. Un fichier readme qui donne un petit exemple et c’est tout. Après, il vous faudra lire les tests et le fichier source directement. Ce n’est pas donc super fourni, mais d’un autre coté, vous me direz que le module est tellement simple que ça suffit. Et vous ne seriez pas loin d’avoir raison. Mais bon.

3- En conclusion

Au départ, quand j’ai découvert ce petit module (je crois que je dois, encore une fois, remercier benoitc pour cela), je n’étais vraiment pas convaincu de son utilité. Il me semblait presque inutile et puis un peu restrictif en obligeant à utiliser la fonction render (alors que j’ai plus l’habitude d’enregistrer les fichier template html avec le décorateur inclustion_tag). Mais au final, on se ren compte que ça simplifie pas mal les choses et on y prend rapidement goût.

4- dernier paragraphe complètement HS.

Ma liste de django-app à tester est loin d’être vide (avec entre autre piston, haystack,..) et ça ne risque pas de changer, vu que chaque semaine, je découvre une nouvelle app. Toutefois, j’écris ces billets avant tout pour qu’ils soient utile . Donc, si vous connaissez des app que vous adorez et que vous aimerez faire découvrir à tous. Laissez moi leur nom en commentaire et je m’efforcerais de les tester.

Je sais, je suis impardonnable, je n’ai pas fait de billet sur la django-application de décembre. Vous pourriez même rajouter que je le suis encore plus parce que décembre c’est le mois des vacances de Noël et que qui dit vacances dit temps pour écrire un billet.

Oui, mais non. Parce que faut pas croire, ça prend du temps tout ces repas de fêtes. Plein de temps. Sans compter le temps que l’on passe à arpenter les magasins (IRL ou sur le net d’ailleurs) pour trouver des cadeaux. Et sans parler du fait que comme décembre est un mois de vacances, pendant les jours de non-vacances, faut bosser encore plus pour essayer de faire autant que pendant un mois normal, mais en moins de jours.

Autant dire que non, je n’ai pas eu le temps pour la django-app du mois.

Et que vu mon emploi du temps en janvier, ça va être tendu pour le billet de celle de janvier. Mais, mais, dans ma grande mansuétude, j’ai décidé de faire un billet de django app du mois de décembre, en retard.

Et pour une fois, je ne parlerais pas de django-app, mais de middleware. Mais oui, les middleware django, vous savez, ce mécanisme génial qui permet de pluger de petit bout de code à différents niveaux de traitement des requêtes. Ce qui permet de modifier plus ou moins profondément le comportement de django au niveau de la gestion de ses entrées / sorties.

Ca permet de faire plein de trucs, et plus encore.

Aujourd’hui je parlerais de deux d’entre eux, un que j’utilise très souvent et un autre que je vais utiliser sous peu..

1- Loguer les requêtes SQL que fait django

J’ai trouvé ce tout petit middleware sur djangosnippets. Il se contente d’afficher la liste de toutes les requêtes SQL faites par django, en donnant le temps pris par leur execution.

C’est bien utile pour vérifier que ces vues ne font pas de la merde et pour tenter d’optimiser en factorisant des choses.

2- Django-maintenancemode

Celui-là, je l’ai découvert au détour d’une conversation sur #django-fr. Carrément plus pratique que la bête page html qui dit ‘en maintenance’, utile à connaître et à avoir dans sa django-boîte à outil.

Ç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.

Me revoilà donc pour le désormais presque célèbre billet mensuel de la django-app du mois. Comme d’habitude, je le fais sur le fils, limite à être en retard. Mais c’est bien normal, après tout il me faut bien un mois complet pour choisir, tester à fond et rédiger un magnifique billet concernant l’app du mois.

L’app d’octobre est donc django-tagging. Qui comme son nom l’indique sert à taguer des models.

Où on le trouve, comment on l’installe, tout ça quoi ?

On le trouve, très simplement sur google-code, sur sa page projet.  Pour l’installation, là aussi c’est du très classique :

• pip
• easy_install
• télécharger un tar.gz
• utiliser le svn de google-code

moi j’ai choisi, une fois n’est pas coutume d’utiliser easy_install.

Niveau documentation ?

Un fichier en ReStructuredText, accessible directement sur le site et présent dans les sources donne la doc et des exemples d’utilisation. Il n’est d’ailleurs par forcément à jour. Certaines fonctionnalités décrites comme étant dans la version de dev sont en fait dans la 0.3

En plus, trois petites pages sont présentes sur le wiki :

• une pour parler d’un tips d’utilisation (avec des properties)
• une pour les incompatibilité entre versions
• une pour les idées et le planning

Ils sont où les murs alors ? ( ou qu’est ce qu’on peut faire avec django-tagging)

Ok, ce titre de chapitre est surement le plus pourris de ma carrière de créateur de titre de chapitre, mais tant pis j’assume.

Le configurer

Il y a quelques possibilité de configuration, en setant des variables dans le settings.py du projet. On peut par exemple forcer à ce que les tags soient en minuscule ou donner la longueur maxi d’un tag.

L’utiliser

On peut donc taguer des instances de model. Mais bon en disant cela, j’ai rien dit. En fait on peut register des models pour pouvoir ensuite simplement rajouter des tags (ou les lister) aux instances de ces models.

On peut également passer directement par les managers de Tags, fournit par l’app, pour taguer des instances.

L’utiliser encore plus

il y a quelques fonctions utilitaires fournis avec l’app.

On pourra par exemple ( avec la fonction get_intersection_by_model) récupéré le sous-ensemble des instances contenu dans le queryset passé en paramêtre 1 qui sont tagués avec tout les tags d’une liste passé en paramêtre 2

De même avoir toutes les instances d’un models tagués par un ou plusieurs tags est possible avec la fonction get_by_model, mais aussi les unions d’instance ou les groupe d’instance ayant les même tag qu’un autre objet …

Et aussi (et presque surtout aurais-je envie de dire) la fonction calculate_cloud qui permet de calculer le nuage de tag en calculant une taille de font pour chacun des tags passé en paramètre. (l’algorithme utilisé pour le calcul est configurable, en plus)

afficher les tags

Avec 4 templatestags différent pour afficher le nuage de tag, tout les tags d’un objet, tout les objets (d’un model précis) tagués avec un tag précis, ou tout les tags qui sont reliés à un model (enfin à ses instances, vous m’avez compris)

Conclusion.

Même si la façon d’ajouter un tag peu sembler un peu alambiqué (pour pouvoir avoir des tags avec des espaces, ou avec des espaces plus des guillemets, etc .. ) , c’est vraiment une bonne app, qui ne fait qu’une chose, mais qui le fait très bien. Donc, je ne peux que conseiller son utilisation.

Tout d’abord, mes plus plates excuses à vous tous, fidèles lecteurs de mon petit espace qui attendiez avec d’abord joie, puis impatience, puis tristesse et désespoir, le billet de la django app du mois de septembre.

Alors oui, nous sommes le premier octobre et le billet de la django app de septembre n’a pas encore été posté. Oui, c’est une honte de lancer ainsi une si bonne idée et de ne pas suivre le principe même de la bonne idée de le deuxième mois. Oui, je reconnais tout cela. Mais votre honneur, je plaide coupa.. pardon innocent.

Ce n’est pas de ma faute si je n’ai pas écrit ce billet. Mon chien (comment ça je n’ai pas de chien?) a mangé mes devoi.. pardon mon cable réseau. Et puis c’est sans parler du débarquement des ET, qui a eu lieu dans mon jardin (comment ça y a pas de jardin dans mon appart?) et qui a ruiné ma pelouse.

Bon, trêve de bêtises. En fait il y a deux raisons à ce retard sur le deuxième billet djangoapp du mois (et aussi sur mon relatif silence sur ce blog). Deux raisons très simples :

• Une grosse période bien chaude au boulot, avec suffisamment de boulot pour y bosser soir et week-end.

• Le fait que la troisième occurrence du SPLLOS (le salon professionnel des logiciels libres qui aura lieu à marseille, le 13 octobre) se rapproche à grand pas (ben oui le 13 octobre) et qu’en temps que président de l’association qui l’organise (Libertis, l’association des boites qui font du libre en PACA), j’ai pas mal de truc à gérer (d’ailleurs je profite de ce billet, même si ils ne le liront jamais, pour remercier plus qu’un peu les membres de l’asso qui bossent aussi sur ce sujet, heureusement qu’on est à plusieurs sur le truc, sinon … )

Et, comme les deux points que je cite au dessus sont toujours d’actualité, le billet du mois de septembre (mais oui on est encore, presque, en septembre) sera un billet court, sur une app que beaucoup doivent connaître mais qui à l’avantage d’être suffisament petite pour être tester avec peu de temps  : J’ai nommé django-registration. Qui sert à la registration des users (désolé ça fait depuis le début du billet que je voulais le faire cet anglicisme).

1- A quoi ça sert , où on le trouve, comment on l’installe ?

1.1 Le pourquoi du comment

Utiliser django-registration c’est bien parce que cela permet de ne pas réinventer la roue et donc de ne pas perdre du temps à développer un système d’enregistrement/activation/ utilisateurs.

1.2 Où on la trouve ?

Sur bitbucket, il y a un repo avec un wiki bien sympa , ici : http://bitbucket.org/ubernostrum/django-registration/

1.3 Comment on l’installe ?

Il y a trois manière pour l’installer, par easy_install , par pypi ou avec les bonnes vieilles sources (hg cloneeeee) et un python manage setup.py.
Personnellement j’ai une préférence pour la troisième méthode, la doc étant incluses dans les sources, je trouve ça plus facile d’avoir les sources du truc que je met à jour de temps en temps.

2- Mais ça fait quoi django-registration, pour de vrai ?

Django registration met un place un système complet d’enregistrement des users.

A savoir, vous avez la vue qui gère le fait qu’un user veut s’inscrire et va remplir un joli petit formulaire.

Une fois le formulaire submit, django va créer un compte user inactif et envoyer un mail qui contiendra une clé d’activation. L’utilisateur qui vient de submit sa demande d’enregistrement verra alors ensuite apparaître une jolie page lui disant d’aller vérifier ses mails et d’activer son compte.

Truc sympa, l’app gére le fait d’interdire certains provider d’emails jetable ou l’interdiction de créer un compte avec un email déjà utilisé.

Cerise sur le gâteau, il y a même un petit script (qui utilise les commandes django) qui permettra de supprimer les comptes qui n’ont pas été activés et qui sont considérés comme expirés.

2.1 Et la localisation ?

Elle y est, dans tout plein de langues (y compris le français, bien entendu)

3- La doc ?

Bien fournie, très précise et claire, il n’y a vraiment rien à redire.

Une fois qu’on a installé l’app, on a plus rien à faire alors ?

Ben en fait si, parce qu’il n’y a aucun template de fournis, même pas à titre d’exemple. Il faut donc ‘tous’ les faire, mais c’est assez rapide. Et puis là aussi, la doc est vraiment bien faite et détaille précisément chaque variable du contexte de chaque view. Faire les templates n’est donc pas vraiment difficile.

4- En conclusion

Installez la et utilisez la.