En fouillant un peu la doc, je tombe sur ceci qui permet de faire précisément ce que je souhaitais : stocker une sérialisation de la définition d’un queryset, et non le queryset lui même (c’est à dire la liste des instances de modèles résultantes).

If you only want to pickle the necessary information to recreate the QuerySet from the database at a later time, pickle the query attribute of the QuerySet. You can then recreate the original QuerySet (without any results loaded)

pickling querysets

En stockant conjointement la définition de la requête et l’index auquel on est parvenu, il est alors possible d’effectuer un traitement par lots en ne chargeant à chaque itération que les données nécessaires.

En l’occurence un envoi de mails en série mais individualisé pour chaque destinataire à partir d’un “simple” template. Cette technique me permet de ne traiter que le résultat d’une recherche multicritères. Il faut toutefois garder en mémoire que le set de données initial peut avoir été modifié entre la sérialisation et le traitement.

Post-scriptum : Il m’a fallu encoder le résultat de pickle.dumps() en base 64 afin d’éviter d’obtenir une erreur no module named copy_reg (alors que import copy_reg fonctionne, étrange).

Note that the current date is always used; it’s not just a default value that you can override.

C’est parfait pour l’usage normal de ces champs, mais gênant lorsque par exemple on importe les données d’une application existante via un script dédié (voir la création de commandes) utilisant la couche modèle.

Pour contourner cet écueil, j’ai tout simplement enregistré mes objets une première fois via save(), puis une seconde fois via la méthode update de leur queryset en filtrant sur la clef primaire.

obj = MyModel()
obj.save()
MyModel.objects.filter(pk=obj.pk).update(created=value, updated=value)

Ce n’est certes pas très optimisé question performances, mais m’économise de créer les objets directement en SQL.

Par défaut, la commande manage.py makemessages n’indique pas dans quel fichier se trouve le problème d’encodage. La solution est que j’ai trouvé est d’activer le mode verbeux avec manage.py makemessages -v 2, chaque fichier parcouru lors de la génération du fichier .po est alors affiché à l'écran.

sys.path.insert(0, os.path.abspath('..'))

# import de l'environnement django
import settings
from django.core.management import setup_environ
setup_environ(settings)

(ceci suppose qu’on travaille dans le dossier docs à la racine du projet).

Bon ça demande un peu de travail d’écriture et de mise en forme pour être digeste, mais c’est quand même appréciable. Surtout quand on en vient (vite) à jongler avec des dizaines de fichiers ouverts de centaines de lignes chacun…

Comme vous peut être, je n’aime pas trop me rendre dépendant d’un service et risquer de perdre tous mes abonnés si l’envie me prenait de le quitter. J’ai donc configuré ces flux de telle manière que leur url reste sous le domaine du site concerné. Voici un très bref tutorial.

Il vous faut :

• Un nom de domaine dont vous pouvez éditer les DNS (Ici enregistré chez Gandi).
• Un compte google/feedburner.
• Un outil de publication permettant de modifier l’url du flux public (ici WordPress).

1. Choisir le sous-domaine qui sera affecté aux flux. feeds par défaut pour feedburner, mais j’ai choisi flux pour mes sites, essentiellement francophones.

2. Générer le flux déporté par feedburner en lui fournissant l’url source du flux, c’est à dire celle produite par votre site (ici WordPress donc votreblog.com/feed ).

   

3. Aller sur son compte feedburner. Copier la valeur du champ DNS CNAME (qui se termine par feedproxy.ghs.google.com.)

4. Ouvrir un onglet avec la configuration du domaine. Ajouter un enregistrement CNAME avec la valeur copiée précédemment. Attention, cette modification pourra prendre plusieurs heures pour être prise en compte.

   

5. Revenir sur feedburner. Lui spécifier les domaines complets des flux. Activer le service.

   

6. Modifier l’adresse publique des flux sur votre site. Pour WordPress, il y a sans doute un plugin qui fait ça très bien mais pas celui que j’ai testé. Je suis donc allé dans l’editeur du thème utilisé pour modifier les <?php bloginfo('rss2_url'); ?> par http://flux.votredomaine.com/slug-feedburner-du-flux. Les fichiers concernés sont généralement header.php (à plusieurs emplacements, dans la partie <head> et dans <body>) et footer.php.

Je ne me prononcerai pas sur twig que je ne testerai sans doute pas de sitôt (vous aurez compris que le besoin est déjà couvert). Je trouve juste dommage que Django ne soit presque pas cité sur son site. D’abord c’est inélégant, mais surtout cela passe à coté de l’un des intérêts selon moi de la librairie en question : l’interopérabilité avec un framework python majeur. J’en fais actuellement l’expérience, puisque je réécris une application web PHP avec Django, et que je réutilise quasiment tel quels les templates puisque la syntaxe est la même.

Concernant la syntaxe en question, et l’avantage par rapport à du PHP “pur”, qui semble être le débat en cours sur twig, il y a bien sûr la possibilité d’en permettre l’édition par l’équipe éditoriale sans qu’une erreur dans le template ne mène à une erreur 500 ou une faille de sécurité. Mais aussi le système d’héritage qui permet de définir facilement un layout global ou par section; le marquage des contenus à traduire pour l’internationalisation, etc.

