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

Deux possibilités pour le trouver, sur sa page github (on regrettera le choix de github et non bitbucket mais bon:) )  ou sur sa page pypi. Ce qui du coup vous permettra de l’installer de deux façon :

• un petit git clone bien de chez nous
• un simple : pip install django-ratelimit-backend

La doc est dispo sur la page readthedocs du projet. Et elle est bien fournie. Une aide à l’install, un quickstart et une section pour expliquer comment modifier le critère de limitation et une référence complète du code.

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

A empêcher les vilains méchants pas beau de crier ‘des logins ou un sort’ devant vos jolis sites webs Django. En clair, à ‘bannir’ pendant 5 minutes des IP qui auraient tentées de se logguer sur votre appli à de trop nombreuses reprises.
Les réglages de base sont :

• si tu tentes de te logguer 30 fois sans y arriver
• dans une période de moins de 5 minutes
• alors tu es bannis 5 minutes.

3- Comment ça marche ?

C’est relativement facile.
Première chose, il n’est même pas nécessaire d’ajouter l’app dans vos INSTALLED_APPS, à part si vous voulez lancer les tests (vous pourrez alors installer tox si vous voulez tester avec toutes les versions de django)

Il vous faudra par contre ajouter un backend d’authentification à savoir :  ‘ratelimitbackend.backends.RateLimitModelBackend’.

Il vous faudra de plus :

• utiliser la vue ratelimitbackend.views.login à la place de django.contrib.auth.views.login
• si vous utilisez l’admin, utiliser ratelimitbackend. admin au lieu de l’admin normal de django.
• Ajouter le middleware ratelimitbackend.middleware.RateLimitMiddleware

Vous pourrez bien entendu modifier les critères de détection de vilains. Pour cela il vous suffira d’implémenter votre propre middleware (tout est bien expliqué dans la doc, ne paniquez pas!)

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

Où est ce qu’on le trouve, sur son site web, sa page pypi et sa page github.

Pour l’installer, vous aurez plusieurs plusieurs solutions :

• un git clone tout simple
• un petit pip install en utilisant le support git de pip
• un petit easy_install ( ou pip install normal) pour avoir la dernière version stable.

Niveau démo, il existe et c’est carrément cool :

• une démo du rendu (qui sert à héberger la doc)
• une démo de la version d’administration.
• Un planet qui liste tous les blogs utilisant Zinnia

Concernant la doc, elle est vraiment super bien foutue et très complète. Installation, Configuration, Configuration avancée, extensibilité, etc etc … C’est vraiment une des meilleures docs d’application django que j’ai pu lire. Pour ne pas dire la meilleure d’ailleurs.

Cerise sur le gâteau, on peut même voir la couverture de code des tests.

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

Bon, je l’ai dit c’est un moteur de blog. Donc on a des catégories, des billets, des tags, et des flux RSS.

Mais ce n’est pas tout, Zinnia propose vraiment pas mal de petites fonctionnalités qui en font un vrai moteur de blog, qui (et je le dis sincèrement) peut imaginer concurrencer certains moteurs de blogs php très connus.

Zinnia offre par exemple :

• des url shortenners
• de la publication de tweets automatique sur publication d’article
• un moteur de recherche interne
• détection des spams avec askimet (ou autre)
• des sitemap
• des channels, un truc spécifique à Zinnia
• une extension facile, ….

Et si vous avez déjà un blog ? Genre WordPress ou Blogger ?

Et ben Zinnia offre des moulinettes d’import / export. Et ça, c’est vraiment terrible.

3- Bon et en conclusion ?

Il y a a mon sens plein de bonnes idées dans Zinnia :

• Les script d’import / export sont tout simplement un must have qui vont que l’on peut vraiment imaginer migrer un blog existant sous Zinnia.
• Les channels qui permettent de réutiliser le moteur de recherche interne (qui utilise pyparsing) pour faire des recherches parmis les articles et en sortir une partie.
• Les models qui sont bien fait, à base de classe abstract et permettent de surcharger sans difficulté les choses.
• Il utilise south ce qui doit faciliter les migrations.

