Le blog d'Aozeo

Excellente année 2008

C'est un peu facile de souhaiter la bonne année sur un blog en hibernation, mais c'est un peu facile de ne pas la souhaiter...

Passez donc une année meilleure que la précédente si celle-ci fut mauvaise, similaire si 2007 vous a convenu, et un peu plus sobre si la dernière a fait exploser les compteurs, pour vous remettre un peu à votre place parce quand même.

Excellente année 2008 donc, et à bientôt sur Aozeo pour la nouvelle version du site qui commence désormais a faire son âge. Aozeo v2(.0) sera graphique ou ne sera pas.

Eiffel V, téléchargez vos vidéos

Certes, ce blog ne connaît pas une activité débordante. Faisons abstraction : voici Eiffel V, un script graphique de téléchargement de vidéos qui tourne en local. Son boulot : récupérer tous les éléments vidéos d'une page et les proposer au téléchargement.

Quel avantage par rapport aux sites proposant ce service, type Keevid ?

Eiffel V s'exécute en local.
Eiffel V est libre (licence CeCILL).
Eiffel V gère les vidéos incluses sur des sites tiers.
Eiffel V est localisable.
Eiffel V est conçu de manière à ce que vous puissiez ajouter les sites dont vous avez besoin.
Eiffel V est en Python.
Je suis gentil.

Quel inconvénient ?

Eiffel V ne fonctionne pas sur Windows.
Eiffel V n'est pas inclus dans le navigateur.
Eiffel V a quelques dépendances : wxPython et BeautifulSoup.
Que ça ?

Téléchargement et installation

Téléchargez l'archive, décompressez, lancez eiffel.py, et ça devrait y être...

Que fait-il vraiment ?

Il gère Youtube, Dailymotion, Myspace, Metacafe, Google Vidéos, même avec un lecteur inclus sur une autre page, et les lecteurs FLV basiques genre celui de Neolao. Il repère les vidéos, vous demande lesquelles souhaitez-vous télécharger, puis s'en occupe. Si vous le lancez en ligne de commande avec une URL en argument, il démarre comme un grand. Si vous avez une idée de fonctionnalité supplémentaire, je suis preneur...

Ajouter un site de vidéos

Créez une classe avec pour nom la première partie du domaine du site, avec une majuscule, en la dérivant de la classe Site. Par exemple avec youtube.com, class Youtube(Site).
Créez une méthode _do, à laquelle sera passé l'élément dom, un objet BeautifulSoup. Faîtes-en ce que vous voulez pour obtenir l'URL du fichier FLV et son titre. Vous avez éventuellement accès à self.url qui est l'adresse de la page.
S'il n'y a pas de vidéo (vidéo rejetée, supprimée, etc.) sur la page, créez un évènement vide : self.evt = ParsingIsDone(videos = []). Sinon, créez celui-ci : self.evt = ParsingIsDone(videos = [Video(url_flv, titre)]). Puis ajoutez ces lignes à la fin de la méthode _do :

if self.send_evt:
     wx.PostEvent(prog.frame, self.evt)

Éventuellement, le site peut permettre à ses utilisateurs d'inclure son lecteur. Si vous désirez gérer ce cas, vous devez créer une méthode _in, à laquelle sera passé l'objet BeautifulSoup représentant l'<embed> ou l'<object> du lecteur flash_object, et la liste des vidéos déjà traitées done_urls. En effet, certains sites utilisent et embed et object, il faut ainsi éviter les doublons.
Tout d'abord, trouvez la véritable adresse de la vidéo, ou n'importe quel élément qui l'identifie à coup sûr et qui nécessite le moins de traitement. Vérifiez ensuite s'il se trouve dans done_urls :

if url_trouvee in done_urls:
    self.evt = ParsingIsDone(videos = [])
    return

Puis ajoutez-le :

done_urls.append(url_trouvee)

Enfin, trouvez l'adresse du fichier FLV et le titre de la vidéo, puis créez l'évènement : self.evt = ParsingIsDone(videos = [Video(url_flv, title)]). Attention, pas besoin de l'envoyer avec wx.PostEvent cette fois-ci.
Vous devez ensuite spécifier un élément qui sera caractéristique de votre site d'inclusion de vidéos, typiquement l'URL du lecteur Flash, que Eiffel V ira chercher dans le contenu des <embed> et des <object> de la page, comme http://lads.myspace.com/videos/vplayer.swf pour Myspace vids. Faîtes le en donnant à la classe un attribut embed_url, par exemple : Vids_myspace.embed_url = 'http://lads.myspace.com/videos/vplayer.swf'
Ajoutez votre nouvelle classe à la variable SITES.

Regardez les classes déjà présentes si vous avez besoin d'exemples, et envoyez-moi les vôtres (baptiste-at-aozeo_dot_com), que j'ajouterai à la prochaine version de Eiffel V :-) Merci pour les retours...

Passez à Jinja !