Pour pouvoir accéder à l’ip client via request.META['REMOTE_ADDR'] lors de l’éxécution des tests unitaires, il faut la définir lors de l’instanciation du client de test. Par exemple :

from django.test import TestCase
from django.test.client import Client

def setUp(self):
self.client = Client(REMOTE_ADDR='127.0.0.1')

Sans cela vous obtiendrez une exception de type KeyError parce que REMOTE_ADDR ne sera pas définie dans request.META. Ceci concerne Django 1.0.2 et j’ai trouvé la solution ici

Ci dessous, je veux créer une variable str, et ensuite convertir un entier en chaine. Ce qui me lève une exception.

>>> str = "un chaine"
>>> douze = str(12)
TypeError: 'str' object is not callable

Pourquoi ? Parce qu’en python tout est objet – y compris les fonctions, et que le concept de variable est remplacé par celui de nom, qui référence les objets. En l’absence du $ qui en PHP distingue les variables des fonctions, j’avais tout simplement remplacé la fonction str() par une chaine.

Ensuite, je me suis arraché les cheveux sur une erreur de calcul incompréhensible jusqu’à ce que j’ouvre une console python pour obtenir le résultat suivant :

>>> 9/12
0
>>> 9.0/12.0
0.75

Eh oui, pas de conversion automatique d’entier en float lors d’une opération. Il faut donc explicitement déclarer les opérateurs en float avec le .0.

La meilleure pour la fin. En PHP, j’avais pris pour habitude de déclarer toutes les propriétés d’instance dans le corps de la classe plutôt que dans le constructeur, afin d’y associer des doc blocks et d’y définir les éventuelles valeurs par défaut. Comme ceci :

<?php
class MyClass {
    /**
     * @var int un entier entre un et douze
     */
    protected $qt = 3;

    public function __construct($qt=null) {
        if (is_int($qt))
          $this->qt = $qt;
    }
}

Ce qui en python donne quelque chose comme ça :

class MyClass():
    # @var int un entier entre un et douze
    qt = 3

    def __init__(qt = None):
        if qt is not None:
            self.qt = qt

Mais ne fonctionne pas du tout pareil. J’étais d’autant plus perdu que la classe en question était instanciée via une méthode statique et que mes instances se comportaient en singleton sans que ce soit le résultat souhaité. J’ai bien du perdre deux heures là dessus, à multiplier les tests unitaires et refactoriser le code pour trouver la source du problème.

>>> first = MyClass(12)
>>> first.qt
12
>>> second = MyClass()
>>> second.qt
12

Jusqu’à ce que je réalise que tout attribut déclaré dans la classe est un attribut de celle-ci et non de l’instance, bien qu’elle soit accessible et modifiable par l’instance avec la même syntaxe (self.qt). Les attributs de classe sont à peu près équivalents aux propriétés statiques en php, et sont partagés entre toutes les instances de la classe.

Pour qu’un attribut soit propre à l’instance (local), il faut impérativement qu’il soit déclaré dans le constructeur :

class MyClass:
    def __init__(qt=None):
        if qt is not None:
            self.qt = qt
        else:
            self.qt = 3

Voici le bilan de trois jours d’évaluation.

Premier jour : (ré)installation de Django, la version 1.0.2, et création du projet. L’application se compose de trois interfaces : une interface web classique (qui doit donc etre multilingue), une interface XML-RPC et une interface client-serveur proprietaire. J’ai choisi de créer une app par interface. Je commence par l’interface client-serveur, qui est le point le plus critique et qui va subir prochainement une forte montée en charge. C’est elle qui va contenir la couche modèle.

La structure de la base de données étant déjà définie, je crée les classes modèles afin qu’elles s’adaptent aux tables existantes. Il s’agit pour l’instant de code essentiellement déclaratif. Parmi les spécificités, je créé un modèle superflu pour prendre en charge une table de liaison qui ne suit pas les conventions de nommage de Django; et un champ CSVField pour des listes de valeurs stockées en CSV dans la base. Le code ci-dessous, incluant docstrings et doctests (Qui sont pour moi une forme de documentation) :

from django.db import models

class CSVField(models.Field):
    """Python list stored as a single CSV-encoded varchar field"""
    separator = ';'
    max_length = 255

    def db_type(self):
        """Define SQL column type"""
        return 'VARCHAR(%s)' % self.max_length

    def to_python(self, value):
        """Converts CSV to Python list

        >>> CSVField.to_python('1;2;3;4;5')
        [1,2,3,4,5]"""
        return value.split(self.separator)

    def get_db_prep_value(self, value):
        """Converts Python list to CSV

        >>> CSVField.get_db_prep_value([1,2,3,4,5])
        '1;2;3;4;5'"""
        return self.separator.join(value)

Je crée également les premières vues, qui se contentent de réafficher les paramètres passées dans l’url.

