Un Electron Libre... - Python - Django

Un mail effacé un peu vite - A mail deleted too quickly (django inside)

NiCoS — Tue, 20 May 2008 09:28:00 +0200

En consultant mes mails ce matin, en regardant mes spams, j'ai parcoucu la liste d'un oeil rapide en cliquant automatiquement sur "Supprimer tous les spams" quand mon oeil a été attiré par les mots "Parter Django Project" (ou quelque chose d'approchan). Si cette personne lit ce blog, je veux bien qu'elle me renvoit son mail sur la même adresse, je ferais plus attention sur les spams dans les jours à venir

When reading my new mails this morning, I jumped to the Spam section and clicked on "Delete all spams" button when my eye was attracted by a title looking like "Partner Django Project" (or something approaching). If the sender read this blog, I would appreciate that he sends me again the related mail on the same email adress. I would be more careful with spam mails in the following days

Edit : Merci à David pour le forward du mail en provenance de Djangogigs apparemment (tiens, je me rappelle pas m'y être inscrit...)

Lecture : Programmation Python

NiCoS — Tue, 25 Mar 2008 10:26:00 +0100

Je viens de terminer la lecture de "Programmation Python", qui possède d'ailleurs son |propre site dédié au livre|http://programmation-python.org/sections/blog|fr].

J'ai trouvé le livre très intéressant et très complet. J'ai compris beaucoup de choses vu ici et là dans des bouts de code python. Autant "Apprendre à programmer en python m'avait permis d'appréhender python et son modèle objet mais sans forcément me donner toutes les clés, autant là, j'ai l'impression d'avoir une bonne bible sous la main et d'avoir fait un grand pas (quitte à avoir trop de clés dans ma besace ).

A sa décharge et au vu de mon niveau actuel en python, y a des pans du livre qui me sont passés au dessus de la tête / que j'ai survolé, estimant que j'y reviendrais surement plus tard.

Autre petit point négatif mais inhérant à sa date de publication, c'est qu'il ne couvre que la version 2.4 de Python.Sur ce point précis, j'avais hésité avec l'achat de "Au coeur de Python" (Tome 1 et Tome 2) qui couvre python 2.5. Toutefois, en parcourant ce dernier livre, j'ai eu l'impression de parcourir un peu la documentation à la php.net où on assiste à un listing exhaustif des fonctions disponibles mais sans plus. Je trouve "Programmation Python" pour le coup plus pédagogique et mieux enrobé quitte pour certains points à ne donner que l'essentiel (et un peu plus) et des pointeurs si nécessaire.

Pour finir sur un point positif, l'aspect méthodologie (test, doctest, design pattern, etc) est très bien documentée et sera complétée dans le livre Petit guide à l'usage du développeur agile.

Bref, un livre à lire tant pour des débutants (qui se focaliseront sur la première partie du livre) ou des développeurs plus expérimentés qui se focaliseront sur la seconde partie.

Il me reste juste à trouver un éditeur de code python qui me va bien pour aller plus loin... (je veux un textmate-like pour Linux)

SPE (Stani's Python Editor) 0.8.4.c dispo sous Archlinux

NiCoS — Tue, 19 Feb 2008 23:33:00 +0100

Archlinux disposant d'une fort vieille version de SPE, je me suis décidé à mettre à jour le fichier PKGBUILD existant en partant de ce qui existait originellement et aussi du paquet spe-svn (paquet orphelin, tout comme spe jusqu'à ce soir).

Cela donne donc SPE 0.8.4.c pour Archlinux.

Pour l'installer :

yaourt -S spe

Par contre, sous Debian Testing, spe ne fonctionne pas suite à un problème de dépendances sur wxpython

Lecture : The Definitive Guide to Django: Web Development Done Right

NiCoS — Fri, 18 Jan 2008 22:05:00 +0100

Je viens de terminer la lecture du livre "The Definitive Guide to Django: Web Development Done Right",écrit par les développeurs principaux du framework python Django, à savoir Jacob Kaplan-Moss et Adrian Holovaty.

Le livre est décomposé en trois grandes parties :

Partie 1 : Présentation de l'outil
Partie 2 : Dans les entrailles de Django : présentation des modules et "sous-frameworks"
Partie 3 : Annexes avec des témoignages et de la documentation

On peut dire qu'à l'issue de la partie 1, vous êtes en mesure de jouer avec Django pour construire une application de démo, simple et sans prétention. A l'issue de la partie 2, vous l'avez bien enrichit et même déployer en production. Si vous avez réussi à intégrer/mémoriser la partie 3, vous êtes un expert Django

Ce que j'ai bien aimé :

Le livre se veut plus un guide qu'une documentation : le livre ne va pas présenter dans le détail tous les aspects de Django. Il va en présenter suffisamment pour s'en faire une idée, voir l'intérêt de tel ou tel module mais pas détailler l'option X du module Y. La documentation de référence reste celle en ligne et du coup, ils sont à voir comme étant complémentaires et non comme une version papier de la documentation officielle.
De nombreuses "bonnes pratiques" tant au niveau de Django que du développement web en général sont données au fur et à mesure du livre. J'ai plié un gros nombre de pages pour me rappeler d'intégrer plein de petits trucs dans mes projets actuels.
Si on connait rien en python, les auteurs fournissent suffisamment d'information pour comprendre la logique de l'ensemble. Globalement je trouve le livre très pédagogique.
J'ai appris plein de choses que je n'avais pas vu en parcourant la documentation officielle.

Ce que j'ai moins aimé :

La partie déploiement est un peu légère à mon goût, je m'attendais à un truc un peu plus solide - pour le coup, c'est pas top évident de déployer une appli django la première fois - surtout quand on vient des applis PHP qui sont "upload & play".

Même si certains choses du livre ont un peu bougé, je pense que ça vaut le coup de l'acheter si on veut se familiariser avec Django. Le livre est également lisible en ligne sur le site djangobook.com. Il paraitrait même que des gens ont proposé de le traduire en français

Djangoseries du moment

NiCoS — Tue, 11 Dec 2007 22:40:00 +0100

Le livre "The Definitive Guide to Django: Web Development Done Right", rédigé par deux des principaux contributeurs au framework django est sorti. Je l'ai commandé, j'ai pas su/pu résister
Blogmarker, une application de blog en django et qui a l'air pas mal du tout... si vous l'utilisez pas en tant que tel, le code doit pouvoir être source d'inspiration
Django Basic Apps,un ensemble d'applications basiques (blog, collection, lieu, etc) sont mises à disposition. Toujours utile en tant que tel ou pour leur code
django-registration et template-utils viennent de passer en 0.4. Parmi les nouveautés, le plus intéressant est l'inclusion de FeeeParser dans template_utils...
Discussion sur la liste des fonctionnalités de Django 1.0 - Miam
Pour appréhender newforms, rien de tel que ce billet en trois parties de James Bennett : Partie 1, Partie 2, Partie 3
et sans oublier django-profiles ou encore le code du blog de James Bennett qui peuvent être intéressant

Y a eu pas mal de choses d'intéressant ces derniers temps sur Django, c'était un "morceau choisi". Tout le reste est sur mon tag "django" sur del.icio.us...

Django : activer l'autocomplétion dans votre console

NiCoS — Fri, 30 Nov 2007 19:09:00 +0100

Utilisant la version de développement (svn) de Django, j'ai farfouillé dans le contenu du répertoire extras de django et on y trouve un symathique fichier django_bash_completion.

Il vous suffit de placer ce fichier dans /etc/bash_completion.d/ (ou de faire un lien symbolique, ce qui peut être pratique si le fichier est mis à jour et si vous suivez régulièrement la version de développement).

Pour profiter de cette complétion suivant votre distribution GNU/Linux et où l'autocomplétion est définie :

source /etc/profile
 
et/ou :
 
source ~/.bashrc

Ensuite, à la racine de votre projet django, faites :

python manage.py [Tab] [Tab]

et toutes les options possibles vont apparaître :

$ python manage.py
adminindex        loaddata          sqlclear          startproject
createcachetable  reset             sqlcustom         syncdb
dbshell           runfcgi           sqlflush          test
diffsettings      runserver         sqlindexes        validate
dumpdata          shell             sqlreset
flush             sql               sqlsequencereset
inspectdb         sqlall            startapp

Toujours ça de pris

Pygments et ReST (partie 2 sur je-sais-pas-combien-encore)

NiCoS — Sun, 18 Nov 2007 23:27:00 +0100

Suite de mon aventure sur Pygments et ReST :

En lisant la documentation rapide (QuickStart) de Pygments, on trouve comment récupérer la feuille de style fournit par défaut :

pygmentize -S default -f html > style.css

Ensuite, lors de la transformation Rest vers HTML, il suffit de faire :

rst2html.py source.txt cible.html --stylesheet-path=style.css

Il y a surement plus propre mais bon, ça marche... Cela veut aussi et surtout dire que pour produire un site à partir de document s au format ReST, il faut construire sa feuille de style CSS en incluant celle de pygments notamment.

Et voilà le résultat :

Voir la capture d'écran

Pygments et ReST (partie 1 sur je-sais-pas-combien-encore)

NiCoS — Sun, 18 Nov 2007 23:00:00 +0100

Dans le monde python, il y a :

Une syntaxe de documentation puissante mais pas aisée à prendre en main : ReST, pour ReStructured Text, fourni via docutils. Voir la QuickRef de ReST.
Pygments, un système de coloration syntaxique, un peu comme GeSHi en PHP.

Dans vos documents rédigés en ReST, il est possible d'inclure Pygments pour enrichir le rendu de vos documents.

Il vous faut pour cela :

docutils installé sur votre ordinateur,
pygments aussi
récupéré le fichier external/rst-directive.py présent dans le fichier source de pygments 0.9 et le copier dans /usr/lib/python2.5/site-packages/docutils/parsers/rst/directives/

Ensuite, et c'est là où le système manque un peu de flexibilité, il faut déclarer cette directive :

Editer /usr/lib/python2.5/site-packages/docutils/parsers/rst/directives/init.py (il y a deux "_" de chaque coté du init - bug de DC2 apparemment) pour ajouter une ligne :

_directive_registry = {
      'sourcecode': ('rst-directive', 'pygments_directive'),
      'attention': ('admonitions', 'Attention'),
      ...
      }

Cette déclaration dit que quand j'utiliserais la directive sourcecode dans mon document ReST, alors il doit aller utiliser la classe pygments_directive présente dans le fichier rst-directive.py.

Editer le fichier /usr/lib/python2.5/site-packages/docutils/parsers/rst/languages/en.py (et les éventuelles traductions) :

directives = {
      # language-dependent: fixed
      'sourcecode': 'sourcecode',
      'attention': 'attention',
      ...
      }

Voilà pour l'installation de pygments et docutils.

Dans votre texte au format ReST, il vous suffit d'utiliser la directive sourcecode comme dans l'exemple suivant :

Tutoriel : partie 1
===================

settings.py
-----------

.. sourcecode:: python

    # Django settings for tutoriel project.

    DEBUG = True
    TEMPLATE_DEBUG = DEBUG

    ADMINS = (
        # ('Your Name', 'your_email@domain.com'),
    )

Si vous voulez que les numéros de lignes soient également mentionnés, il vous faut décommenter la ligne suivante (dans rst-directives.py) :

et modifier votre fichier de la façon suivante (ajout de la directive :linenos: :

Tutoriel : partie 1
===================

settings.py
-----------

.. sourcecode:: python
    :linenos:

    # Django settings for tutoriel project.

    DEBUG = True
    TEMPLATE_DEBUG = DEBUG

    ADMINS = (
        # ('Your Name', 'your_email@domain.com'),
    )

Je vous fais grâce du code html de rendu, ~~surtout que pour le moment, je n'ai pas de coloration syntaxique~~ (cf Pygments et ReST Partie 2)

Django : internationaliser vos modèles dans vos applications

NiCoS — Thu, 15 Nov 2007 12:34:00 +0100

La documentation sur l'internationalisation d'une application Django m'ayant laissé perplexe tant en anglais qu'en français, voici un petit résumé de ce qu'il faut faire.

Dans settings.py, il vous faut :

Avoir un language code correctement configuré
Que USE_I18N soit bien activé - c'est le cas par défaut
Ajouter 'django.middleware.locale.LocaleMiddleware', à la liste de vos middleware. Attention l'ordre compte - cf documentation

Exemple :

[...]
 
LANGUAGE_CODE = 'fr'
 
USE_I18N = True
 
[...]
 
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.locale.LocaleMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.middleware.doc.XViewMiddleware',
)
 
[...]

Dans app/models.py :

Importer gettext_lazy fourni par django. gettext_lazy() s'utlise pour traduire les champs des modèles
Pour éviter d'écrire gettext_lazy('Single'), on peut utiliser le système d'alias pour n'écrire que : _('Single') .
Si vous êtes en unicode, c'est ugettext_lazy() et non gettext_lazy() bien sûr,

Exemple :

# -*- coding: utf-8 -*-
from django.db import models
from django.contrib.auth.models import User
from django.utils.translation import ugettext_lazy as _
 
"""
Profile
 
This object is used to provide some common information regarding the profile of a user.
"""
 
class Profile(models.Model):
    CIVILITY_CHOICES = (
         ('single', _('Single')),
         ('taken', _('Taken')),
    )
    who = models.ForeignKey(User, unique=True, verbose_name=_('Person'),)
    photo = models.ImageField(height_field="80", width_field="80", upload_to="photos", blank=True)
    street = models.CharField(_('Address 1'), maxlength=100)
    street_bis = models.CharField(_('Address 2'), maxlength=100, blank=True)
    zipcode = models.IntegerField(_('Zip code'), maxlength=5)
    city = models.CharField(_('City'), maxlength=100)
    phone = models.CharField(_('Phone'), maxlength=20)
    mobile = models.CharField(_('Mobile'), maxlength=20, blank=True)
    civility = models.CharField(_('Status'), maxlength=20, choices=CIVILITY_CHOICES)
    birthdate = models.DateField(_('Birth date'))
    children = models.IntegerField(_('Children'), blank=True, null=True)

Dans le répertoire de votre application, créer un répertoire "locale" :

mkdir -p /chemin/de/votre/projet/django/app/locale

Ensuite il vous faut générer votre fichier de langue .po correspondant à votre langue (ici : fr):

/usr/lib/python2.5/site-packages/django/bin/make-messages -l fr

Saisissez alors la traduction dans app/locale/<langue>/LC_MESSAGES/django.po

Exemple :

#: models.py:14
msgid "Single"
msgstr "Célibataire"

Compiler ensuite votre fichier de langue :

/usr/lib/python2.5/site-packages/django/bin/compile-messages

Vous obtenez alors un fichier app/locale/<langue>/LC_MESSAGES/django.mo

Dans votre template :

ajouter {% load i18n %} en tête de template

Ex :

{% extends "base.html" %}
{% load markup %}
{% load i18n %}

Si vous utilisez le serveur de développement, il faut le redémarrer pour qu'il prenne en compte les fichiers de langue compilés (idem lors d'une mise à jour des fichiers de langue).

Et voilà, savourez le travail...

Merci à benoitc et anhj de #django-fr pour m'avoir aidé à trouver mon erreur (ie avoir créer dans le répertoire de mon application une structure conf/locale au lieu de locale. La première ne s'utilise que pour l'ensemble d'un projet django).

Django : utilisation de regroup avec tri sur des clés étrangères

NiCoS — Sun, 16 Sep 2007 14:11:00 +0200

Objectif : Utilise la balise "regroup" en filtrant sur une clé étrangère

Modèle :

Soit le modèle suivant :

"""
Technicat skills
"""
 
class DomainTechSkill(models.Model):
     name = models.CharField('Domaine de compétence technique', Maxlength=100, core=True)
 
class Techskill(models.Model):
     who = models.ForeignKey(User, verbose_name='Personne',)
     name = models.CharField('Compétences techniques', maxlength=100, core=True)
     domain = models.ForeignKey(DomainTechSkill, verbose_name='Domaine de compétences techniques',)
 
class Usertechskill(models.Model):
     who = models.ForeignKey(User, verbose_name='Personne',)
     name = models.ManyToManyField(Techskill, verbose_name='Compétence technique', filter_interface=models.HORIZONTAL, blank=True)

L'idée est de faire d'une part TechSkill <=>DomainTechSkill et d'autre part User <=> TechSkill. Ensuite au niveau de la restitution, on veut lister les compétences techniques d'un utilisateur en les regroupant par "DomainTechSkill".

Vue :

avec la vue suivante (extrait) :

def cv_detail(request, firstname, lastname):
     user = User.objects.get(first_name=firstname, last_name=lastname)
     user_techskill = user.usertechskill_set.all()
     return render_to_response('cv/cv_detail.html', {'user_techskill': user_techskill, })

Template :

et le template suivant (extrait) :

                 {# -- technical skills -- #}
                 {% if user_techskill %}
                 <p>Comp&eacute;tences techniques :</p>
                 {% for techskill in user_techskill %}
                 {% regroup techskill.name.all|dictsort:"domain" by domain as grouped %}
                 <ul>
                          {% for group in grouped %}
                                 <li> {{ group.grouper }} :
                                         {% for item in group.list %}
                                                 {{ item.name }}{% if forloop.last %}.{% else %},{% endif %}
                                         {% endfor %}
                                 </li>
                          {% endfor %}
                 </ul>
                 {% endfor %}
                 {% endif %}

Jeux de données :

Imaginons que j'ai alors rentré les couples de valeur suivants (Compétence techniques / Domaine Technique) :

HTML / Web
CSS / Web
Apache / Serveur
Portail / Système d'information
Bind / Serveur
CMS / Système d'information

Ce qui est souhaité :

Serveur : Apache, Bind
Système d'information : CMS, Portail
Web : HTML, CSS

Ce qui est parfois obtenu (comme n'importe quelle autre combinaison de ces valeurs, ce qui nous permet d'avoir la bonne de temps à autre)

Serveur : Apache
Système d'information : CMS, Portail
Serveur : Bind
Web : HTML, CSS

Solution pour avoir la bonne combinaison de façon systématique :

La solution consiste dès lors à ajouter le nom de l'attribut (ex : domain.name) ou de filtrer par un id (ex : domain.id)

                 {% regroup techskill.name.all|dictsort:"domain.name" by domain as grouped %}

Et là, vous avez systématiquement le résultat souhaité (seul l'ordre des compétences peut varier sur une même ligne)

Merci à Samuel pour m'avoir indiqué cette capacité.

Django et les fixtures

NiCoS — Sat, 15 Sep 2007 09:40:00 +0200

Sauvegarder les données saisies dans une instance sous la forme de fixture :

Pour sauver toutes les données de votre projet :

python manage.py dumpdata --indent=4 > initial_data.json

Note :

le --indent=4 permet que le fichier créé soit correctement indenté et plus facile à lire.
par défaut, c'est exporté au format json
en nommant votre fichier initial_data.* il sera chargé automatiquement par django lors d'un syncdb, reste ou sqlreset

Pour sauver les données d'une application nommée "monapp" :

python manage.py dumpdata --indent=4 monapp > initial_data.json

Attention, si vous voulez opérer un changement sur votre modèle, il faut faire le dump avant de faire des modifications, sinon cela ne marche pas.

Pour charger une fixture, il suffit de faire :

python manage.py loadata ma_fixture.json

Passer de sqlite à MySQL (ou autre) en ayant des caractères accentués :

Lors du passage de Sqlite à MySQL, j'ai eu le bug suivant avec les exports en json : tous mes caractères accentués étaient transformés en caractères spéciaux. Le seul moyen fut de passer par un export xml :

python manage.py dumpdata --format=xml --indent=4 monapp > initial_data.xml

Django-fr, le site de la communauté francophone Django est (enfin) en ligne !

NiCoS — Mon, 04 Jun 2007 15:24:00 +0200

David a su profiter de sa présentation du framework python Django lors des journées francophones python (organisées par l'AFPy) pour mettre en ligne une première version du site django-fr.org.

Vous allez donc pouvoir retrouver sur ce site :

la documentation traduite dans la langue de Molière,
des liens utiles,
le code du site en lui-même (qui peut toujours servir d'exemple ou de base pour un projet perso...),
pleins de gentilles personnes via la liste et le canal irc #django-fr sur freenode.net

Content de voir que le projet sort enfin, ça donne une réalité à ce serpent de mer dont on parle depuis des mois et ça devrait (re)motiver les troupes pour finaliser les traductions et apporter peut être un peu de sang neuf...

Django - gestion des caractères accentués dans les modèles

NiCoS — Mon, 16 Apr 2007 22:13:00 +0200

Si vous avez qqc du genre :

class Skill(models.Model):
    SKILL_LEVEL_CHOICES = (
        ('beginner' : 'Débutant'),
        ('intermediate' : 'Intermédiaire'),
        ('advanced' : 'Avancé'),
    )
    ...

et que lorsque vous utilisez :

python manage.py validate

vous avez une jolie erreur du type :

mvmo.cv: Non-ASCII character '\xc3' in file /home/django/mvmo/../mvmo/cv/models.
py on line 111, but no encoding declared; see http://www.python.org/peps/pep-026
3.html for details (models.py, line 111)

Hé bien cela est du aux accents !

Pour résoudre cette erreur, il vous suffit de placer en tête de votre fichier models.py :

# -*- coding: utf-8 -*-

Vous pouvez remplacer utf-8 par un autre jeu d'encodage : latin-1, iso-8859-15, iso-8859-1, ascii, etc.

Et le tour est joué.

1ère appli django en ligne : Les Steinmetz.Net

NiCoS — Sun, 15 Apr 2007 00:05:00 +0200

C'est avec une certaine joie que j'ai le plaisir de vous annoncer que Les Steinmetz.Net a subi un rafraichissement de printemps et qu'il est surtout généré par le framework python Django, avec intégration des librairies Feedparser pour la prise en charge des flux RSS et Flickr.py pour s'interfacer avec l'API de Flickr.

Le site en tant que tel n'a pas grand chose d'intéressant mais c'était l'occasion de se faire la main. Il fallait bien une petite étape pour m'encourager à continuer à jouer avec Django. La prochaine sera MvMo, et ensuite Atome.

Un grand merci à David et à Baptiste pour leur aide, leur patience à mon égard et pour avoir répondu à mes questions !!

Pour ceux que cela intéresse, le code est là.

Django : Surcharger les urls de vos applcations

NiCoS — Sat, 03 Mar 2007 23:37:00 +0100

Il y a quelques jours, avec l'installation du dépôt de snippets "Cab", je me suis retrouvé avec un problème fort ennuyeux.

Le problème était le suivant : l'application cab a définit un certain nombre de motifs d'url non compatibles avec mon installation locale. Ainsi, mon dépot de snippets étant disponible à l'adresse http://localhost:8000/snippets/, il était tout naturel de penser avoir http://localhost:8000/snippets/languages/python pour avoir la page listant les snippets fait en python. Et bien non, l'auteur de Cab avait mis un schéma d'url différent, ce qui fait que cela me renvoyait sur http://localhost:8000/languages/python et m'affichait une belle erreur 404.

Deux solutions s'offraient alors à moi :

Modifier la fonction get_absolute_url définie dans l'application, ce que je ne voulais pas afin de pouvoir suivre les évolutions de Cab
Avoir une autre solution.

Pensant que c'était un bug, j'avais remonté l'info à l'auteur de l'application. Ce dernier l'a considéré comme un bug qu'il ne corrigera pas mais m'a dit que je pouvais soit modifier la valeur de la fonction, soit utiliser ABSOLUTE_URL_OVERRIDES.

J'ai donc consulté la documentation sur ABSOLUTE_URL_OVERRIDES. Cela explique qu'on peut simplement modifier la valeur de get_absolute_url en donnant les nouvelles valeurs à utiliser. Génial ! Je rajoute donc dans mon fichier snippets/settings.py :

ABSOLUTE_URL_OVERRIDES = {
    'cab.Language' : lambda o: "/snippets/languages/%s/" % o.slug,
}

Pour rappel, la fonction initale get_absolute_url de ma classe "Language" de l'application cab (ce qui explique le "cab.Language") est :

    def get_absolute_url(self):
        return "/languages/%s/" % self.slug

Suite à ce changement, lorsque j'utilise la fonction get_absolute_url de ma classe Language, je ne suis plus sensé avoir /languages/python mais /snippets/languages/python.

Sauvé ! me dis-je. Et non, raté !

Un petit bug sur la version de développement fait qu'en fait il faut mettre le nom de la classe en minuscule (voir ticket #3646), ce qui me donne donc pour le moment :

ABSOLUTE_URL_OVERRIDES = {
    'cab.language' : lambda o: "/snippets/languages/%s/" % o.slug,
}

Mais bon, maintenant ça marche

Django : Installer "Cab", le gestionnaire de snippets made by django

NiCoS — Tue, 27 Feb 2007 06:30:00 +0100

C'est assez simple :

Créer un projet django (attention, il vous faut une version svn de django pour profiter de newforms absent de la version 0.95.* ; pour l'installation, voir la documentation officielle ou mon billet à ce sujet) :

django-admin.py startproject snippets

Récupérez la dernière version de Cab :

svn checkout http://cab.googlecode.com/svn/trunk/ snippets/cab

Récupérez la dernière version de Django-Registration qui gère la partie authentification de Cab :

svn checkout http://django-registration.googlecode.com/svn/trunk/ snippets/registration

Récupérez la dernière version de markdown et installez la :

unzip markdown-1.6a.zip
cd markdown-1.6a
sudo python setup.py install

Récupérez et installer la dernière version de Pygments :

tar xzf Pygments-0.7.1.tar.gz
cd  Pygments-0.7.1/
sudo python setup.py install

Editez snippets/settings.py au niveau de la base de données, le fuseau horaire (Europe/Paris) et la langue (fr-fr) et ajoutez "snippets.cab", "snippets.django-registration" et "django.contrib.admin" (pour bénéficier de l'interface d'admin de django), ainsi que "django.contrib.comments", "django.contrib.feeds" et "django.contrib.markup" dans la liste des applications installées :

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'snippets.cab',
    'snippets.registration',
    'django.contrib.admin',
    'django.contrib.comments',
    'django.contrib.markup',
    'django.contrib.syndication',
)

Créer votre base de données :

python manage syncdb

Editez ensuite snippets/urls.py pour ajouter que toutes les urls en /snippets/ soient utilisées par "cab" et /accounts/ par "django-registration" et décommentez la ligne de l'interface d'admin :

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    # Example:
    # (r'^snippets/', include('snippets.foo.urls')),

    # Uncomment this for admin:
    (r'^admin/', include('django.contrib.admin.urls')),
    (r'^snippets/', include('snippets.cab.urls')),
    (r'^accounts/', include('snippets.registration.urls')),
)

Créez un répertoire snippets/templates et éditez snippets/settings.py pour avoir :

TEMPLATE_DIRS = (
    # Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
    # Always use forward slashes, even on Windows.
    # Don't forget to use absolute paths, not relative paths.
    "./templates"
)

Créez un fichier snippets/templates/base.html et snippets/templates/base_user.html pour avoir un premier rendu (moche) :

<html>
<head>
<title>{% block title %} {% endblock %}</title>
</head>
<body>
{% block content_header %} {% endblock %}

{% block main_content %} {% endblock %}
</body>
</html>

Lancer le serveur embarqué :

python manage.py runserver

et rendez-vous sur :

Pour les autres urls à tester/voir, jetez un oeil à snippets/cab/urls.py et snippets/registration/urls.py

A l'heure où j'écris, il vous faudra créer pas mal de templates spécifiques requis par "cab" ou "django-registration". J'ai fait la demande d'un template complet par défaut, j'espère être entendu...

Edit : pour le moment, je ne suis pas entendu - faudra monter son template soi-même...

Edit2 : Ajout de django.contrib.comments & django.contrib.markup dans les applications à installer et du template base_user.html (copie de base.html)

Edit3 : Ajout de "django.contrib.syndication" dans les applications à installer

Djangoseries du matin...

NiCoS — Mon, 26 Feb 2007 08:42:00 +0100

Pour celles et ceux qui voudraient un dépôt de code (snippets) un peu comme les snippets de Symfony ou "Les petits bouts de code à Niko" mais en Django en lieu et place de Symfony, ils vont être ravis de l'annonce de la sortie de Django Snippets et du logiciel servant à faire tourner ce dépôt : Cab.

Toujours au passage, le module d'authentification a été sorti du projet cab et peut donc être réutilisé à outrance : Django-Registration.

Sinon, la version 0.96 avec notamment les newforms et le framework de test devrait sortir d'ici peu.

Django et les vues génériques : petit exemple de filtrage de contenu.

NiCoS — Thu, 18 Jan 2007 22:24:00 +0100

Il y a un truc que je trouve bien dans Django, ce sont les vues génériques. Ce sont des fonctions qui permettent d'afficher une liste ou le détail d'objets de façon très simple, sans avoir à coder quoi que ce soit.

Cependant, elles ont un petit inconvénient : par défaut, elles ne permettent pas de filtrer la liste de résultats selon un argument. C'est donc génial pour afficher tous les billets d'un blog ou un billet en détail mais pas pour les billets de la catégorie XYZ. J'en vois déjà certains raler (non pas de nom, c'est mal) . Et bien ils auraient tord, car on peut vite retrouver nos petits avec les vues génériques et un chouilla de dev autour.

Il existe un très bon billet à ce sujet : Django tips: get the most out of generic views

Dans le cas présent, ce qui nous intéresse, c'est d'afficher tous les billets d'un blog portant le tag "XYZ" :

Soit une appli de blog possédant le modèle suivant :

class Tag(models.Model):
    name = models.CharField(maxlength=50)
    url = models.SlugField(prepopulate_from=("name",))

class Post(models.Model):
    author = models.ForeignKey(User)
    title = models.CharField(maxlength=50)
    summary = models.TextField(blank=True)
    message = models.TextField()
    tag = models.ManyToManyField(Tag, blank=True)
    url = models.SlugField(prepopulate_from=("title",))

et la configuration d'url suivante :

urlpatterns = patterns('',
   (r'^$', 'django.views.generic.list_detail.object_list', dict(queryset= Post.objects.all(),)),
   (r'^post/(?P<slug>[-\w]+)/$', 'django.views.generic.list_detail.object_detail', dict(queryset= Post.objects.all() , slug_field= 'url',)),
   (r'^tag/$', 'django.views.generic.list_detail.object_list', dict(queryset= Tag.objects.all(), )),
   (r'^tag/(?P<mytag>[-\w]+)/$', 'atomecms.blog.views.tag_detail'),
)

ce qui nous intéresse surtout, c'est la règle suivant qui dit que toute url commençant par /tag/quelquechose doit être traiter par la vue "tag_detail" de l'application blog de mon projet atomecms :

   (r'^tag/(?P<mytag>[-\w]+)/$', 'atomecms.blog.views.tag_detail'),

dans le fichier views.py de mon application, il me suffit de définir la vue "tag_detail" dont le but est d'afficher la liste des billets portant le tag passé dans l'url :

from atomecms.blog.models import Post, Tag
from django.views.generic.list_detail import object_list

# Display all post for a given tag
def tag_detail(request, mytag):
    whoistag = Tag.objects.get(url=mytag)
    postlist = whoistag.post_set.all()
    return object_list(request, queryset=postlist, template_name='blog/tag_detail.html', allow_empty = 'True',)

Explications :

J'ai besoin de manipuler les objets Post et Tag définis plus haut, je les importe donc,
Comme je m'appuie sur les vues génériques, j'ai aussi besoin d'importer la fonction me retournant une liste d'objets
whoistag me permet de récupérer les information du tag passé dans l'url en le matchant avec l'attribut "url" de mon modèle. Il me fait une sorte de lookup complet. J'obtiens ainsi l'id et le nom du tag.
postlist me donne la liste des billets portant le tag passé dans l'url en me basant sur l'id du tag obtenu précédemment. J'avais écrit initialement la ligne suivante qui donne le même résultat mais est peut être plus compréhensible à savoir que postlist me donnait tous les billets ayant l'id du tag retenu.:

    postlist = Post.objects.filter(tag=whoistag.id)

mais david me dit que c'est mieux ainsi et plus "django compliant". En effet, après avoir regardé la doc sur l'api de la DB, on comprend mieux la raison d'être du post_set et le raccourci que me fait faire david.

et dans mon template, dans la zone dédié à cet effet, il me suffit d'ajouter :

	{% for object in object_list %}
		<dl>
			<dt>{{object.title}}</dt>
			<dd>{{object.summary}}</dd>
		</dl>
	{% endfor %}

Explications :

ma vue me retourne un object_list avec tout les billets répondant à la requête et fournit pour chaque billet, l'ensemble des champs de mon modèle post.
je crée donc une boucle, qui parcourt mon objet object_list et pour chaque item j'affiche le titre et le résumé de mon billet.

Et voila, il me suffit de me rendre sur http://localhost:8000/blog/tag/xyz et ça marche ! J'ai l'affichage qui m'intéressait et le projet Atome vient de faire un grand bond en avant !

edit : Niko, c'est plus clair maintenant ?

Django - installer la version de développement

NiCoS — Fri, 12 Jan 2007 22:15:00 +0100

Me remettant à django sur mon ordi perso, j'ai reparcouru la doc d'install qui conseille de prendre la dernière version de développement. Allez soyons fou en ce vendredi soir !

J'ai suivi bêtement les indications :

svn co http://code.djangoproject.com/svn/django/trunk/ django_src
sudo ln -s `pwd`/django_src/django /usr/lib/python2.3/site-packages/django

Par contre au lieu de copier django_src/django/bin/django-admin.py dans /usr/local/bin, j'ai préféré faire un lien symbolique, ce qui me semble plus pertinent avec une version de dev (on sait jamais, ce binaire peut changer et je pourrais rater cette mise à jour).

sudo ln -s `pwd`/django_src/django/bin/django-admin.py /usr/local/bin/django-admin.py

Et voilà, c'est parti

Edit : j'ai un seul petit souci, je n'arrive plus à avoir l'autocomplétion de django sous Eclipse - je sais pas si c'est du à la version de dev ou à la dernière version de pydev... sinon tout marche au poil

Django et les vues génériques - utilisation de extra_context

NiCoS — Fri, 01 Dec 2006 22:46:00 +0100

Django met à disposition les vues génériques pour faciliter la vie du programmeur pour les questions courantes (lister un ensemble d'objets, montrer le détail d'un objet, que ce soit sous la forme d'une simple liste, ou bien par des tris de date).

Cette fonctionnalité est très pratique et permet de créer rapidement des pages. Dans ces vues génériques, on a parfois besoin d'afficher d'autres éléments et il faut bien caser les opérations nécessaires quelque part. C'est là qu'interviennent les "extra_context".

Reprenons une vue générique simple : si j'arrive sur http://www.domaine.tld/ je veux lister tous les billets d'un blog.

Je vais avoir dans urls.py :

from django.conf.urls.defaults import *
from blog.models import Post, Tag, Category

urlpatterns = patterns('django.views.generic.list_detail',
   (r'^$', 'object_list', dict(queryset= Post.objects.all(),)),
)

et dans mon template :

{% block centralcontent %}
	<h3>Derniers billets...</h3>
	{% for object in object_list %}
	<div class="post">
		<h4>
			<a href="{{ object.get_absolute_url }}" title="{{ object.title }}">{{ object.title }}</a>
		</h4>
		<p class="post-info">Rédigé le {{ object.pub_date|date:"d F Y à H:i" }}, dans
		{% for post_category in object.category.all %}
		 <a href="{{ post_category.get_blog_absolute_url }}" title="{{ post_category.name }}">{{ post_category.name }}</a>
		{% endfor %}
		</p>
		<div class="post-tag">Tags :
			{% for post_tag in object.tag.all %}
			 <a href="{{ post_tag.get_blog_absolute_url }}" title="{{ post_tag.name }}">{{ post_tag.name }}</a>
			{% endfor %}
		</div>
		<div class="post-content">{{ object.summary }}</div>
	</div>
	{% endfor %}
{% endblock %}

Imaginons un instant que je veuille ajouter sur ma page d'accueil la liste des tags et des catégories de mon blog. Je vais donc ajouter des éléments dans mon motif d'urls :

from django.conf.urls.defaults import *
from blog.models import Post, Tag, Category


urlpatterns = patterns('django.views.generic.list_detail',
   (r'^$', 'object_list', dict(queryset= Post.objects.all(),extra_context={'all_tags': Tag.objects.all(), 'all_categories': Category.objects.all(), })),
)

et dans mon template, j'aurais juste à ajouter :

{% block rightcolumn %}
	{% if all_tags %}
	<h3>Tags</h3>
	<ul>
	{% for tag in all_tags %}
		<li><a href="">{{ tag.name }}</a></li>
	{% endfor %}
	</ul>
	{% endif %}

	{% if all_categories %}
   	<h3>Categories</h3>
   	<ul>
	{% for categories in all_categories %}
		<li><a href="" title="{{ categories.description }}">{{ categories.name }}</a></li>
	{% endfor %}
	</dl>
	{% endif %}
{% endblock %}

Et voilà, ma page d'accueil liste mes billets, et dans la colonne de droite la liste des tags et des catégories (s'il y en a).