Je n'ai pas mis à jour ce blog depuis pas mal de temps pour cause d'activité débordante et je ne reprends le flambeau que pour quelques jours étant en vacances à partir de la semaine prochaine, mais c'est toujours un article de pris.

Je continue d'utiliser Django pour des projets professionnels et privés, et c'est vraiment un plaisir de jouer avec. Cependant, les limitations du langage de gabarits ont eu un jour raison de mon enthousiasme, et j'y ai cherché une alternative. Ne souhaitant pas recommencer l'apprentissage d'une nouvelle syntaxe, mon choix s'est rapidement porté sur Jinja, qui reprend en majorité celle de Django. Dans l'absolu, vous pouvez utiliser n'importe quel moteur de gabarits. Dans la pratique, il est préférable d'en choisir un qui soit adapté à Django !

Je vais présenter mon coup de cœur (qui n'était pas un coup de tête, je suis toujours fidèle à à mon choix deux mois plus tard) de manière certes non-exhaustive mais, je l'espère, complète, en se penchant sur les divers aspects de son fonctionnement.

Syntaxe

Commençons par le point le plus simple. La syntaxe de Jinja comporte quelques différences avec celle de Django :

L'appel aux méthodes n'est plus implicite, ainsi vous devrez écrire {{ instance.get_absolute_url() }} au lieu de {{ instance.get_absolute_url }}. C'est un peu contraignant lors de la migration car vous devrez vérifier chaque variable, mais le gain vaut à mon avis le coup : une meilleure clarté, la gestion du cas de figure (bien qu'à éviter) méthode/attribut homonymes, et la possibilité de fournir des arguments.
Les arguments des filtres sont à utiliser comme ceux des fonctions, ce qui permet d'en placer plusieurs ; on passe ainsi de {{ liste|join:", " }} à {{ liste|join(", ") }}.
Point de tag {% include "gabarit.html" %} mais rendertemplate("gabarit.html") .
Plus de dérivées de if comme ifequal, au profit du vrai test, celui disponible en Python. C'est un avantage majeur qui permet d'éviter l'inévitable {% if %}{% else %} du langage de Django, qui autorise de vraies comparaisons comme >=, et qui souffre la combinaison des conditions avec les mots-clés and et or.
Plus non plus de {% if %} les uns dans les autres pour simuler un banal {% elif %}... Car ce tag existe dans Jinja ! Certains le jugent dangereux car il complexifie des gabarits, je trouve au contraire qu'il les simplifie,

{% if var %}
{% elif var2 %}
{% elif var3 %}
{% endif %}

étant autrement plus élégant que :

{% if var %}
{% else %}
    {% if var2 %}
    {% else %}
         {% if var3 %}
          {% endif %}
    {% endif %}
{% endif %}

Fonctionnement global

La classe Environment est la base de tout le système : c'est le contexte dans lequel seront traduits vos gabarits ; il se charge de les trouver à partir de leur chemin puis de les interpréter. Les différents filtres doivent y être recensés pour exister dans l'espace de nom du gabarit, et il contient votre configuration. Dans cet article, la référence à l'objet principal Environment se fera à travers la variable env. Le schéma classique de fonctionnement est le suivant :

TEMPLATE_PATH = settings.TEMPLATE_DIRS[0]
env = Environment(loader=FileSystemLoader(TEMPLATE_PATH))
gabarit = env.get_template('/chemin/vers/gabarit.html')
gabarit.render(contexte)

Par défaut, pour instancier l'environnement, vous devez simplement indiquer le chemin d'un dossier qui contiendra tous vos gabarits. Il est possible de personnaliser ce comportement en créant votre propre Loader, mais pour ça, référez-vous à la documentation, ce billet va déjà être bien assez dense !

Filtres

Comme avec le système de Django, vous pouvez écrire vos propres filtres très simplement. Pour reprendre l'exemple de la documentation, voici le filtre cut version Jinja :

def do_cut(arg=u''):
    def wrapped(env, context, valeur):
        return valeur.replace(arg, '')
    return wrapped

En fait, cet exemple est la version complète du filtre, avec un accès à l'environnement env et au contexte à la variable éponyme. En procédant de cette manière, il est nécessaire d'enregistrer le filtre dans l'espace de nom de l'environnement avec env.filters['cut'] = do_cut. Mais il est en réalité possible de faire plus simple :

from jinja.filters import stringfilter

def do_cut(valeur, arg):
    return valeur.replace(arg, '')
env.filters['cut'] = stringfilter(do_cut)

Oui, c'est la même chose que dans Django ! À une différence près : la fonction peut prendre autant d'arguments que vous le désirez. Par exemple, pour faire un filtre similaire à cut mais limitant la taille de la chaîne :

def do_cut(valeur, arg, taille):
    return valeur.replace(arg, '')[:taille]
env.filters['cut'] = stringfilter(do_cut)

que l'on utilisera simplement en faisant {{ somevariable|cut(0, 15) }}. C'est aussi simple que dans Django mais bien plus puissant, le nombre d'arguments n'étant pas limité et une possibilité d'accès au contexte étant réservée !