A tout cela il faut ajouter le fait qu’il n’y est au final que peu de dépendances. Au niveau des apps django, il n’y a que deux dépendances obligatoires :

• django-mptt
• django-tagging

Après cela dépends des fonctionnalités que vous voulez mettre en place, mais cela reste très light et très clair. (je ne parlerais pas par exemple de pinax qui en comparaison me fait l’effet d’une usine à gaz).

Je vais donc suivre ce projet avec intérêt et même si je ne suis pas sur de passer tout de suite le mad blog en Zinnia, je vais en migrer d’autre d’ici quelques temps, ça, c’est certain.

Espérons que la django app du mois d’aout soit à l’heure…. En attendant de voir si en août, à l’heure je serais, je vous propose de découvrir cette petite django-app bien sympatique.

Mais avant un peu de contexte. Je cherche depuis quelques temps une django app pour faire de l’autocompletion. Djangopackages qui est décidément très souvent mon ami propose un tableau récapitulatif assez sympa d’un certain nombre d’app qui propose cela.

Parmi la liste, j’ai décidé de tester django-autocomplete qui me paraissait le mieux répondre à mes besoin, à savoir de l’autocomplete facile coté admin, comme coté site non admin.

Nouveauté ce mois si au niveau du billet, je vais vous présenter deux versions de l’app à savoir la version ‘officielle’ faite par tyrion et un fork fait par etienned. Pourquoi vous présentez deux versions ? Parce que la version d’etienned propose quelques améliorations visuelles intéressantes (et quelques petits refactor pas débiles).

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

Ici cela dépends de la version que vous désirez tester de django-autocomplete. Si vous voulez tester la version première de tyrion alors vous avez  deux possibilité :

• par un petit hg clone à partir de sa page bitbucket
• en utilisant easy_install ou pip.

Par contre pour la version d’etienned, pas de package, donc pas d’easy_install ou de pip, il n’y a qu’une solution, un bon vieux hg clone

Chose suffisamment rare pour qu’elle soit mis en avant, il y a une démo de la version première, que vous pourrez tester ici.

Concernant la doc, pour les deux versions, tout se trouve dans bitbucket.

• Dans la version de tyrion vous aurez droit au fichier Readme et au wiki.
• Dans la version d’etienned il n’y a que le fichier Readme qui est composé en grande partie du descriptif des addons que propose ce fork (et qui se finit par un exemple d’utilisation dans l’admin).

Est ce que c’est suffisant ? Si vous envisagez de n’utiliser l’autocomplétion que dans la partie admin, clairement oui. Sinon alors là, clairement non. Vraiment pas même. Et à vous les joies de la lecture du code source pour comprendre comment cela fonctionne (ou alors vous pouvez continuer à lire mon billet et voir comment tout cela fonctionne dans la partie 3 ).

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

Tout simplement à proposer un mécanisme d’autocomplétion sur les champs texte ou Int mais aussi  les foreignkey et les manytomany. Et qui, cerise sur le gâteau, ce veut simple au niveau de son déploiement

Et à le faire d’une façon un peu ‘magique’. On déclare seulement quels sont les models qui mettront en place l’autocomplétion et pour lesquels de leur champs. Et après tout ce fait presque tout seul (en tout cas pour la mise en place des urls qui permettent de retourner le résultat du filtrage en fonction des caractères tapés, c’est tout automatique).

3- Comment ça marche ?

C’est presque tout simple.  En tout cas si vous voulez intégrer django-autcomplete dans l’admin.

Imaginons que vous vouliez autocomplete les auteurs de bouquin dans une app de critique de livre.

Vous allez commencer par déclarer une classe qui configure votre autocomplete :

Ensuite ?

