Tag: Python

Django-samaritan, parce que tout le monde a le droit d’aimer Bruce Willis

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.

Titanium par l’exemple, un client twitter en dix minutes.

Bon, bien entendu mon titre est volontairement accrocheur. Et complètement mensonger. Mais il faut bien appâter le chaland un peu. Sinon, je ne serais jamais un blogueur influent.. Alors vive les titres accrocheur 🙂

Mais avant de commencer, il faut peut-être que j’explique ce que c’est que Titanium. Titanium c’est un framework assez génial (et libre) qui permet de faire du dev iphone/android en html/javascript. Histoire que ceux qui n’aiment ni l’objective-C, ni le Java puisse tout de même coder sur ces plateformes là. Histoire aussi de coder qu’une fois son appli et de la voir tourner sur les deux.

Là, vous devez être en train de vous demander : ‘Il va nous parler de dev iphone/android en js ? ‘

Et ben en fait, pas du tout.

Parce que là où Titanium est encore plus génial, c’est que l’on peut coder pour le Desktop aussi, en multiplateforme à savoir Linux, OSX et Windows. Sympa, vous aller me dire, mais bon faire toute une appli desktop en js, voilà quoi …

Oui, mais non, parce que pour le desktop, on peut coder en python (attention en python 2.5 uniquement), en ruby ou.. misère, en php. Et là, ça devient carrément miam.

Ca faisait donc plusieurs mois que j’avais envie de tester le bouzin, mais bon, j’avais déjà pas le temps de bosser sur histoiresderolistes.com alors tester un truc en plus… Et puis les tests c’est bien joli mais pour faire des Hello World! Merci.

Mais comme les vacances, ce n’est pas fait que pour travailler sur le boulot en retard, j’ai pu m’y mettre, un peu. (et puis faut avouer que le billet de @popofr13 sur le dev titanium iphone m’a boosté à écrire le mien). Restait alors le problème du Hello World. Après 30 secondes de réflexion je me suis dit que bidouiller des trucs avec twitter, ça serait rigolo. Et en plus comme c’est bien buzz word twitter, ça plaira, c’est sur.

Et c’est ainsi qu’un froid jour d’avril, une nouvelle catégorie d’article naquit sur le j-mad blog. Une catégorie dédiée aux bidouillages avec Titanium et ayant pour fil rouge le dev d’un client twitter basique (type Pino quoi). Et comme pour chaque projet, il faut un nom, j’en ai trouvé un TwittPouick. Oui je sais. Non, pas de commentaires sur le nom.

1- La genèse, installation et création du projet.

Alors c’est tout simple, pour télécharger Titanium, on va sur le site et on clique sur téléchargement.

Ensuite il n’y a qu’à décompresser l’archive et lancer l’installateur. Petite précision, il y a assez régulièrement de nouvelle version, qui sont indiqués directement dans l’interface de Titanium. Il suffit alors de relancer le cycle dl/décompression/installation.

Une fois Titanium installé et lancé, il suffit de cliquer sur New Project pour voir la fenêtre ci dessous apparaître. Rien de bien difficile à comprendre, il suffit de remplir les champs et de cliquer sur create project (N’oubliez pas de cocher en vert la petite case python tout de même).

Vous arrivez ensuite sur la fenêtre principale composé d’à gauche la liste de vos projets (sur mon screen on voit d’ailleurs mon projet twittpouick) et à droite ben la zone de droite avec un menu horizontal en haut Dashboard / Edit / Test & Package.

  • Le premier ne sert à rien, c’est simplement la liste des options en fonction de si on a un abonnement payant ou pas.
  • L’onglet Edit sert un peu plus, il permet de modifier les infos que l’on a saisit à la création du projet
  • Enfin Test & Package sera celui sur lequel vous allez passer le plus de temps, vu que c’est à partir de là que vous lancerez votre projet. (et qu’un jour quand il sera fini vous le packagerait et tout et tout)

2- Et ensuite ?

Ben ensuite, on prend son navigateur de fichier favori et on va voir ce qu’il nous à générer le tonton Titanium.
Et l’on voit ça :

Bon le fichier jquery n’est pas là de base, c’est moi qui l’est rajouté. Vous comprendrez pourquoi par la suite.

Donc il ne devrait y avoir quasiment que le fichier index.html. Qui correspond à notre fenêtre principale. Avant de partir pour de vrai dans des vrais choses rigolotes (comprendre le client twitter), on va tout de même faire un hello word. Et oui.