Macros

Pour finir cet aperçu de l'utilisation de Jinja, je vais parler rapidement des macros, qui sont une fonctionnalité souvent demandée et assurément manquante à Django. Elles permettent de répéter un morceau de code sans le réécrire, un peu comme une variable. Comme les fonctions, elles peuvent aussi prendre des arguments. Par exemple :

{% macro afficher_dictionnaire(dico) %}
   {% if dico %}
       <ul>
       {% for cle, valeur in dico|dictsort %}
            <li>{{ cle }} : {{ valeur }}</li>
       {% endfor %}
       </ul>
    {% endif %}
{% endmacro %}

Que vous utiliserez avec {{ afficher_dictionnaire(form.errors) }}. C'est un atout majeur, car la consigne fétiche de Django, DRY, est bien mise à mal lorsqu'on est obligé de recopier des bouts de code plusieurs fois pour simuler ce comportement !

Utiliser Jinja avec Django

L'intégration à notre framework préféré se fait sans douleur grâce à l'existence d'un render_to_response pour Jinja. Il fonctionne exactement de la même façon que l'existant, aucun souci de migration à prévoir. Je vous conseille personnellement de créer un fichier utils/jinja.py à la racine de votre projet, et d'y placer votre render_to_response. Dès que vous aurez besoin d'un nouveau filtre, il vous suffira de l'éditer pour avoir accès à l'objet env très simplement ! Enfin, gardez l'astuce permettant de transformer un filtre Django en filtre Jinja sous la main. Plus tard peut-être, un nouveau billet sur Jinja pour aborder tout ce qui ne l'a pas été aujourd'hui...

Conclusion

Cette présentation ne vaut assurément pas la documentation, mais permet de donner une idée de la puissance de Jinja qui surpasse en bien des points le langage de gabarits de Django. C'est un module qui m'est désormais indispensable, car je n'ai plus à bidouiller continuellement pour obtenir ce que je veux, ce qui était devenu obligatoire même en faisant attention à ne pas déporter ce qui pourrait être fait dans la vue dans le template. Si vous avez décidé de sauter la marche, le plus simple pour obtenir de l'aide (en anglais) reste IRC sur #pocoo@irc.freenode.net. Les développeurs principaux sont souvent présents et très réactifs en cas de souci ! Mais vous pouvez aussi poser votre question ici-même, peut-être pourrais-je y répondre...

Mémento SPIP 2

La première version de l'aide-mémoire SPIP était assez imparfaite pour mériter une petite révision. Au menu, des corrections de fautes (d'orthographes) et de vraies erreurs, des explications un peu moins incompréhensibles, une légère mise à jour du contenu et une présentation plus efficace avec un code joliment présenté (moins laidement, en tout cas).

La version PDF tient toujours sur deux pages, un A4 recto-verso :
Télécharger le mémento 2.01

On a soulevé le problème, alors voici une version sans couleur, pour les daltoniens et ceux qui économisent leurs cartouches :
Télécharger le mémento 2.01 sans couleur

Son contenu ne sera par contre pas visible en ligne, contrairement à la version précédente. Ça peut être un inconvénient, mais c'est impossible de maintenir deux versions parallèles d'un même document ! Il faut en tout cas noter que quelques lignes de cet aide-mémoire concernent la 1.9.2, il serait donc bon de considérer ce mémento 2 comme destiné à cette version de SPIP. Pour les réfractaires, il existe toujours la première version.
Première version qui avait finalement été traduite en italien par Renato après une tardive mise en ligne des sources. Cette fois-ci, elle n'attendra pas, le fichier .sla (Scribus) est d'ores et déjà disponible sur la zone. Vous pouvez le traduire et proposer des modifications, pour peu d'installer Scribus et les typos nécessaires (voir plus bas).

Merci de faire remonter erreurs et coquilles pour obtenir une version, allez, parfaite ! Et car la demande a été récurrente, un jour (un jour, pas bientôt) arrivera le mémento débutant qui n'aura plus grand chose à voir avec un aide-mémoire mais qui présentera le fonctionnement de SPIP pour ceux qui veulent commencer à y toucher mais qui ne comprennent rien à la documentation. Et un jour plus tard, le mémento bidouilleur qui listera avec une subjectivité revendiquée les chouettes plugins à ne pas manquer pour SPIPer avec joie et entrain.

Pour finir, un dernier détail car certains avaient été gênés par ce point, le mémento 2 n'utilise que des polices libres : Monaco, DejaVu et Steinem.

Historique des modifications

2.01 : Correction d'une erreur sur l'emplacement des squelettes de formulaires en 1.9.2 & explications un peu moins concises sur la #PAGINATION. Merci Alexandra.
2.0 : Version initiale

Django 0.96 est sorti

La nouvelle version de Django, à priori dernière étape avant la prochaine 1.0, vient d'être publiée. Voici un récapitulatif des changements, d'après les notes de version.