Vous déclarez simplement où vous voulez utiliser votre autocomplete. En partant du principe que votre model pour les reviews de bouquin s’appelle Reviews et que le champ pour l’autheur du bouquin s’appelle book_author cela donnera cela :

et voilà. C’est fini. Vous avez dans votre admin, un champ ForeignKey en autocomplétion. Et sans forcer.

En lisant la doc vous verrez que l’on peut faire de façon différente, spécifier le queryset sur lequel on veut limiter l’autocomplete, etc etc …

Maintenant, qu’est ce qui se passe si vous voulez mettre un peu d’autocomplétion dans votre site version pas admin ?

Hum ben là, c’est pas beaucoup plus compliqué en fait. Le problème est juste qu’il n’existe pas de doc.
Mais si vous farfouillez dans le code vous verrez qu’il existe une classe de widget (AutocompleteWidget qui se trouve dans  autocomplete.widgets qui permet de mettre en place l’autocomplétion).

Il vous suffit alors dans votre formulaire, de rajouter le paramêtre widget à votre Field et de lui passer un AutocompleteWidget (qui a lui même en paramètre le champ qui mettra en place l’autocomplétion).

Si l’on reprend l’exemple d’au dessus on pourrait avoir quelque chose ressemblant à cela :

Il y a bien évidement le widget qui va bien pour la version multiple sélection (MultipleAutocompleteWidget)

Et si l’on continue à fouiller un peu plus, dans utils, on trouvera une très sympathique autocompleteform_factory qui permet de générer un form en prenant un paramètre le Model qui va bien, un dictionnaire listant les champs implémentant l’autocomplétion
ainsi que les champs à exclure.

4 conclusion et tips.

J’ai eu quelques problèmes lors de mes tests lorsque j’ai voulu installer django-autocomplete en temps qu’app dans le répertoire de mon projet et pas dans mon pythonpath. J’avais des phénomènes bizarre de double exécution de code qui me donnais de jolies exception. Je n’ai pas vraiment réussi à comprendre le pourquoi du comment ni pourquoi en sortant simplement l’app du répertoire de mon projet cela se mettait à fonctionner parfaitement…

Pour ceux qui utilisent grappeli, je viens de voir qu’il existait un fork de django-autocomplete pour en faciliter l’intégration. Mais par contre, là, je n’ai pas du tout essayé.

Ha et pour finir, le titre est une référence un peu obscure à un film avec Jack Black:).

Ce mois-ci, enfin le mois dernier, je vais vous présenter Impostor une application que j’ai découvert au détour d’un tweet (de dzen je crois )

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

Deux possibilité pour le trouver, sa page github ou sa page django packages. Pas de page pypi, enfin pas encore, espérons qu’elle arrive vite.

Pour l’installer, pas le choix, il faut passer par github.
Un petit git clone https://github.com/samastur/Impostor.git et c’est plié.

Quand à la doc, Elle se limite au readme.rst. Mais cela suffit. Et puis le readme est bien clair. Il vous expliquera comment l’installer dans votre projet django et comment vous en servir (et puis si vous continuer à lire, je vous l’expliquerais aussi)

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

Tout simplement à se déguiser lorsque l’on se logue. D’ailleurs c’est un des meilleurs noms d’app django que j’ai pu croiser. Décrivant à la fois bien la finalité de l’app tout en étant rigolo.

Impostor vous permettra donc, si vous avez un login staff member de vous loguer en temps qu’un au tre utilisateur. Vous verrez donc l’appli comme il la voit, vous pourrez interagir avec django en étant considéré comme l’utilisateur dont vous avez prit les traits (enfin le login).

3- Comment ça marche ?

C’est tout simple.
Il suffit d’ajouter un backend d’authentification à votre application django, à savoir ‘impostor.backend.AuthBackend’

ce qui doit vous donner quelque chose ressemblant à :

 AUTHENTICATION_BACKENDS = (
 'django.contrib.auth.backends.ModelBackend',
 'impostor.backend.AuthBackend',
 )

