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!)

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.

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

Après avoir passé quelques heures à farfouiller dans la doc et à faire quelques tests, je me suis dit qu’il n’y avait pas de raisons que je garde mes découvertes pour moi.

Voici donc un premier billet pour partager les plus utiles avec vous.

list_display, comment changer l’entête d’une colonne fonction.

On sait tous comment configurer les colonnes que l’on va afficher dans la vue en liste des content_type. En utilisant list_display. Mais est ce que cela ne vous ai jamais arrivé de vouloir afficher le résultat d’une fonction ?

Aucun problème, il suffit de mettre le nom de la fonction dans list_display. Oui c’est vrai, sauf que.. sauf que l’entête de colonne c’est le nom de la fonction.. Et ça, ce n’est pas très joli.

Sauf que, sauf que django pense à tout. Pour pouvoir afficher un intitulé de colonne sympa au lieu du nom de la fonction, il suffit de rajouter à votre fonction un attribut short_description qui contiendra l’intitulé voulu.

Un petit exemple :

list_display, comment utiliser du HTML dans les colonnes .

De même, il se peut que votre super fonction qui tue, renvoie non pas une valeur simple (genre un nombre) mais du code html (que vous aurez bien entendu généré avec un template). Sauf que là, oh rage, oh désespoir. Vous avez beau faire tout les mark_safe du monde, rien n’y fait. Votre code est escaped…

Comment modifier ça ? La encore, ça passe par un attribut de fonction, allow_tags qu’il vous suffira de mettre à True. Et miracle, ça fonctionne.

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 ..:) ) .

Les Congs en quelques chiffres :

• 11 conférences le matin
• 12 slots de barcamp l’après-midi
• 1 app releasée durant les Congs
• 1 doc de bonne pratique lancée
• 75 personnes le samedi matin dans l’amphi, à écouter les conférences (un peu moins le dimanche matin, après la soirée arrosée, parce que comme là dit un illustre inconnu : ‘ce matin, on a 50% de perte)
• 3 repas complétement pris en charge par l’organisation
• un peu plus de 100 dosettes de Senseo utilisés sur les deux jours (mais qu’une dizaine de sachet de thé, on le sait tous, le café est supérieur au thé)
• 200 litres d’eau bus, au bas mot, parce que dans le sud, il fait chaud, Cong !
• Quelques bonnes dizaines de coup de soleil, cadeau surprise pour ceux qui n’ont pas l’habitude du vrai soleil du vrai sud.
• 36 litres de bières (edit : j’avais oublié les 6litres de guinness) et 20 litres de vin bu lors des 6h qu’à durer la soirée du samedi soir. Et pourtant tout le monde est rentré sur ses jambes.
• Un nombre de kilo de paella engloutis par nos estomacs,  qui fait juste peur. Comme quoi les poneys, ils ont bon appétit.
• un article dans Linux Magazine dans le prochain numéro.

Les Congs du point de vue d’un organisateur.

La deuxième édition fut l’occasion d’essayer d’être plus pro dans l’organisation des choses. Et je pense qu’on a fait plus qu’essayer.

• Plus de salles dont un amphi bien équipé niveau son (Merci encore à l’école centrale de Marseille nous avoir accueilli pendant ces deux jours).
• Plus de préparation au niveau des repas. On a remplacé les réservations dans de multiples restos par des plateaux repas et des sandwitch livrés sur site, pour gagner du temps et permettre de continuer en mangeant les discussions entamées pendant les confs.
• Une vrai préparation pour la soirée du samedi (à la Boate) et pas juste un ‘on va sur le vieux port et on trouve un resto comme l’année dernière).
• Quelques choix un peu clivant comme des durées de conf courtes ou du #Nowificonf pendant une partie des Congs.
• Moins de trajet dans ma voiture pour chercher les gens perdus ou les ramener. Marseille commence à priori à être connu de tous et il n’y a plus de femme enceinte parmi les présentes .
• Encore plein de points à parfaire ou à juste faire (comme prévoir l’impression des badges en avance et les donner le premier matin, à l’arrivée. Ou prévoir un vrai carnet de route de l’accompagnant avec activités et truc à faire pour ne pas lâcher les gens comme ça et qu’ils s’ennuient pendant deux jours).