Les deux nouveautés principales sont les nouveaux formulaires, newforms, dont j'ai parlé récemment, et l'arrivée d'un outil permettant de tester "industriellement" les applications et de remplir la base de données automatiquement (fixtures).

Les newforms se situent pour le moment dans django.newforms, et les anciens dans django.oldforms. À la prochaine version, les nouveaux formulaires seront placés dans django.forms, et les anciens supprimés. Il est donc de temps de profiter de la 0.96 pour les mettre à jour en douceur.
Les tests sont plus complexes à synthétiser, je vous conseiller de lire la documentation (en anglais). On retiendra la possibilité de charger automatiquement des données pour les besoins du test, ce qui est assez pratique pour gagner du temps. manage.py prend désormais deux nouvelles options : dumpdata et loaddata, qui permettent respectivement de copier les données de la base et d'en insérer.

Une petite modification qui change pas mal de choses : les fichiers URLconfs peuvent désormais appeler directement des fonctions, au lieu de chaînes. Voici concrètement ce que ça peut changer, exemple directement repris du site officiel :

Avant

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    ('^mavue/$', 'monsite.monapp.views.mavue')
)

Maintenant (il ne s'agit que d'une possibilité, l'ancienne syntaxe fonctionne toujours)

from django.conf.urls.defaults import *
from monsite.monapp.views import mavue

urlpatterns = patterns('',
    ('^mavue/$', mavue)
)

Ce qui autorise l'inclusion d'un décorateur directement dans le fichier urls.py. Par exemple, ce code ajoute une authentification à une vue générique :

from django.conf.urls.defaults import *
from django.contrib.auth.decorators import login_required
from django.views.generic.list_detail import object_list
from monsite.monapp.models import MonModele

info = {
    "queryset" : MonModele.objects.all(),
}

urlpatterns = patterns('',
    ('^mavue/$', login_required(object_list), info)
)

Enfin, la version requise du module MySQL Python est désormais la 1.2.1p2 ; mais pour ne pas casser les sites ne pouvant effectuer la mise à jour, il est toujours possible d'en utiliser une plus ancienne en passant le paramètre DATABASE_ENGINE de settings.py à "mysql_old".

La publication de cette version a été un peu soudaine, la traduction Française n'est donc pas entièrement à jour... Un patch a été proposé. Pour conclure, une dernière nouveauté certes complètement mineure, mais en étant l'auteur j'en suis honteusement et orgueilleusement fier, le module humanize est désormais localisé. C'est à dire que nombre ne donnera plus "1st" mais 1er (avec même le "er" en exposant).

Newforms : des validateurs personnalisés

Avec les newforms de Django, il est relativement facile d'ajouter des validations personnalisées à vos champs : il faut simplement créer une classe dérivée du type de champ que vous souhaitez utiliser.

Dans cet exemple, nous allons simplement vérifier que l'utilisateur donné n'existe pas (pour, par exemple, un formulaire d'inscription). Il faut effectuer quelques imports avant tout, bien sûr :

from django import newforms as forms
from django.contrib.auth.models import User

Pour un créer champ classique, on pourrait utiliser :

nom_utilisateur = CharField(label="Nom d'utilisateur", min_length=3, max_length=128)

Nous allons donc dériver CharField :

class UserField(forms.CharField):

Comme nous l'avons vu dans le précédent article, la validation des différents champs est définie dans leurs méthodes clean. Il suffit donc de l'étendre :

    def clean(self, value):
        super(UserField, self).clean(value)

super permet d'appeler la méthode clean de la classe parente, qui vérifie notamment que la longueur du champ est bien comprise dans l'intervalle [min_length, max_length] et qu'il est rempli si l'attribut required est à True. C'est une ligne à placer au début de toute méthode d'une classe dérivée (évidemment, seulement si elle est étendue, c'est à dire définie dans la classe parente) pour éviter les soucis.
La vérification, enfin :

        try:
            User.objects.get(username=value)
            raise forms.ValidationError("Quelqu'un utilise déjà ce nom d'utilisateur ! Choisissez-en un autre.")
        except User.DoesNotExist:
            return value

L'explication est très simple : on cherche tout d'abord un utilisateur existant déjà et avec cet identifiant. Si il n'existe pas, alors Django lève une exception User.DoesNotExist, et on peut retourner la valeur pour dire que tout va bien. Par contre, si l'utilisateur existe, la fin du try est exécutée, et une exception ValidationError est levée, avec le texte d'explication fourni en argument (qui sera affiché comme l'erreur "Ce champ est obligatoire").
La ligne du formulaire qui va créer le champ ressemble désormais à :

nom_utilisateur = UserField(label="Nom d'utilisateur", min_length=3, max_length=128)

Django va ensuite se débrouiller tout seul, empêcher de valider le formulaire, et ajouter l'erreur à form.errors. Plus besoin de faire quoi que ce soit, si vous affichez votre formulaire grâce à form dans votre gabarit (ou même si vous séparez erreurs et champs, avec form.errors ).

Simple, et efficace !

Introduction aux newforms de Django

Pour inaugurer cette catégorie dédiée au framework web Django, qui présente l'intérêt majeur d'être écrit en Python, voici une présentation des nouveaux formulaires qui seront introduits dans la prochaine version 0.96, et qui sont déjà disponibles dans la version de développement. Il vaut mieux commencer à les comprendre dès maintenant, étant donné que les anciens ne seront rapidement plus disponibles.

À noter que l'absence de documentation n'a pas permis à ce billet d'être exhaustif... Quelques fonctionnalités des newforms ne seront pas abordées.

Commencer

Il convient tout d'abord de les importer :

from django import newforms as forms

Commençons par créer un formulaire. C'est très simple, un formulaire est une classe, dérivée de django.newforms.Form, dans laquelle on peut définir les différents champs qui seront disponibles, exactement comme dans les modèles.

class FormulaireCommentaire(forms.Form):
    nom = forms.CharField()
    email = forms.EmailField()
    message = forms.CharField()

Pour créer le formulaire, il suffit d'instancier la classe :

form = FormulaireCommentaire()

Méthodes et attributs

Une classe forms.Form peut prendre plusieurs arguments. Le premier permet de le pré-remplir (par exemple, s'il a déjà été envoyé mais qu'il contient des erreurs, et qu'il doit être réaffiché).
Vous pouvez également spécifier l'argument auto_id, qui est un motif pour les identifiants des champs : champ_%s_formulaire donnera, pour le "nom", champ_nom_formulaire.

data = request.POST.copy ()
form = FormulaireCommentaire(data, auto_id='commentaire_%s')

L'attribut is_bound renvoie True si le formulaire contient des données, False sinon. Quand vous y avez inséré du contenu, vous pouvez vérifier sa validité en testant form.is_valid(). Si certains champs sont mal remplis, form.errors retourne un dictionnaire de la forme {'champ': [u'Erreur']} ; mais vous pouvez également afficher une erreur particulière en utilisant form['champ'].errors. Quand votre formulaire est valide - et seulement lorsqu'il l'est -, vous pouvez accéder à l'attribut clean_data, qui contient les données (sous la forme d'un dictionnaire) converties en objets Python correspondants. Pour savoir quel champ retourne quel type de données, regardez la liste des types de champs plus bas. De la même façon que pour les erreurs, vous pouvez accéder au contenu d'un champ en utilisant form.clean_data['champ']. Si le formulaire n'est pas valide, vous devrez vous baser sur les données POST : request.POST['champ'], mais ce ne sera pas un objet Python.

Avant d'aller plus loin, regardons les arguments communs à tous les champs :

required

C'est assez parlant, True (défaut) pour que le champ doive être rempli, False pour qu'il puisse rester vide.

widget

L'argument widget permet de choisir comment afficher un champ, plus d'explications dans la suite.

label

Permet de spécifier le nom du champ.

help_text

Permet de spécifier un texte qui apporte des précisions sur le champ.

initial

La valeur par défaut que prendra le champ.

Afficher les formulaires

Pour afficher le formulaire, vous pouvez simplement le transmettre à votre gabarit, puis l'afficher avec {{ form }}. Mais par défaut, il est rendu comme faisant partie d'un tableau, ce qui est loin de convenir à la majorité des cas. Vous pourrez ainsi faire {{ form.as_p }} pour afficher le formulaire dans des paragraphes, et {{ form.as_ul }} pour l'afficher sous forme de liste. Attention, si vous avez passé le paramètre auto_id à False, les <label> ne seront pas affichés ! De ces trois façons, les messages d'erreur seront également affichés sous les champs concernés.

Cependant, on peut désirer personnaliser un peu plus la sortie HTML du formulaire, et Django le permet. Ainsi, form['nom'] affichera seulement l'<input> ; form['nom'].errors les erreurs, et @@form['nom'].label l'intitulé du champ. Il faudra donc assembler ces éléments.

Widgets

L'argument widget permet d'associer un type de champ (sortie HTML) à l'un d'entre eux. Par exemple, un même champ classique CharField pourra être affiché avec différents widgets : TextInput (par défaut), PasswordInput, HiddenInput, Textarea... Ils permettent donc de choisir comment afficher un champ, en fonction de son objectif. Il est également possible de créer les vôtres en dérivant la classe forms.Widget (ou l'un d'entre eux directement si vous souhaitez ne modifier qu'un détail), si vous avez un besoin plus spécifique. Parmi les autres widgets disponibles, retenons FileInput, CheckboxInput, Select, SelectMultiple, RadioSelect, CheckboxSelectMultiple, dont les noms sont suffisamment parlants. Attention, les widgets n'influent pas sur le contenu du champ, seulement sur la manière dont il est présenté.

Exemple

Voici comment afficher un formulaire basique de commentaire, et l'ajouter à la base de données.

def vue_article(request, id_article):
    class FormulaireCommentaire(forms.Form):
        nom = forms.CharField("Votre nom")
        email = forms.EmailField("Votre email", help_text = "Veuillez indiquer une adresse mail valide", required = False)
        message = forms.CharField(widget = forms.Textarea)

    try:
        article = Article.objects.get(id=id_article)
    except Article.DoesNoExist:
        raise Http404

    form = FormulaireCommentaire()

    if request.method =='POST': 
        #On copie les données POST
        data = request.POST.copy()
        #Et on crée un formulaire avec
        form = FormulaireCommentaire(data)
        message = None
        #S'il ne contient pas d'erreur...
        if form.is_valid():
            #On peut créer un nouveau commentaire
            comment = Comment(nom = form.clean_data['nom'], email = form.clean_data['email'], message = form.clean_data['message']
            #Et l'enregister
            comment.save()
            #On remplace form par un nouveau formulaire vide
            form = FormulaireCommentaire()
            message = "Commentaire enregistré avec succès !"
    return render_to_response("article.html", {'article': article, 'form': form})

Ensuite, votre gabarit :

{% extends base %}
{% block content %}
 article.text 
{% endblock content %}
{% block content_bottom %}
{# Si on a un message de succès, on l'affiche. #}
{% if message %}
<p class="message"> message </p>
{% endif %}
<form action="" method="POST">
{# On fait une boucle sur le formulaire pour avoir une sortie plus personnalisée, et car ce ne serait pas intéressant, sinon ! #}
{% for field in form %}
    {# On n'oublie pas de relier le label au champ, grâce à l'attribut auto_id #}
    <p><label for="{{ field.auto_id }}">{{ field.label }}</label>
    {{ field }}
    {% if field.errors %}
    <span class="error">
        {{ field.errors }}
    </span>
    {% endif %}
    {# On affiche la ligne d'aide si jamais elle est présente #}
    {% if field.help_text %}
        <span class="help">
        {{ field.help_text }}
        </span>
    {% endif %}
    </p>
{% endfor %}
</form>
{% endblock content_bottom %}

Conclusion

Voici un bref aperçu des nouveaux formulaires de Django. Si ils permettent d'harmoniser leur création avec la structure des modèles en offrant une syntaxe cohérente et puissante, ils présentent le défaut majeur de ne pas pouvoir regrouper certains champs pour former des <fieldset>, qui se révèlent pourtant très utiles dans la création de formulaires avancés. Cela m'oblige à utiliser des palliatifs grossiers dans mon gabarit... et ça ne me plaît pas !

Les champs

Voici maintenant les différents types de champs disponibles dans une classe forms.Form :

Field

Classe de base, qui représente un champ de texte simple. clean retourne une chaîne.

CharField

Comme Field, mais un peu plus avancé, avec les arguments min_length et max_length qui stipulent respectivement un nombre minimum et maximum de caractères. clean retourne une chaîne.

IntegerField

Un entier ; prend les arguments min_value et max_value pour choisir les nombres auquels la valeur ne doit respectivement pas être inférieure et supérieure. clean retourne un entier.

DateField

Une date, prend un argument input_formats qui peut être un tuple de formats de date acceptés, comme par exemple "%d/%m/%Y" pour "7/3/2007". Par défaut, un bon nombre sont déjà définis... clean retourne un objet datetime.date.

TimeField

Une heure, prend un argument input_formats qui peut être un tuple de formats d'heure acceptés, comme par exemple "%Hh%M:%S" pour "17h23:12". clean retourne un objet datetime.time.

DateTimeField

Une date et une heure, prend un argument input_formats qui peut être un tuple de formats de date et heure acceptés, comme par exemple "%Hh%M:%S %d/%m/%Y" pour "17h23:12 7/3/2007". clean retourne un objet datetime.datetime.

RegexField

Comme CharField, à la différence que son contenu doit correspondre à l'expression régulière fournie à l'argument regex (requis). Prend également un argument error_message, qui sera retourné si l'expression régulière ne valide pas le champ. clean retourne une chaîne.

EmailField

Une adresse email valide, avec les arguments min_length et max_length. clean retourne une chaîne.

URLField

Une URL valide (du format http://www.aozeo.com/). Prends un argument verify_exists, qui, passé à True, vérifiera que l'URL répond et ne renvoie pas une 404 ; validator_user_agent permet de choisir l'USER-AGENT qui sera envoyé lors du test. clean retourne une chaîne.

BooleanField

Un champ vrai ou faux classique. clean retourne True ou False.

ChoiceField

Un choix entre les différentes options passées en argument à choices, sous la forme d'un tuple : ( ('identifiant_option_1', 'Option 1'), ('identifiant_option_2', 'Seconde option') ). clean retourne une chaîne.

MultipleChoiceField

Comme ChoiceField, mais autorise la sélection de plusieurs valeurs. clean retourne une liste de chaînes.

Webinaire W3C sur les bonnes pratiques du Web Mobile

Poussé par Karl Dubost, j'ai assisté au premier webinaire français organisé par le W3C, qui concernait les bonnes pratiques du web mobile.

Une expérience très réussie, félicitations à Cédric Kiss pour sa présentation ; et un succès logistique admirable. On pouvait entendre l'animateur sur un flux audio, voir en parallèle les diapos en ligne qu'il déclenchait au fur et à mesure, tout en pouvant poser des questions, et ce avec 32 auditeurs.

Cette conférence - qui sera prochainement mise en ligne -, a permis de cerner réellement les problématiques du web mobile, un des domaines ayant le plus fort potentiel d'expansion de l'Internet actuel, mais bien mal connu et bien mal aimé, de par ses importantes contraintes.

Ce qui ressort, pour moi, de cette heure de séminaire, quand au support :

Il est très difficile d'établir une "configuration" de base sur laquelle partir pour l'élaboration de sites destinés à des outils mobiles, les différences entre appareils sont illustrées par ce bref récapitulatif des capacités de quelques téléphones.

Cependant, on peut considérer une configuration "moyenne" des appareils actuellement en service, qui est bien sûr destinée à évoluer rapidement : 120px de large, pas de JavaScript, des pages de 20ko maximum, et un support des images JPEG et GIF.

À l'inverse de l'Internet classique, où la démocratisation de l'ADSL rend la contrainte du poids de plus en plus marginale, elle est très importante pour le média portable, car l'accès est en général facturé au poids,
Il faut accorder une importance à la différence de finalité : l'utilisateur qui visite un site sur son téléphone portable n'a pas le même objectif qu'un visiteur sur son ordinateur de bureau

Mais ce moyen d'accès au Web est à prendre sérieusement en compte, car l'utilisation d'un portable est plus courante que celle d'un ordinateur et étalée sur la journée entière !

En ce qui concerne le développement de sites pour ce média, ce qui nous intéresse :

Le support de l'UTF-8 peut-être considéré comme acquis
Il est compliqué de détecter un media mobile, mais on peut essayer de se baser sur l'Agent-Utilisateur et les entêtes transmis par le navigateur
On doit penser aux mobiles dès la création du site, par exemple lors de l'élaboration des messages d'erreur : un site qui requiert un "Page précédente" au moindre problème n'est pas efficace, c'est lent pour les utilisateurs de téléphones
Pour les formulaires, préférer autant que possible les <select> aux <input type="text">, et ranger les choix par pertinence pour faciliter la sélection
Utiliser des <label> pour mettre en évidence la nature des champs
Les ancres sont utiles, mais provoquent sur certains médias un rechargement complet de la page !
Pour les pages longues, les diviser peut être une solution ; mais ça comporte selon moi un inconvénient majeur : si on cherche un passage donné, ce n'est pas pratique de devoir visiter les 10 subdivisions de la page pour la trouver, comme il est nécessaire de le faire avec l'adaptation que fait subir Google aux pages visitées à partir du moteur de recherche mobile, que l'on peut constater sur la page Philosophie de Wikipedia
Le JavaScript peut-être interprété par certains téléphones, mais pas la majorité : il faut le rendre non indispensable et non obstrusif

Quand à la présentation et à l'apparence des sites mobiles :

On peut s'appuyer sur les CSS media="handled", même si certains appareils interprètent également les feuilles de style media="screen" : j'imagine qu'il faut penser à surcharger les règles CSS
Il faut absolument limiter la taille des images, pour réduire temps de chargement et coûts
Si les tableaux fonctionnent bien sur tous les navigateurs classiques, ils sont à proscrire totalement des pages mobiles ! Ils alourdissent sérieusement la page (risquent de provoquer une erreur mémoire chez les périphériques les moins robustes), et sont très mal rendus, de par l'affichage linéaire des téléphones portables.
Il faut également utiliser les CSS avec parcimonie : des feuilles de style trop longues sont elles aussi susceptibles de causer des problèmes

Cédric a développé le concept du « One Web », qui est de présenter un seul contenu, une seule page, même si elle peut-être adaptée au média ; c'est à dire de ne pas avoir deux sites redondants, un pour les téléphones portables et un pour les ordinateurs, mais un unique, prenant en compte les spécificités des différents moyens d'accès au site. L'utilisation des CSS media="handled" est la pierre angulaire de cette "philosophie", si j'ose dire, mais ne constitue pas le seul paramètre à prendre en compte : les pages doivent également être pensées pour l'utilisateur mobile. Privilégiez les images miniatures avec un lien vers la version originale, pas de contenu susceptible de faire apparaître un ascenseur horizontal, préférez du texte concis et allant droit au but.

Pour ceux qui s'y intéressent, vous pouvez donner vos avis sur le second brouillon de la spécification mobileOK, visant à déterminer les critères d'accessibilité d'un site aux médias portables, et à terme de faire office de "label qualité" pour les utilisateurs.

Si vous désirez tester le rendu de votre site sur un téléphone, il y a des émulateurs de navigateurs pour mobiles, mais ce sont en général ceux des plateformes avancées (Symbian, Windows Mobile, ...). Sans avoir besoin d'aller jusque là, on peut se contenter de l'extension Web Developer pour Firefox (finalement, elle a toujours une utilité !), qui propose deux options intéressantes : "Linéariser la page" et "Rendu sur petits écrans", ce qui donne sur le blog d'Aozeo cette image. En situation réelle, et sur un téléphone Nokia interprétant les CSS media="screen" (merci à celui qui a effectué les photos), le résultat est beaucoup moins réjouissant. Pourquoi ? Car le téléphone interprète comme il peut des instructions qui ne lui sont pas destinées, et ça fâche. Mais bientôt, ce blog sera mobileOK, grâce à la création d'une feuille de style "handled" !

Bref, un webinaire très enrichissant, sur un domaine très prometteur et voué à une grande expansion, comme le prouve la décision récente de l'opérateur Ten de rendre l'Internet mobile gratuit et illimité pour ses abonnés. Je serai au rendez-vous pour le prochain !

Gérez vos polices de caractère avec Fonty Python

Si vous touchez parfois au Gimp, vous avez sûrement déjà du être confronté à la recherche d'une police de caractère qui convienne à l'usage que vous désirez en faire. Et pour peu que vous en ayez pas mal, ça devient rapidement infernal !

En cherchant un logiciel me permettant de gérer mes typos, je suis tombé sur Fonty Python. Il permet de visualiser ses polices de caractères, et de les organiser en pogs, listes qui les référencent. Il est ainsi facile d'installer et de désinstaller plusieurs jeux de polices en fonction de ses besoins.

Cependant, Fonty Python ne correspondait pas tout à fait à ce dont j'avais besoin. Je me suis donc essayé à Python - agréable expérience, pour y apporter les modifications qui me semblaient utiles. Avant de continuer, je préviens tout de suite que son auteur n'a pas souhaité sortir cette nouvelle version avant de l'avoir étudié en détail, ce qu'il ne peut pour le moment pas faire, elle n'est donc pas encore disponible.
Au menu :

utilisation de gettext, et traduction de l'application
tags
notation
sauvegarde des miniatures pour accélérer l'affichage

Ce que résume cette capture :

Bientôt, donc, un gestionnaire de polices de caractère complet pour Linux (et même dès maintenant si vous n'avez pas besoin des nouveautés exposées ci-dessus) !

Cette première expérience Python m'a fait découvrir un langage très puissant et performant, auquel je ne reprocherai que la documentation, loin d'égaler celle de PHP par exemple. J'en retiendrai également que wxWidgets est un créateur d'interfaces à éviter, au vu de son nombre de bugs et de comportements inattendus ! Je viens de me pencher sur pyGTK qui semble être plus intéressant, mais pour une grosse application, je pencherai plutôt pour pyQT4, qui a le mérite de ressembler, sous GNOME, à une application GNOME.

W3-Campus, édition 2007

Webmaster-Hub a lancé l'année dernière la première édition de W3-Campus, un séminaire sur le Web (plus sur son utilisation que sur la technique).

Vu le succès de l'édition précédente, il ne pouvait qu'être reconduit, cette fois sous le signe du référencement et de la communication. Il se déroulera les 30 et 31 mars, à Marseille, avec les interventions - entre autres - de Sébastien Billard, de Philippe Yonnet (directeur du département Internet à Studyrama) ou de Paypal France. Le programme est dense, nul doute que vous trouverez ce qui vous intéresse si vous touchez à ce domaine.
La cité phocéenne est un peu éloignée de mes pâturages parisiens, je ne pourrai pas m'y rendre, mais les intéressés pourront faire confiance à l'organisation qui s'occupera de vous loger (dans un hôtel ***, excusez du peu) et de vous inviter à la soirée de clôture à bord d'un vrai bateau ancien en vrai bois.
Bref, une fin de semaine entièrement planifiée et sans effort : comptez 590€ pour le séminaire, l'hébergement et les repas ; 305 pour les deux jours de conférence seuls.

Réservez !

Le blog d'Aozeo

Excellente année 2008

Eiffel V, téléchargez vos vidéos

Téléchargement et installation

Que fait-il vraiment ?

Ajouter un site de vidéos

Passez à Jinja !

Syntaxe

Fonctionnement global

Filtres

Tags

Macros

Utiliser Jinja avec Django

Conclusion

Mémento SPIP 2

Historique des modifications

Django 0.96 est sorti

Avant

Maintenant (il ne s'agit que d'une possibilité, l'ancienne syntaxe fonctionne toujours)

Newforms : des validateurs personnalisés

Introduction aux newforms de Django

Commencer

Méthodes et attributs

Afficher les formulaires

Widgets

Exemple

Conclusion

Les champs

Webinaire W3C sur les bonnes pratiques du Web Mobile

Gérez vos polices de caractère avec Fonty Python

W3-Campus, édition 2007