et bien entendu il faut ajouter ‘impostor’ à vos INSTALLED_APPS

Ensuite ?

Un simple petit syncdb et c’est fini, vous allez pouvoir vous déguiser en un de vos utilisateurs. Comment ?
Au lieu de vous loguer avec votre login il vous suffira de vous loguer ainsi :

 votrelogin as leloginquevousvoulezdevenir

et de taper votre password.

Donc la deuxième django app du mois sera django-urlcrypt. Une petite précision avant d’aller plus loin, c’est une des toutes premières fois où je vais parler d’une app sans avoir fait plus que la tester sur un projet de test, sans avoir d’idée précise de où ni comment je vais l’utiliser ‘en vrai’.

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

Alors on le trouve soit sur sa page pypi soit sur sa page github.

Pour l’installation là encore, les trois moyens habituels :

• par easy_install
• pip
• un petit git clone des familles

La doc, là c’est comme l’app précédente, elle est limitée au contenu de la page de pypi ou au fichier Readme.rst.

Bon alors c’est vrai que la doc est suffisante pour comprendre comment l’app marche, mais sur une app qui est aussi ‘sensible’, une bonne lecture du code ne fait pas de mal (c’est d’ailleurs ce que j’ai fait quand j’ai commencé à faire joujou avec).

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

En fait l’app a deux utilité même si une seule est vraiment mise en avant sur la doc de l’app. La première c’est de fournir aux utilisateurs une url ressemblant à ça :  http://www.mydomain.com/r/TkNJBkNFAghDWkdFGPUAQEfcDUJfEBIREgEUFl1BQ18IQkdDUUcPSh4ADAYAWhYKHh8KHBsHEw qui les authentifiera automatiquement et qui en plus les redirigera vers l’url que vous aurez voulu.  (genre le renvoyer sur /profil ou /inbox)

L’autre fonctionnalité moins mise en avant, c’est que l’on peut encoder des infos dans l’url, dans un message qui se trouve être un dictionnaire. Alors honnêtement je ne sais pas trop encore à quoi cela peut servir, mais je trouve l’idée coolos.

3- Comment ça marche ?

C’est tout simple.

Dans une vue, on peut utiliser la fonction urlcrypt.generate_login_token qui prend en param l’utilisateur et l’url de redirect et qui génére le token qui encode le tout. Ensuite il suffit de créer l’url complète qui va bien.

Dans un template, on utilise le template tags encoded_url qui prend comme argument un user et une url de redirect.

Enfin on peut utiliser les fonctions urlcrypt.encode_token et urlcrypt.decode_token
qui permettront de crypter / décrypter un message contenu dans un dictionnaire (voir l’aide pour plus d’infos).

Au niveau des configurations possibles, on peut configurer :

• à combien de requêtes à droit un visiteur
• l’url de fallblack si l’authentification contenu dans l’url echoue
• un path vers une clé privée RSA qui permettra d’ajouter un cryptage RSA lorsque l’on génère le token.  L’utilisation de ce paramètre est très très fortement recommandé (pour rappel pour généré le clé : ssh-keygen -t rsa -f )

4- conclusion

Le mécanisme de login par url cryptée me séduit beaucoup. Mais d’un autre coté je me pose des questions au niveau sécurité. Parce que l’url, l’utilisateur il va devoir la stocker. Et qu’autant mémoriser un mot de passe, on peut le faire, autant apprendre une url…, qu’en pensez vous ?

La question de la durée de vie de l’url me semble aussi importante. J’aurais aimé avoir dans l’app un système qui permette de rendre des url obsolètes parce que trop vieilles..

Enfin concernant la deuxième méthode d’utilisation, à savoir encoder des messages dans l’url, je trouve l’idée ravissante, j’ai envie de l’utiliser mais je ne sais pas à quoi elle pourrait bien me servir. A réfléchir donc.