Les congs d’un point de vue perso.

Vivement la troisième édition. Comme les deux premières fois, la fin des Congs arrivant, un grand sentiment de vide se fait sentir et à peine le dimanche soir arrivé, l’envie d’être déjà à l’année prochaine, de pouvoir discuter à nouveau en IRL avec des gens que je ne vois parfois qu’une fois par an.
D’un point de vue perso, l’année dernière avait été une grande claque technique dans ma figure. Deux jours de conférences non stop, ça en met plein les mirettes.
Cette année, malgré le fait qu’il y est moins de conférences ce fut encore mieux. Les confs auxquelles j’ai pu assister m’ont en effet fait découvrir plein d’outil qu’il va falloir que je test, mais les barcamps ont permis d’échanger pour de vrai, de commencer même pour certaines sessions à poser les premières pierres de quelques choses (je pense là a Geek sans Frontière par exemple).

Mais ce n’est pas tout. L’un des points qui fait que cette deuxième édition fut immensément mieux que la première c’est que cette année la partie ‘non technique’ a été pensée et organisée. Et autant sur des découvertes techniques, on peut imaginer les faire par IRC / billets de blog, autant rencontrer les gens et se rendre compte qu’on les apprécie, pour de vrai, hé ben, y a pas à dire, il faut être dans la même pièce.

On mange difficilement de la barbe à papa rose sur IRC. Apprendre le GO, c’est aussi un peu compliqué. Et je ne parlerais même pas de jouer à ‘il était une fois’ avec Kael, Cyberj et Exirel. Ou de tenter de survivre à une partie de Pandémie. Et comme ArmagnacOverIP n’existe pas encore, on a encore besoin que dzen ramène sa bouteille dans son sac pour y gouter (je ne t’oublie pas brutasse, ta chartreuse était très bonne aussi:) ). C’est tout ces moments là. Tout ces moments partagés qui font que pour de vrai, DjangoCong 2.0, putaing, c’était terrible.

Et à l’année prochaine, pour d’autre aventure et une djangoCong 3.0

quelques liens :

• le convore des articles de blog qui parlent des Congs
• le convore des slides des confs
• le groupe djangofr sur linkedin
• l’etherpad de debrief collaboratif

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.

Mais comment faire pour masquer d’autre champs ? Comme des champs de KEY d’API ou de password divers ? Parce qu’après tout, il peut arriver de devoir en stocker, et de vouloir les cacher à certains des yeux qui pourraient voir la vue de DEBUG.

He ben, encore une fois, django a tout prévu. Il suffit en effet que le nom de votre constante contienne soit :

• SECRET
• PASSWORD
• PROFANITIES_LIST
• SIGNATURE

Pour que dans les vues de DEBUG, leur valeur soit remplacé par des ***

Et bien entendu, cela marche aussi pour les key des dictionnaires que vous pourriez déclarer dans vos settings (l’exemple parfait étant celui qui sert de configuration pour les BD).

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.

L’argument through permet d’avoir une table explicitement déclaré que l’on peut donc manipuler avec l’ORM.

Mais si on utilise la méthode commune, celle où c’est django qui fait tout, on pourrait avoir l’impression que l’on a alors, plus accès à cette table de jointure. Ce n’est pas utile allez vous me dire, on s’en fout, la seule info que l’on manque c’est la pk des tuples.

C’est vrai dans la plupart des cas. Mais comment faire si vous veniez à avoir besoin de pouvoir mettre la main sur ces PK ? Si par exemple vous voulez synchroniser des choses ??

Et bien, les choses sont bien faites en django. Il existe en effet une données membres through qui permet de récupérer la table créer automatiquement dans django.

Un petit exemple (en reprenant celui de django)

pour avoir accés à la table qui relie les Pizza au Topping il suffit de faire :

et donc pour filter il suffit de faire :

Et voilà.