Ouvrez le fichier index.html et remplacez son contenu par celui-ci

<html>
    <head>
        <script type="text/python">
      def hello_python():
          return "Hello World"
        </script>
    </head>

    <body >
        <div >
            <div >Le Hello World</div>
            <button onclick="alert(hello_python())">Bouton Hello</button>
        </div>
    </body>
</html>

Allez dans Test & Package, cliquez sur Launch App, une fenêtre blanche se lance avec un bouton, cliquez sur le bouton et mirage, une fenêtre Alert javascript s’affiche avec un Hello World dedans.

Ce qui est logique, si on regarde le code au dessus. On crée une section de code python, on définit une fonction que l’on appelle sur le onclick du bouton, dans un code js donc, et on passe le retour de la fonction python (je le rappelle) en paramètre à la fonction alert js.

En fait cet exemple, bien que très simple, montre la plupart des trucs génials de Titanium.

On peut déclarer des sections de code python, directement dans les fichiers html (mais on peut le faire proprement en dehors aussi, ça sera l’objet d’un prochain billet) et on peut accéder au python du js.

Et c’est aussi valable dans l’autre sens. On peut accéder du python, à du code JS. Que ce soit accéder à des fonctions ou à des variables, que l’on peut modifier, bien entendu (à ce propos, cette page de la doc officielle explique la conversion entre les types python / javascript.

3- Et TwittPouick naquit.

Pour clore ce premier billet, déjà bien long, et justifier un peu, le titre du billet, on va faire une premier truc, c’est récupérer, après clic sur un bouton, sa timeline, dans un mode code grouirk, parce que c’est juste pour finir en beauté ce billet.

3.1 Récupération de sa timeline.

Je ne connais pas les librairies twitter en python. Et je n’ai pas vraiment le temps de me plonger dedans pour voir laquelle est la mieux. Par contre je connais bien restkit, une librairie bien bien sympa de @benoitc et qui marche plutôt bien.

On va donc l’utiliser pour récupérer sa timeline.

3.2 Affichage de sa timeline.

On à une interface HTML. On veut modifier le dom. Moi j’aime bien jquery. Donc on va utiliser Jquery. Directement dans du code python. Et oui. Comme si on était en Js. Sauf que l’on ne pourra pas utiliser le raccourci $ , vu qu’on est en python. On va donc simplement utiliser le vrai objet JQuery.

3.3 Utilisation des API Titanium

On peut bien entendu, encore heureux, utiliser directement les API titanium qui sont en Js. Pour l’exemple, j’utilise Titanium.API.info qui permet d’afficher une chaîne de caractère dans la console.

Bon et maintenant le code, complet, du fichier index.html

<html>
    <head>
   
    <link rel="stylesheet" type="text/css" href="style.css" />
    <link rel="stylesheet" type="text/css" href="color.css" />    
   
    <script type ="text/javascript" src="jquery-1.3.2.js"></script>


    <script type="text/python">
        def getTimelineJquery():
            from restkit import Resource, BasicAuth
            from pyquery import PyQuery as pq
           
            try:
                import simplejson as json
            except ImportError:
                import json # py2.6 only
   
            class TwitterTimeline(Resource):
   
                def __init__(self, pool_instance=None, **kwargs):
                    search_url = "https://api.twitter.com/1/statuses/"
       
                    auth = BasicAuth("TwitterUserName", "TwitterPassword")
       
                    super(TwitterTimeline, self).__init__(search_url, follow_redirect=True,
                                    max_follow_redirect=10,
                                    pool_instance=pool_instance,
                                   filters=[auth],
                                    **kwargs)
       
                def get_timeline(self):
                    return self.get('home_timeline.json')
       
                def request(self, *args, **kwargs):
                    resp = super(TwitterTimeline, self).request(*args, **kwargs)
                    return json.loads(resp.body)
   
            s = TwitterTimeline()
            tl = s.get_timeline()

            for item in tl :
                element = u"""<p class="p_tweet color_p_tweet"> %s :  %s</p>""" % (item['user']['screen_name'], item['text'] )
                Titanium.API.info (element)
                jQuery("#timeline").append(element)

    </script>

    </head>
    <body class="body color_body">
         <div>
           
            <h1>Votre timeline avec TwittPouick</h1>
            <button onclick="getTimelineJquery()"> Get Timeline Jquery </button>
           
            <div id="timeline">

            </div>
        </div>
    </body>
</html>

Vous n’avez plus qu’à installer restkit (avec easy_install), pour python 2.5 N’OUBLIEZ PAS !!!, mettre jquery à coté de votre fichier index.html, mettre votre login / mot de passe twitter et puis lancer l’appli twitter.

Cliquer sur le bouton, quelque seconde après .. miracle les tweets apparaissent. Recliquez sur le bouton, les nouveaux twitts s’ajoutent en bas de liste….

Et voilà, même pas 10 minutes et déjà vous avez un début de client. Comme quoi, je ne vous avais pas tant mené en bateau que ça, dans mon titre, finalement.

4- Conclusion.

Ce premier billet, n’est qu’un premier billet. Il ne va pas très loin dans la présentation de Titanium, parce que je n’ai pas vraiment eu le temps de moi même faire plus. Vivement les prochains billets donc. Enfin, j’espère que c’est ce que vous vous dites en ce moment :).
Pour la suite, je mettrais en place un repository mercurial sur bitbucket où je déposerais les différentes étapes de la création de TwittPouick.