Deuxième jour : Je mets en place les premiers tests unitaires. Je découvre le client de test de Django, qui me permet de tester les premières vues, avec des données générées dans une base de tests en partie par un fichier yaml (fixtures) et en partie via l’API de la couche modèle dans le setUp() de la classe de tests.

Ensuite, je m’attaque à l’interface web classique qui doit être internationalisée. J’installe pour cela gettext sur mon poste de travail (windows). Je crée la première vue (la page d’accueil) et les templates correspondant. Je marque les parties à traduire dans le code et les templates, et crée les fichiers de traduction anglais et chinois. Je les édite avec poedit, un logiciel spécialisé (de l’avantage d’utiliser un standard existant). Je copie-colle ce que me donne Google Translate pour le chinois parce que, euh, je ne parle pas cette langue. Mais je peux voir avec satisfaction les premiers idéogrammes apparaitre sur le site.

Ici les contenus textuels n’auront pas à être édités fréquemment. Dans le cas contraire je vois mal comment interfacer simplement gettext avec un CMS. Ici, le choix de gettext et poedit permet de faire saisir les traductions par quelqu’un qui n’est pas webmestre. De plus, gettext est également disponible en PHP via une extension spécifique.

Troisième jour : Il est temps de passer à l’interface xml-rpc. Après une brève recherche, je tombe sur django_xmlrpc qui permet d’associer les vues aux methodes fournies par le serveur (Django sert les vues selon des expressions régulières sur l’url de la requete, or avec xml-rpc toutes les méthodes sont servies sur la même url).

Après avoir listé les méthodes et les vues, je crée quelques tests unitaires pour la première. pour cela, je surcharge la classe TestCase de Django avec quelques méthodes utilisant les utilitaires xml-rpc de python (Voir le code ci-dessous). Après quelques tatonnements, mes premiers tests passent !

from django.test import TestCase

class XmlRpcTestCase(TestCase):
    """Specialisation de TestCase pour xml-rpc"""

    # @param string method
    # @param tuple params
    # @param string uri
    # @return Response
    def methodCall(self, method, params=(), uri='/rpc/'):
        """Issue a methodCall and sends a django's test client Response"""
        from xmlrpclib import dumps
        call = dumps(params, method)
        return self.client.post(uri, call, content_type='text/xml')

    # @param Response response
    # @param bool use_datetime if True return datetimes as object
    # @return tuple
    def parseResponse(self, response, use_datetime=True):
        """Parse django's client http Response to python tuple"""
        from xmlrpclib import loads, Fault
        try:
            result = loads(response.content, use_datetime)
            # result is a tuple params, method
            return result[0]
        except Fault, f:
            self.fail("Response was a Fault")
            return ()

    # @param string method
    # @param tuple params
    # @param string uri
    # @return tuple
    def parseCall(self, method, params=(), uri='/rpc/'):
        """method's result <params> as a python tuple

        assert False on method Fault"""
        response = self.methodCall(method, params, uri)
        return self.parseResponse(response)

    def assertNotFault(self, response):
        return self.assertNotContains(response, '<fault>')

Comme il me reste un peu de temps, je reviens sur l’interface client-serveur qui sert un XML maison. Je découvre donc l’implémentation DOM de python pour le générer. Je rajoute quelques tests, et quitte la boite (tôt) sur un premier test positif

Bilan : Compte tenu de la vitesse à laquelle je me retrouve avec un prototype, et du fait que je n’ai rencontré aucun obstacle, je vais très probablement continuer l’implémentation en python et django. Il s’agit d’un choix tout à fait subjectif. J’apprécie beaucoup la syntaxe Python, son modèle tout-objet, et la philosophie batteries included (il y a en standard une bonne librairie pour la plupart des besoins). Et surtout, la qualité et l’exhaustivité de la documentation du langage et du framework, qui permettent de trouver très rapidement ce que l’on cherche, et même plus !

• Formulaire d’installation de l’administration (création d’utilisateur pour l’authentification HTTP).
• Génération de la structure de base des paquets depuis l’admin, ainsi que l’import de fichier de librairie.
• Simplification de l’usage des tests unitaires : il suffit de déposer les classes de tests et scripts SQL de mise en place dans le dossier tests/ du kit.
• De nouvelles librairies intégrées (bases de données, système de fichiers, et un début d’implémentation de Django Forms.
• Et bien sûr pas mal de polissage et de corrections de bugs.

Le site web a également été mis à jour pour l’occasion, avec un nouveau tutorial qui se place dans le cadre de la refactorisation d’un site. La première partie est publiée, le reste suivra prochainement.

Prenons le cas d’une application web vieillissante que nous souhaitons étendre et refactoriser. Comme par exemple, un intranet en code spaghetti, consistant en un ensemble de scripts mixant HTML, PHP et SQL. Bien sûr, il s’agit d’un exemple purement théorique. Toute coïncidence avec une application existante ne serait que pur incident statistique .

lire la suite

Pour rester informés, vous pouvez suivre le twitter du projet. Ses messages sont repris sur le site web et sur l’interface d’administration. Pour participer, vous pouvez également passer par le forum / newsgroup ou envoyer un email.