UPDATE:

on vient de me pointer quelques problèmes qui existent avec cette app (discussion visible ici) Apparement un des problèmes a été réglé en utilisant RSA (mais son utilisation n’est toujours pas obligatoire) mais il me semble que le hash du password est toujours utilisé dans certain cas. Ce qui n’est vraiment pas une bonne idée. En l’état l’app n’est donc pas forcément à utiliser, mais plutôt à étudier pour imaginer son propre système.

Du coup, pour marquer, le coup, je publierais deux django app du mois de mai, même si je les publie en juin.

Et pour commencer, django-countries. C’est d’ailleurs assez rigolo parce que je parlais il y a peu de moyen de gérer les pays, avec une liste de choix existantes, etc.. et op, je tombe sur django-countries.

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

Vous trouverez django-countries soit sur sa page pypi soit sur sa page bitbucket.

Pour l’installation, vous avez les trois moyens désormais classique :

• un easy_install
• un pip install
• un bon vieux hg clone

La doc elle se limite à :

• la page pypi
• le readme du repository

Sachant que dans les deux cas, le contenu est le même. Mais vu la simplicité de l’app, cela suffit amplement.

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

L’app rajoute tout simplement un nouveau type de field, le CountryField. Ce CountryField vous permettra de gérer les codes à 2 lettres internationaux qui modélisent les pays mais aussi d’afficher un petit gif du drapeau qui va bien.

Et oui, comme dans les vrais sites et tout quoi.

3- Comment ça marche ?

C’est donc vraiment tout couillon. Un field CountryField. Et des instances de fiels qui ont les données membre :

• code (le code à deux lettres)
• name (le vrai nom du pays)
• flag (le chemin vers le drapeau)

Rien de bien compliqué.

Et en plus, ce qui est bien, c’est que comme c’est une toute petite app, ça ne sera pas fatiguant du tout d’écrire ce billet.

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

Là c’est tout simple, on la trouve sur github. Et uniquement sur github. Quand à la doc elle tient toute entière dans le fichier Readme.rst qui se trouve lui aussi sur github. (et vous la trouverez aussi en docstring de l’unique classe que contient l’app).

Pour l’installation il suffit ou plutôt il faut forcément, cloner le repo github.

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

A gérer d’une manière propre les Choices que l’on peut avoir à mettre en place dans les fields Django.  Parce qu’il est vrai que la méthode normale, à base de constantes que l’on ne sait pas trop où déclarer et de tuples de tuples, me si elle fonctionne bien, n’est pas super élégante.

L’app permet donc d’encapsuler tout ça dans une belle petite classe

3- Comment ça marche ?

Bon la je vais, sans aucun remords, faire un petit copié/collé de la doc. Parce que l’explication de comment ça marche est très bien faite.

Donc en fait cela marche comme ça :

plutôt clair non ?

Et cela remplace ce code là :

Personnellement, je trouve que la notation pointée  STATES.CHOICES ou  STATES.DRAFT est bien bien plus clair que la notation précédente.

Conclusion

Une petite app qui ne fait qu’une chose mais qui le fait bien. A utiliser de partout donc. (Il ne manque juste que des tests ..:) ) .

django-generic-aggregation

Qui n’a jamais utilisé les agrégat dans Django ? C’est quand même super utile. Et qui n’a pas ralé sur le fait que zut alors… Saperlipopette même, on ne pouvait pas utiliser les agrégat sur les Generic FK ?

Et c’est là qu’arrive django-generic-aggregation. Qui permet justement de le faire.

Concernant l’installation, trois moyens :

• easy_install
• pip
• un petit git des famille grâce à github : https://github.com/coleifer/django-generic-aggregation

Quand à la doc, vous aurez droit à la page de pypi qui est aussi la page de doc de github. Bon après, il faut bien dire que l’app n’est pas super compliqué à comprendre.