En attendant mon prochain billet, amusez vous bien avec Titanium.

Django-request , ne partez plus en quest de vos stats

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 :

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.

Lancement d’un side project : Histoiresderolistes.com

‘C’est l’histoire d’un mec …’ qui était rôliste.

Bon ok, c’était facile, mais je trouve que c’est une bonne façon de démarrer ce billet. Billet tout entier consacré à de l’autopromo ou plutôt à l’annonce du lancement d’un de mes side-project comme on dit.

Histoiresderolistes.com. Né d’une idée toute simple à savoir que les rôlistes, dont je suis, adorent se raconter leur vieilles histoires de joueurs, leurs souvenirs de catastrophe évitées ou de justesse, ou pas du tout, leur grand moment de rigolade. Et parfois on a envie de partager ces histoires, pas seulement avec son groupe de joueur actuel, mais avec ses anciens compagnons de parties, ou même avec d’autres rôlistes tout court.

Comme je n’ai pas trouvé un tel endroit, je me suis dit que j’allais la bâtir moi même, la petite taverne virtuelle où nous pourrions tous être barde, le temps d’une histoire.

Alors ce ne fut pas facile de venir à bout de ce projet, dont la taille est pourtant plus que petite. Pour donner une idée de la chronologie :

  • j’ai eu l’idée du site en juillet 2009, j’ai aussitôt acheté le nom de domaine
  • j’ai commencé à aligner quelques lignes de code en aout (merci les vacances), mais ayant du boulot du boulot, en retard, j’ai que très peu avancé.
  • Je m’y suis vraiment mis fin janvier/début février en essayant de trouver du temps la nuit et les week-ends.
  • le week-end de Pâques m’a permis de finaliser le tout et de faire tester à quelques chanceux (merci les gens de #djangocong et du plug).

Mais maintenant, il est en ligne, et vous pouvez aller y lire/raconter des histoires de rôlistes. Et si il est en ligne, c’est aussi grâce à ma chére et tendre qui a été la première des béta testeuses, bien qu’elle ne soit pas du tout rôliste… Le fait qu’il n’y est pas de fautes d’ortographes sur le site (ou presque pas) est par exemple complètement grâce à elle, mais ce n’est pas son seul apport, loin de là.

Et ce n’est pas qu’un ‘simple’ site où les gens soumettent des histoires. Quitte à lancer un truc, autant s’en servir comme bac à sable, pour tester des choses dont je parle dans mes billets.

Comme par exemple, l’introduction de mécanismes tirés des jeux vidéos, comme les titres et succès (qui sont ici appelés badges).

Vous pourrez donc gagner des titres (top posteur par exemple) ou des badges comme le badge du djinn narcissique ou du gobelin fanatique (liste des badges). Exactement comme dans les jeux, vous ne connaitrez pas la manière de débloquer certains badges. Parfois même, vous ne saurez même pas que les badges existent avant de les débloquer.

Ce n’est bien entendu qu’un début, j’ai plein d’autres idées (dont certaines déjà listées dans les billet du ce blog), que je mettrais en place petit à petit. En essayant, ensuite, d’analyser le retour des utilisateurs à mes ‘expériences’.

Mais déjà, la question est de savoir si h2rolistes (et il y a même un twitter et un identi.ca pour suivre les nouveautés) va trouver son public ou non…

Et bien entendu, h2rolistes c’est du 100% django.

Petit mémo concernant la syndication Django

Ce billet n’est qu’un petit mémo rapide, pour éviter que d’autre perdent comme moi du temps à chercher un problème qui n’en est pas un. Si jamais je me trompe dans mon interprétation du problème et dans la solution que j’en donne, je suis preneur d’une explication / correctif dans les commentaires.

Django embarque, dans les contrib, un petit framework pour géré la syndication. Plutôt bien foutu d’ailleurs.

Il fonctionne suivant un principe assez simple, pour chaque flux on définit une classe, ensuite on range les classes dans un dict où la clé sera le nom du flux dans l’url et la valeur, la classe, que l’on passe en paramètre à la vue qui gère l’ensemble des flux. (tout est parfaitement expliqué dans la doc, ici).

Par exemple :

from django.conf.urls.defaults import *
from myproject.feeds import LatestEntries, LatestEntriesByCategory

feeds = {
'latest': LatestEntries,
'categories': LatestEntriesByCategory,
}

urlpatterns = patterns('',
# ...
(r'^feeds/(?P<url>.*)/$', 'django.contrib.syndication.views.feed',
{'feed_dict': feeds}),
# ...
)

ici on aura donc deux urls :

  • /feeds/latest
  • /feeds/categories

On peut définir deux templates celui pour justes les titres et celui pour l’item RSS complet. Les deux templates doivent avoir pour nom :

  • KeyDict_title.html
  • KeyDict_description.html

Soit dans notre exemple :

  • latest_title.html
  • latest_description.html
  • categories_title.html
  • categories_description.html

Et tout fonctionne parfaitement dans le meilleur des mondes.

Maintenant prenant un exemple un peu plus compliqué. Imaginons deux apps django, une pour gérer un blog, une pour gérer des reviews de films.
Les deux apps vont donc mettre en place des flux RSS, logique.
Et les deux vont vouloir mettre en place le flux latest. Donc dans chaque répertoire templates des apps, il y aura un sous-répertoire feeds avec les fichiers latest_title.html et latest_description.html

Et là, patatra. Le deuxième flux (dans l’ordre des INSTALLED_APPS) va utiliser les fichiers templates du premier. Parce qu’apparement la recherche des templates pour les feeds et transversale.
Donc faut nommer de manière différentes ses flux. latestblogs et latestreviews par exemple.

Et là, miracle, ça fonctionne.

Voilà, c’est tout.

Petits tours des méthodes des querysets.

Les queryset sont une des composantes importantes de Django. Comment en effet interagir avec la BD sans eux ?

Mais est ce que cet outil si important et si souvent utilisé est si bien connu que ça ?

Parce que tout le monde connait count(), filter(), all() et exclude(). Mais qu’n est-il des autres méthodes ? Perso, je suis le premier à aller dans la doc, pour revérifier si ce que je voudrais n’existe pas déjà…

C’est le pourquoi de ce billet, lister quelques méthodes ‘à connaître’ des querysets (et puis comme ça la prochaine fois que j’aurais besoin de vérifier un truc, je pourrais le faire en lisant du français et pas de l’anglais). (Ce n’est au final qu’une redite de la page de doc qui va bien, mais ça peut servir).

1- Les méthodes qui renvoient un queryset (ou assimilés)

annotate(*args, **kwargs)

une petite méthode bien pratique, qui permet de rajouter des colonnes calculées (en utilisant les classes d’agrégat Sum,Count, etc défini par django) pour chaque objets récupérés dans le queryset.

Et ça, c’est plutôt fort. Surtout que l’on peut, bien entendu, ‘traverser’ les foreign key
L’un des exemples de la doc, montre cela en calculant pour un magasin le prix minimum et maximum des livres en vente :

Store.objects.annotate(min_price=Min('books__price'), max_price=Max('books__price'))

values(*fields) et Values_list (*fields)

Deux méthodes plus que miam.
Values retourne un ValuesQuerySet qui est en fait un queryset composé d’une liste de dictionnaires au lieu d’une liste d’instance d’objet modèle. Chaque dictionnaire représente un objet, les paire clés / valeur représentant le nom de l’attribut (la key) et la valeur de l’attribut (sa valeur).
On peut passer à values un paramètre optionnel *fields, qui permet de spécifier la liste des noms d’attribut (des strings donc) que l’on veut récupérer.
Exemple :

>>>Blog.objects.values()
[{'id': 1, 'name': 'Beatles Blog', 'tagline': 'All the latest Beatles news.'}],
>>> Blog.objects.values('id', 'name')
[{'id': 1, 'name': 'Beatles Blog'}]

Deux choses importantes à se rappeler, values ne récupère rien pour les manytomany et dans le cas des FK, la clé du dico est le nom ‘vrai’ de l’attribut dans la table (souvent avec _id donc) et la valeur, la valeur de la PK de la FK. Et comme le voit dans l’exemple, si on veut passer le nom explicite de l’attribut de la fk, on peut au choix mettre ou pas le _id, le résultat est le même.

Exemple :

>>> Entry.objects.values()
[{'blog_id: 1, 'headline': u'First Entry', ...}, ...]

>>> Entry.objects.values('blog')
[{'blog': 1}, ...]

>>> Entry.objects.values('blog_id')
[{'blog_id': 1}, ...]

values_list c’est à peu près la même chose que values, sauf que c’est une liste de tuple et pas une liste de dico. On peut en plus lui passer un paramêtre flat que l’on peut mettre à true , pour ‘aplatir’ les tuples quand l’on demande qu’un seul champ (juste coolos quand on veut une liste de pk)

>>> Entry.objects.values_list('id').order_by('id')
[(1,), (2,), (3,), ...]

>>> Entry.objects.values_list('id', flat=True).order_by('id')
[1, 2, 3, ...]

A quoi sert values et values_list ?

L’intérêt c’est qu’un ValuesQuerySet, c’est comme un queryset. Et que donc on peut utiliser toutes les méthodes des queryset dessus. Y compris refiltrer, order_by, etc etc ..

Et que dans le même temps, on peut alléger la charge, surtout si on a des gros models dont l’on ne veut utiliser que quelques champs.

defer (*fields)

Permet d’indiquer au queryset de ne pas récupérer automatiquement le contenu des champs qui sont passés en paramêtre du defer. Ca peut être utile dans le cas de gros champ texte par exemple (imaginons une vue en liste de billet de blog où l’on ne veut que les titres des billets et pas leur contenu, utiliser un defer(‘body’) pourrait être une possibilité , utiliser un values en serait une autre)

les champs deferred seront récupérés quand on les appelera explicitement. Pour annuler les defer d’un queryset, il suffit d’appeler la fonction avec None en paramêtre.

only (*fields)

C’est l’inverse du defer, on ne récupère que certains champs.

2- Les fonctions qui ne renvoient pas un queryset.

in_bulk(id_list)

Cette petite fonction bien sympa prend une liste de pk et renvoie un dico des objets qui correspondent (les clés étant les pk)

latest(field_name=None)

Renvoie le dernier objet, inséré dans la base, en se basant sur les dates et en utilisant le champ passé en paramètre (qui doit donc être un champ  date).
Si le model en question définit la Meta get_latest_by, on peut appeler latest sans argument.

Ok, cette fonction ‘ne sert à rien’ à part pour rendre plus lisible le code. Mais bon, ça ne mange pas de pain. Et l’utilisation de la Meta get_latest_by permet de ‘centraliser’ la façon de rechercher le dernier, ce qui rendra une modification plus facile.

aggregate(*args, **kwargs)

Retourne un dico des valeurs d’aggrégat calculés non pas objet par objet comme avec annotate, mais sur tout le queryset.

A vous les sommes de champ, les moyennes ou autre. Vive les rapports :).

>>> q = Blog.objects.aggregate(Count('entry'))
{'entry__count': 16}
>>> q = Blog.objects.aggregate(number_of_entries=Count('entry'))
{'number_of_entries': 16}

et comme pour annotate, on peut contrôler le nom, ici de la clé, que notre valeur calculée.

exists()

cette fonction n’existe pas encore dans django, elle sera présente dans la 1.2. Elle permet tout simplement de savoir si le queryset est vide ou pas. (oui je sais, devoir attendre la 1.2 pour avoir cette fonction.. mais bon 🙂 ).

Django-rosetta, parce que pierre qui roule n’amasse pas mousse

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.

Django-transmeta ou comment traduire son contenu sans se faire suer

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 :

class Book(models.Model):
title = models.CharField(max_length=200)
description = models.TextField()
body = models.TextField(default='')
price = models.FloatField()

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 :

class Book(models.Model):
__metaclass__ = TransMeta

title = models.CharField(max_length=200)
description = models.TextField()
body = models.TextField(default='')
price = models.FloatField()

class Meta:
translate = ('description', 'body', )

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 :

LANGUAGES = (
('es', ugettext('Español')),
('en', ugettext('English')),
)

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

CREATE TABLE "fooapp_book" (
"id" serial NOT NULL PRIMARY KEY,
"title" varchar(200) NOT NULL,
"description_en" text,
"description_es" text NOT NULL,
"body_es" text NOT NULL,
"body_en" text NOT NULL,
"price" double precision NOT NULL
)
;

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.

Ajouter ses filters perso aux filters builtins

Vu le manque de temps dont je souffre, je n’ai pas vraiment le temps d’écrire de long billet. J’espère pouvoir changer cela assez vite. Mais en attendant, une petite astuce que j’ai découvert il y a peu et que pour l’instant, je dois l’avouer, je n’utilise pas beaucoup. Mais ça peut-être utile.

Django offre deux outils merveilleux pour bosser avec ses templates, les templatetags et les filter. J’en utilise à tour de bras, sans arrêts.

Ce qu’il y a d’ennuyeux, il faut bien le dire, c’est dans le cas où l’on utilise un filter, dans tout les templates, de devoir faire, dans chaque template le {% load myfilter %}

Sachant qu’en plus si j’inclus un template A dans un autre B, le template A ‘n’hérite pas’ des filters et templatetags qui ont été déclaré dans B. Je devrais donc de nouveau dans A me refrapper les {% load ..

Pas de quoi raler plus que ça, je vous l’accorde.

Mais quand même, ce n’est pas très DRY tout ça, si on doit faire un load dans tout les templates de son appli.

Heureusement, papi Django a pensé à nous. Et il y a la possibilité de déclarer un filter comme étant un builtins. Il sera donc inclus par défaut, dans tout les templates.

Comment on fait ce petit miracle ? Rien de plus facile. Il suffit de mettre quelque part dans son code (dans l’__init__ de son app par exemple ) :

from django.template import add_to_builtins
add_to_builtins('nom_app.templatetags.nom_fichier_filter')

C’est tout de même assez facile, non ?

Par contre, je pense qu’il ne faut pas abuser de cette petite astuce, je soupçonne une diminution des perfs possible dans le cas d’une utilisation sans modération.

Unpacking de tuples dans les templates django

Il peut arriver que l’on est besoin de passer à ses templates des données sous la forme de tuple. Mais comment dans le template, récupéré les données qui sont dans le tuple ?

Question importante s’il en est.

Je vous rassure tout de suite, là réponse n’est pas ‘construire une classe qui sert à rien pour pouvoir faire instance.nom_donneée_membre. ‘

Il y en en fait deux méthodes.

Méthode 1

on peut unpack (désolé je n’ai pas trouvé de traduction françaises pour unpack) les tuples en utilisant la notation .NumeroChamp. Petit exemple :

tuples = [ ( foo, barr, tut ) , ( a , b , c ) , ( x, y , z ) ]

{% for tuple in tuples %}
    {{ tuple.0 }} {{ tuple.1}} {{ tuple.2 }}
{% endfor %}

C’est déjà pas mal, mais c’est peu lisible. Il y a donc mieux, la méthode 2.

Méthode 2

Celle ci permet d’unpack directement vos tuples dans la boucle for, en donnant un nom à chaque variable. Dans ce cas là, il faut donc que chaque tuple est la même structure.

Imaginons par exemple que l’on construit des liens à la volée, avec des tuples qui contiendraient deux champ, l’url et le nom du lien, on aurait donc :

{% for url , name  in tuples %}
    <a href="{{url}} "> {{name}}</a>
{% endfor %}

Plutôt sympa non ?

Django 1.2 beta, the news

Comme le petit billet qui listait les nouveautés de la version alpha de django 1.2 a eu un petit succès, j’ai décidé de récidiver et de faire la même chose pour la sortie de la version beta. Ce qui sera d’ailleurs beaucoup moins fatiguant, vu qu’il y a peu de nouveautés entre l’alpha et la toute récente beta.

Pour ceux qui veulent les releases notes précises, en anglais, c’est par ici, sur le site de django.

1- Trucs obsolètes ou changés.

1.1 Le lanceur de test

Le lanceur de test passe dans un modèle class-based. L’ancien style fonctionne encore mais il faut penser à passer dans le nouveau style.

1.2 La Syndication

La classe qui Feed qui gère les feeds a été modifiée (mais elle garde le même nom) et en plus elle change de package. De django.contrib.syndication.feeds.Feed elle devient django.contrib.syndication.views.Feed. L’api du truc ne change pas vraiment, mais maintenant on peut l’utiliser dans des vues.

De plus un atom:link apparaît, pour être en concordance avec les RSS best practices.

1.3 Encodage de cookies

L’ancien encodage des virgules et des points virgules bugguaient dans certain navigateur (IE par exemple..) Du coup, l’encodage a été changé.

2- Ce qui est complètement nouveau dans la beta

Tout d’abord, il faut savoir que la sortie de cette beta marque le gel des nouveautés dans la 1.2. Et non. Plus rien de nouveau. Il n’y aura plus maintenant que de la correction de bug (ma bonne dame). Mais en attendant, cette beta amène quand même quelque nouveautés.

2.1 Les permissions par objet

Ce n’est pas géré directement par le système par défaut de gestion des permissions. Mais cette beta permet maintenant à des systèmes tiers de gestion de permissions, de mettre en place un système de gestion de permissions par objet. Et ça, ça tue. (Pour être exact, ce système était déjà présent dans l’alpha mais pas documenté du tout).

2.2 Les permissions pour les anonymes.

Encore une modification du système d’authent / droit d’accés, qui permettra au système tiers de gestion d’authenfication, de gérer les droits pour les utilisateurs anonyme. Cette nouveauté permet de centraliser et d’homogénéiser les choses.

2.3 le select_related () passe à la gonflette

Peut-être grâce au pouvoir du glaive ancestral, ou peut-être juste à un gentil codeur core-team django, en tout cas, maintenant, le select_related accepte les related_name en paramètre.

3- Conclusion

Et voilà, c’est ‘déjà’ fini… Mais bon, je trouve que ça fait déjà pas mal de nouveautés (et de nouveautés utile en plus) pour une version beta. Pour la roadmap, rien n’a changé :
RC autour du 2 mars
version finale autour du 9 mars.

Il ne me reste donc plus qu’une seule chose à ajouter : Vivement le mois de mars.

je dois bien avouer que j’avais prévu d’insérer ici un proverbe concernant le mois de mars… mais malheureusement après une rapide recherche google j’ai eu le choix entre :

  • Pluie de mars ne vaut pas pisse de renard.
  • Mars qui rit malgré les averses prépare en secret le printemps
  • Au mois de mars, pluie et vent fou, sur nos gardes tenons-nous.
  • Mars en brume, mois de mai enrhume.
  • D’autre que je vais vous épargner.

Je ne finirais donc pas par un proverbe de mars. Tant pis.

petit mémo python

J’aime lire du code des autres. Enfin quand c’est du code de qualité, bien entendu. (Parce que question code bien pourri… j’ai été servi, plus qu’à mon tour, sur les différentes reprises de projets complètement à la ramasse auxquels j’ai eu la joie de participer).

Pourquoi j’aime lire du code bien écrit ?

Parce que tout simplement, j’apprend beaucoup en faisant cela. Et parfois, je découvre des ‘trucs’, que je trouve tellement élégant que je me dis ‘mais comment je pouvais faire sans’.

C’est une des raisons qui fait que je me fais assez régulièrement des sessions de lecture du code du django. La dernière remonte à .. hier soir.

Et j’y ai découvert une écriture que je trouve très élégante. C’est celle-ci :

def func(foo):
    return foo

toto = func(arg) or "bip"

A quoi sert-elle ? elle permet de remplacer le code suivant :

def func(foo):
    return foo

bar = func(None)
toto = bar if bar else "bip"

Une petite explication en bon français ? (pas forcément utile, j’en conviens, vu la simplicité de la chose, mais bon).

Imaginons que l’on veuille donner une valeur à une variable. Cette valeur peut-être soit la valeur de retour d’une fonction, soit si le code de retour est None (ou False) une chaine de caractère. Sans le petit truc avec or, on est obligé d’écrire le code que j’ai mis juste au dessus et qui utilise une variable temporaire (et un opérateur if .. else .. que je n’aime pas trop).

Voila, je suis sur que je n’ai rien appris à personne, mais bon, on ne sait jamais.