Et au pire, il y a le code des tests. Une petite précision toutefois concernant la doc, la page readthedoc de l’app renvoie pour l’instant sur un 404 readthedoc (un 404 en ASCII ART d’ailleurs)

Ensuite à l’utilisation c’est tout simple, un petit exemple, tiré de la doc :

Pour la petite histoire, j’ai découvert cette app en testant django-simple-ratings une autre app du même monsieur.

django-exposure

La encore une petite app toute bête qui permet de resizer des images avant de les afficher. Les images redimensionnées sont stockées en mémoire et il y a même une gestion de cache.

La doc est présente sur packages.python.org et elle explique bien la manière de l’utiliser. Après pour vraiment comprendre, vive les sources.

Quand à l’installation, vous pourrez soit utiliser :

un petit pip install django-exposure
ou une récupération d’un tar.gz sur bitbucket
ou même un hg clone

L’utilisation en elle même est très simple. Il suffit en effet d’utiliser le filtre |resize en lui donnant trois paramêtre, Width, Height et Crop.

Crop peut prendre 5 valeurs de 0 à 5 suivant le crop que vous voulez mettre en place ( 0 étant pour un crop centré).

Pour rester dans le même sujet, je ne peux finir ce billet sans parler de django-thumbnail-works qui sert comme son nom l’indique à gérer les thumbnail. Le principe étant de là, gérer cela directement au niveau de l’ImageField. Mais je ne peux vous en dire plus, je n’ai pas eu le temps de la tester.

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

Alors on le trouve sur sa page pipy mais aussi sur sa page github.
Pour l’installation, comme souvent on à le choix entre :

• passer par pip avec un petit pip install django-mockups
• passer par easy_install
• passer par un git clone

Quand à la doc, elle est générable quand on installe le paquet sinon la page pipy (mais aussi la home page du projet) en contient une bonne partie. Elle est, en l’état, il faut bien le dire, un peu limité et d’ailleurs l’auteur le dit lui même dans la dernière partie. C’est dommage, mais en attendant une doc plus précise, il y a toujours la possibilité de lire le code.

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

A générer des données. De grosse masse de données de test générées aléatoirement pour remplir vos bases de tests et rendre vos tests plus facile.

3- Comment ça marche ?

En fait on peut utiliser django-mockups de deux façons. Soit en utilisant une ligne de commande soit en mettant un place un script qui va utiliser les classes fourni par l’app et vous permettra de faire bien plus de choses que la simple ligne de commande.
Vous pourrez entre-autre :

• définir combien de données par modèles vous voulez générer.
• décider si vous voulez générer ou pas des données de table reliés par fk ou m2m aux tables que vous configurez dans mockups, sachant que bien entendu vous pouvez décider lesquelles des fk vous voulez générer.
• Pour les m2m, choisir combien de relation vous allez vouloir créer, en pouvant utiliser un intervalle.
• Spécifier lorsque que vous voulez, au milieu de votre masse de données générées, insérer des données bien précises.

4 Conclusion

Je découvre à peine django-mockup depuis quelques jours. Mais déjà je lui vois de multiples utilisations possibles, que ce soit pour tester des algos de recherche dans une grosse masse de données ou faire des tests de charges plus réalistes qu’auparavant.

Ce mois-ci (enfin le mois dernier quoi), je vais parler d’une partie de django dont je ne parle pas assez l’admin, en vous présentant django-admin-tools.

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

Où on le trouve sur sa page bitbucket sur laquelle vous trouverez aussi tout plein de screenshoot (que je reproduis ici en partie), une mini doc et un lien vers une doc très très complète.

Quand à l’installation vous pouvez soit :

• cloner le repo puis faire un python setup.py install
• utiliser easy install : easy_install django-admin-tools
• utiliser pip : pip install django-admin-tools
• simplement mettre le repertoire admin_tools dans votre python path

Quand à la doc, elle est présente sur readthedocs.org et est vraiment très bien faite. bien fournie et claire.

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

Django-admin-tools va vous permettre de customiser votre admin django.

Vous allez pouvoir des petits dasboards en page d’accueil, personnalisable et drag and dropable et foldable. Vous allez aussi pouvoir avoir un menu horizontal et une gestion des bookmarks. Les menus pourront être constitués de sous menus, de liens finaux ou de menus construits automatiquement à partir de  la liste des app (moins celles que l’on décide d’exclure).

3- Comment ça marche ?

Dans tout les cas, il y a une config par défaut. Si on veut changer la config des dashboard ou du menu, il faut générer un module python ( qui par défaut sera celui qui donne la config par défaut), le modifier et indiquer que l’on veut l’utiliser. On peut aussi modifier le thème CSS qui sera utilisé.

Pour le menu :

• python manage.py custommenu

ou

• python manage.py custommenu somefile.py

puis :

• ADMIN_TOOLS_MENU = ‘yourproject.menu.CustomMenu’

pour le dashboard, même chose :

• python manage.py customdashboard

ou

• python manage.py customdashboard somefile.py

puis

• ADMIN_TOOLS_INDEX_DASHBOARD = ‘yourproject.dashboard.CustomIndexDashboard’

• ADMIN_TOOLS_APP_INDEX_DASHBOARD = ‘yourproject.dashboard.CustomAppIndexDashboard’

4 Conclusion

Je dois bien avouer que je pense sous utilisais l’admin django. Je suis toujours à refaire des trucs en espace non admin alors que l’admin offre pourtant des possibilités immenses, pour très peu de temps passés. La découverte de django-admin-tools me conforte dans l’idée qu’il faut que je me force à utiliser plus souvent l’interface admin. Et donc à tester de nouvelles app d’extension de l’admin.

Mais ne pas avoir de temps n’est pas une raison pour ne pas perpétuer la tradition des django apps du mois. Surtout que cela fait déjà 16 mois que je tiens, et que tout les mois, qu’il fasse chaud ou froid, que les zombies ou les ET menacent de nous éradiquer ou que le tout derniers MMO à la mode sorte sa béta, je publie un billet de présentation de django app.

Et ce mois ci, je vais vous parler d’une app que j’ai découvert il n’y a que quelques dizaines jours mais qui est bien sympathique (il est même possible que je l’utilise dans un contexte de business).

Cette App c’est donc django-easy-maps.

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

Vous trouverez django-easy-maps sur sa page bitbucket (enfin un projet qui a compris qu’il fallait utiliser mercurial parce que rien n’est mieux que mercurial).
Mais vous aurez aussi le droit à une page pypi (à l’heure ou j’écris, la version sur pypi est la 0.7).

Pour l’installation, vous avez deux méthodes :

• un petit hg clone ( hg clone https://VOTREUSER@bitbucket.org/kmike/django-easy-maps )
• un pip ou un easy_install suivant votre préférence.

La doc, elle, tient dans le fichier Readme du projet et dans les commentaires du code. Mais il faut bien avouer que vu la taille de l’app, c’est bien suffisant pour comprendre comment l’utiliser. Si vous voulez comprendre comment elle marche, la par contre, il faudra lire le code.

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

Elle sert à afficher une carte, directement tiré de google maps, qui montre une adresse.

Vous donnez l’adresse que vous voulez voir apparaître à un templatetags et au moment du rendu, vous voyez apparaître un joli composant google maps, avec zoom, déplacage de la carte possible, etc etc. Et en plus, sans avoir besoin d’API Key google ou autre. Plutôt cool nan ?

On peut de plus définir les tailles de la carte, passer un template custom ou utiliser le cache template django.

3- Comment ça marche ?

Tout d’abord il faut penser à installer geopy qui est une dépendance obligatoire. (par pip ou easy_install).

Ensuite, c’est tout simple. On commence par loader le bon templatetags :
{% load easy_maps_tags %}

et ensuite on demande l’affichage de la carte :

{% easy_map “Russia, Ekaterinburg, Mira 32″ 300 400 %}

Si on veut personnaliser, on peut, en faisant par exemple :

{% easy_map address 200 200 5 using ‘map.html’ %}

La syntaxe complète du templatetags étant :

{% easy_map < address > [ < width > < height >] [< zoom >] [using < template_name >] %}

Vu mes explications, vous pensez peut-être qu’il n’y a pas de modèles BD. En fait si. L’app stocke en effet la longitude et latitude en BD pour ne pas avoir à les recalculer à chaque fois.

4-Conclusion

Django-easy-maps est une petite app, qui fait pas forcément beaucoup de chose mais qui les fait bien. Et ça j’aime.

Une précision importante, elle fonctionne avec South, donc si vous avez mis en place South pour votre projet django, un simple ./manage.py migrate easy_maps à la place syncdb et ça roule …

5-Conclusion bis

C’est donc avec django-easy-maps que je termine cette année de django-apps du mois. J’espère que certains billets vous ont été utile et vous ont fait découvrir des apps que vous utilisez maintenant quotidiennement.

En tout cas, je vous souhaite un très bon réveillon 2010 et vous dit à l’année prochaine, en espérant que j’aurais le temps de tester l’app que j’ai prévu de vous présenter en janvier qui sera, cette fois-ci, une app d’une toute autre dimension (si j’ai le temps).

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

Alors on trouve django-mobile à la fois sur :

• sa page pypi
• sa page github.

Pour l’installer donc, un petit coup de

• easy install ou apparenté
• git clone

et le tour est joué.

La doc quand a elle, est bien fournie. Avec une description ‘théorique’, des exemples précis et une explication pour chacune des variables de configuration utilisable

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

Comme son nom l’indique, django-mobile permet d’avoir un mode de visualisation mobile pour son site django. Mais en fait, pas seulement. Il permet en fait d’avoir X modes de visualisation pour son site :  mobile, Ipad, sans image, etc ….

3- Comment ça marche ?

Django-mobile fonctionne avec le concept de ‘flavour’.
Vous commencez par définir plusieurs ‘flavour’ pour votre site, tout simplement en les listant dans votre settings.py.

Chaque flavour se défini par son nom et surtout son jeu de template propre qui sont tous rangé dans un ou des sous-répertoires ayant le nom de la flavour en question.

Ensuite il suffit de passer d’une flavour à l’autre. Pour cela deux façon soit c’est une détection automatique (pour passer en mode mobile) soit vos visiteurs peuvent passer d’une flavour à une autre. La valeur de la flavour courante sera alors stockée comme une variable de session (dont le nom est paramétrable)

Le tout fonctionne assez simplement en se basant sur :

• un middleware qui détecte automatiquement si vous venez d’un terminal mobile ou pas
• un loader qui rajoute le nom de la flavour en répertoire préfixe pour vos templates
• deux context processor qui injectent l’un le nom de la flavour courante et l’autre indique si on est en mode mobile ou pas
• un middleware qui permet de changer la flavour courante.

Django-mobile, en plus d’être simple est pas mal customisable, presque à l’excès. On peut configurer le nom du paramètre de ssion qui stockera la flavour courante choisi par vos visiteurs, le nom du paramètre GET qui permet de changer la flavour courante. On peut également désactiver la possibilité pour l’utilisateur de choisir sa flavour ou choisir si on veut rajouter un répertoire préfix de plus à tout les répertoires de flavour (pour les ranger proprement tous dans un répertoire flavour par exemple).

Que du bon donc, et une petite app à utiliser sans modération (va falloir que je pense à l’intégrer pour histoire de rolistes tiens ). Et puis en plus, j’ai même pu faire un jeu de mot dont je suis excessivement fier dans mon titre de billet…:)