.: chiroux.com :. » Obsolete

Django : une arborescence de catalogue

Thomas — Wed, 08 Aug 2007 22:26:49 +0000

C’est la semaine de la publication… Après le gadget vista pour la NB4, voici un article qui explique comment gérer une structure arborescente avec django (un excellent framework python).
J’espère que cet article sur django est le premier d’une longue série. J’ai comme beaucoup l’intention de basculer mon site sur cette techno, mais cela va prendre du temps. En attendant, j’essaierais de continuer à proposer des morceaux de codes ou des applications django comme celle-ci à l’avenir.

Depuis ma ‘conversion’ à python, j’ai eu – entre autre – l’occasion de découvrir le framework de développement web django. Après avoir fait un peu de tour du marché des framework python open source, c’est vraiment celui qui m’a paru le plus prometteur avec une approche à la fois intelligente et très pragmatique du développement web. Depuis ce temps, je n’avais pas vraiment eu l’occasion de développer un site en particulier, l’occasion s’est présentée il y a environ un mois où j’ai eu le besoin de maquetter un petit site de gestion de catalogue de films (une sorte de proof of concept), pour lequel il a donc fallu constuire une arborescence du catalogue. Voici donc une petite application django qui permet de gérer un catalogue hierarchique.

[cliquez ici pour accéder directement au téléchargement]

Fonctionnalités et technologies utilisées

A ce stade, le catalogue affiche une page web avec un catalogue hierarchique que l’on peut gérer dynamiquement.
Toutes les modifications de ce catalogue sont réalisées en AJAX.
Les fonctionnalités sont donc les suivantes :

afficher un catalogue avec une vue hierarchique
déplacer des éléments du catalogue vers une autre position (avant, après ou à l’intérieur d’un autre élément)
Ajouter des éléments du catalogue (avant, après ou à l’intérieur d’un autre élement)
Supprimer un élément du catalogue
Modifier un élément du catalogue (le renommer)

Les techno utilisées sont :

Coté client
- mootools (cela devient une habitude)
- mootree (une extension à mootols qui permet de gérer justement des catalogue), dans une version modifiée par moro (http://forum.mootools.net/viewtopic.php?pid=23580) qui permet tout particulièrement la gestion des drag&drop.
Côté serveur
- django et donc python (j’utilise la version de devt, à la revision 5830 au moment où j’écris ces lignes)

Django

Comme à mon habitude, mon but n’est pas de réécrire ce qui a déjà été présenté et expliqué dans d’autres sites bien mieux que je ne pourrais le faire.
Pour débuter sur django et pour aller plus loin ensuite, il existe de plus en plus de ressources sur le net.
Je ne saurais trop vous conseiller de suivre les étapes du book django.
Le site officiel de django qui regroupe tout ce qui est nécesaire :
Ainsi que le site français django-fr
J’ai aussi trouvé beaucoup d’information très intéressantes et pertinentes sur le site de David Larlet : Biologeek

Django et AJAX

Le principal reproche que l’on fait généralement à django (notamment quand on le compare à rails est qu’il ne gère pas les applications AJAX nativement.
Nous allons voir plus loin que faire des applications AJAX avec django non seulement ne pose aucun problème mais en plus est extrèmement simple (comme souvent d’aileurs avec ce framework).

Etape 1, la modélisation des données

Le principe général est que chaque élément est un noeud du catalogue et qu’il a donc un élémént ‘père’. Cela forme ainsi une structure hiérarchique potentiellement infinie. Les éléments qui n’ont pas de père sont les éléments en tête du catalogue.

class Catalogue(models.Model):
    node_name = models.CharField(maxlength=200)
    node_parent = models.ForeignKey('self', blank=True, null=True)
    path = models.CharField(maxlength=200, editable=False, null=True)
    indent_level = models.PositiveSmallIntegerField(editable=False, null=True)
    level_order = models.PositiveSmallIntegerField(editable=True, null=True)

l’élément de catalogue a également trois informations supplémentaires qui seront mises à jour automatiquement par l’application :

le ‘path’ qui représente de façon linéaire la position de l’élément dans le catalogue (ex pour l’émément d’id 4 : 1.2.3.4 signifie que son père est le 3 et que son grand père est le 2 et ainsi de suite)
l’ ‘indent_level’ représente le niveau de profondeur dans l’arbre où se site l’élément (0 est le niveau le plus haut, notre élément dans cet exemple a donc un indent_level de 3)
le ‘level_order’ est un champ qui va servir à ordonner les éléments du même niveau hierarchique (pour ne pas obliger un tri en particulier)

Ces 3 champs étant mis à jour dynamiquement, il est nécessaire, dans la définition du modèle, de réaliser des actions particulières lors de l’INSERT, l’UPDATE ou le DELETE d’un élémént.
Dans les modèles django, c’est effectué en spécialisant les méthodes save() et delete() : a chaque action de save() [en cas d'INSERT ou UPDATE] ou de delete(), ces méthodes seront appelées et feront les calculs et modifications nécessaires à la mise à jour de ces données.

    def save(self):
        """Redéfinition du save afin de remplir les champs path, indent_level et level_order
        """
        if self.id == None:
          # C'est un insert : On fait un premier save pour récupérer un id
          self.path = ''
          self.indent_level = 0
          #self.level_order=0
          super(Catalogue, self).save() # call the real save()

        # On modifie son path en ajoutant son id au path du parent
        parent = self.node_parent
        if self.node_parent != None:
          self.path=parent.path + '.%s' % self.id
          self.indent_level= parent.indent_level + 1
        else:
          self.path = '%s' % self.id
          self.indent_level = 0
        super(Catalogue, self).save() # call the real save()

        #Ensuite on resauvegarde les enfants pour remettre à jour path et indent_level
        for son in Catalogue.objects.filter(node_parent=self):
          son.save()

	def delete(self):
	    """Traitement du delete du catalogue afin notamment de raccrocher les fils au nouveau père
	    """
	    #Identifier les fils
	    sons = Catalogue.objects.filter(node_parent=self)
	    for son in sons:
	      #pour chaque fils, le rattacher à mon propre pere
	      son.node_parent=self.node_parent
	      son.save()

	    super(Catalogue, self).delete() # call the real delete()

On peut remarquer ici que le delete ne supprime pas l’arborescence qui en sous l’élément effacé. C’est un choix de ma part, à la fois pour des questions de sécurité (eviter l’erreur fatale) et pour des raisons de gestions, cela me parait plus logique au jour le jour d’avoir des manipulations unitaires que des suppressions de catalogues complets.

Toutefois il serait imaginable de coder une sorte de ’super delete’ qui supprimerait l’élément et tous ses enfants.

Etape 2, les URLS

L’application et donc les URLS sont d’inspiration REST. Je ne peut pas encore parler de RESTFULL car je n’ai pas encore assez creusé le sujet. A ce sujet les articles de David sur son site, notamment celui ci assez récent sont des très bon points de départ.

La gestion des URLs est déléguée dans l’application, ainsi la config d’urls.py du projet est assez simple :

urlpatterns = patterns('',
    (r'^catalogue/', include('myproject.catalogue.urls')),

le fichier urls.py du projet catalogue est plus intéressant :

from django.conf.urls.defaults import *
from myproject.catalogue import views

urlpatterns = patterns('myproject.catalogue.views',
    (r'xml/?', 'catalogueXML'),
    (r'move/?', 'moveCatalogueItem'),
    (r'insert/?', 'insertCatalogueItem'),
    (r'delete/?', 'deleteCatalogueItem'),
    (r'update/?', 'updateCatalogueItem'),
    (r'/?$', 'catalogue'),

Les URLS globales seront donc de la forme : /catalogue/xml/, etc…

Voici leur rôle :

/catalogue/
- Affiche la page web du catalogue
/catalogue/xml/
- renvoie une strucute xml avec tout ou partie du catalogue (un filtrage peut être réalisé en envoyant des données en POST)
/catalogue/move/
- toujours en fonction des données envoyées en POST, permet de déplacer des éléments du catalogue
/catalogue/insert/
- insère un élément dans le catalogue (le PUT du REST)
/catalogue/delete/
- supprime un élément dans le catalogue
/catalogue/update/
- modifie un élément du catalogue

A chaque URL correspond une vue que nous allons décrire maintenant

Etape 3, Les vues

la vue catalogue

Cette vue est ultra simple et pourrait dans l’absolu être hébergée n’importe où : comme toutes les autres relations entre la page web et le site sont en AJAX, django n’a pas besoin de gérer cette vue. Elle est ajoutée ici pour des raisons de cohérence et de simplicité. Elle ne fait rien d’autre que d’afficher un template de la page catalogue.html. Nous reviendrons sur cette page plus bas car c’est là que se situe tout le code javascript.

la vue catalogueXML

cette vue renvoie une structure XML représentant l’arbre (ou une partie de l’arbre) du catalogue.
Elle prend en argument en POST le ‘node_path’ du node de l’arbre a partir duquel on souhaite récupérer l’arborescence. Si on n’envoie aucun paramètre c’est l’arbre entier qui est retourné.

A noter : toutes les vues gère à la fois la récupération des arguments en GET ou en POST, c’est principalement pour des raisons de debug.

Le parcours du catalogue en base est réalisé de façon récursive et cette méthode appelle donc une sous méthode récursive (recurseCatalogueXML) qui elle même continue à parcourir les sous éléments du noeud.
Il y a d’autres façon de faire, certainement plus performantes (notamment en utilisant un parcours linéraire en ordonant les résultats du node_path), mais alors les fonctions pour générer la structure XML sont plus complexes à écrire. J’ai choisi ici la lisiblité au détriment de la performance.

def catalogueXML(request):
    node=None
    try:
        if request.method == 'GET':
            debug('catalogueXML - method:GET')
            node_path = request.GET['node_path']
        elif request.method== 'POST':
            debug('catalogueXML - method:POST')
            node_path = request.POST['node_path']
        try:
            node = Catalogue.objects.get(path=node_path)
        except ObjectDoesNotExist:
            node = None
    except KeyError:
        # Pas de request, on part du root catalogue
        node = None

    xml = ''
    xml = recurseCatalogueXML(node)

    t = loader.get_template('catalogue_xml.xml')
    c = Context({
        'snippet': xml,
    })
    return HttpResponse(t.render(c), mimetype='application/xml')

def recurseCatalogueXML(parent):
    if parent == None:
      items_list = Catalogue.objects.filter(node_parent__isnull=True).order_by('level_order')
    else:
      items_list = Catalogue.objects.filter(node_parent=parent).order_by('level_order')

    xml = ''

    for item in items_list:
        tmp_xml = recurseCatalogueXML(item)
        if tmp_xml == '':
            #pas d'enfants
            xml+= '\n'
        else:
            #des enfants
            xml+= '\n' + tmp_xml + ''

    return xml

la vue updateCatalogueItem

C’est la vue ‘active’ la plus simple. Elle prend en argument le path de l’item à modifier ainsi que le nouveau nom, récupère l’élément, le modifie et retourne le nouveau nom.

A noter : Pour cette vue et toutes les autres vues de modification, j’ai choisit aussi la simplicité concernant la gestion des valeurs de retour, en renvoyant du texte simple.
Une bonne application bien faite et bien propre renverrait une structure JSON ou XML avec des valeurs normalisées. Je le modifierais peut-être à l’avenir dans ce sens (notamment en permettant de choisir le format de retout JSON ou XML). Il sera de toute façon obligatoire de le faire à partir du moment où il est nécessaire de retourner plusieurs éléments, ce qui est d’ailleurs en théorie le cas ici).

Dans cet exemple, si l’update n’a pas pu être réalisé, la vue renverra ‘NOK’ et dans les autres cas le nouveau nom du noeud. Il y a donc un problème théorique si on renomme notre noeud en ‘NOK’ et que tout se passe bien… j’ai un peu triché là dessus côté client, nous verrons tout à l’heure.

def updateCatalogueItem(request):
    if request.method == 'GET':
        debug('updateCatalogueItem - method:GET')
        node_path = request.GET['node_path']
        item_new_name = request.GET['node_name']
    elif request.method== 'POST':
        debug('updateCatalogueItem - method:POST')
        node_path = request.POST['node_path']
        item_new_name = request.POST['node_name']

    debug('item:'+node_path)
    debug('new name:'+item_new_name)

    result=''
    try:
        node_to_be_updated = Catalogue.objects.get(path=node_path)
        node_to_be_updated.node_name = item_new_name
        node_to_be_updated.save()
        result=item_new_name
    except ObjectDoesNotExist:
        result='NOK'

    return HttpResponse(result)

la vue deleteCatalogueItem

Cette vue prends un seul paramètre : le node_path du noeud à supprimer et renvoye ‘OK’ ou ‘NOK’.

En fait cette vue ne fait rien d’intelligent (elle récupère le noeud et le supprime) car toute l’intelligence de traitement (notamment rattacher les noeud fils au père du noeud supprimé) sont fait dans les modèles que nous avons vu tout à l’heure.

def deleteCatalogueItem(request):
    if request.method == 'GET':
        debug('deleteCatalogueItem - method:GET')
        node_path = request.GET['node_path']
    elif request.method== 'POST':
        debug('deleteCatalogueItem - method:POST')
        node_path = request.POST['node_path']

    debug('node_path :'+node_path)

    result=''
    try:
        node_to_be_deleted = Catalogue.objects.get(path=node_path)
        node_to_be_deleted.delete()
        result='OK'
    except ObjectDoesNotExist:
        result='NOK'

    return HttpResponse(result)

la vue insertCatalogueItem

Cette vue est un peu plus complexe car elle doit gérer 3 cas différents :

L’insertion avant un item
L’insertion après un item
L’insertion à l’intérieur d’un item (et dans ce cas il faut gérer si c’est le premier élément sous l’item ou non)

Elle prend donc 3 arguments :

le nom de l’item à insérer
le node_path de l’item ‘près’ duquel nous allons insérer ce nouveau noeud
le type d’insertion (before, after ou inside)

def insertCatalogueItem(request):
    if request.method == 'GET':
        debug('insertCatalogueItem - method:GET')
        new_node_name = request.GET['node_name']
        to_item = request.GET['to_item']
        insert_type = request.GET['insert_type'] # before, after or inside
    elif request.method== 'POST':
        debug('insertCatalogueItem - method:POST')
        new_node_name = request.POST['node_name']
        to_item = request.POST['to_item']
        insert_type = request.POST['insert_type'] # before, after or inside

    debug('node_name :'+new_node_name )
    debug('to:'+to_item)
    debug('type:'+insert_type)

Comme il faut gérer des notions comme avant ou après un noeud, il faut gérer l’ordre, c’est donc pour cela que le champ ‘level_order’ existe.
Donc pour insérer l’item au bon endroit, il est nécessaire de connaitre son père et son numéro d’ordre à côté de ses frères.
La première chose à faire est donc de déterminer ces éléments en fonction des paramètres :

#On récupère le père
if insert_type == 'before':
    new_node_parent=Catalogue.objects.get(path=to_item).node_parent
    new_level_order=Catalogue.objects.get(path=to_item).level_order
elif insert_type == 'after':
    new_node_parent=Catalogue.objects.get(path=to_item).node_parent
    new_level_order=Catalogue.objects.get(path=to_item).level_order+1
elif insert_type == 'inside':
    try:
        new_node_parent=Catalogue.objects.get(path=to_item)
    except ObjectDoesNotExist:
        # Il n'y a pas d'objet c'est vraissemblablement le premier
        new_node_parent = None

    try:
        items_list=Catalogue.objects.filter(node_parent=new_node_parent).order_by('-level_order')
        new_level_order = items_list[0].level_order+1
    except IndexError:
        new_level_order = 1

En cas d’insertion before ou after, le parent est le même : c’est le parent du node mis en référence.
En cas d’insertion inside, le parent est directement le node mis en référence.
J’ai choisi pour l’insersion inside d’insérer par défaut en dernière position, il faut donc récupérer quelle est la dernière position des fils du node en référence.

Ensuite, en cas d’insertion before ou after, on doit éventuellement décaler tous les autres items ‘frères’ d’un cran afin de laisser la place à celui qui arrive :

# Pour les insert before et after : On update le level order de tous les enregistrements suivant du même niveau
    if insert_type == 'before' or insert_type == 'after':
        items_list = Catalogue.objects.filter(node_parent=new_node_parent, level_order__gte=new_level_order).order_by('level_order')
        for item in items_list:
            item.level_order+=1
            item.save()

Enfin on crée l’élément avec ces valeurs et on retourne le path :

# On crée l'enregistrement
p = Catalogue.objects.create(node_name=new_node_name, node_parent=new_node_parent, level_order=new_level_order)

return HttpResponse(p.path)

la vue moveCatalogueItem

Comme pour l’insert, cette vue va gérer trois types de mouvements : before, after ou inside un élément.

def moveCatalogueItem(request):
    if request.method == 'GET':
        debug('moveCatalogueItem - method:GET')
        item = request.GET['item']
        to_item = request.GET['to_item']
        move_type = request.GET['move_type'] # before, after or inside
    elif request.method== 'POST':
        debug('moveCatalogueItem - method:POST')
        item = request.POST['item']
        to_item = request.POST['to_item']
        move_type = request.POST['move_type'] # before, after or inside

    debug('item:'+item)
    debug('to:'+to_item)
    debug('type:'+move_type)

Ensuite, nous allons changer le parent de l’item en fonction des paramètres d’entrées pour le mettre au bon endroit :

    # le père de l'item est maintenant le même père que le to
    # On récupère le père de to
    catalogue_item_to = Catalogue.objects.get(path=to_item)
    # On récupère l'item
    catalogue_item = Catalogue.objects.get(path=item)

    # On met le bon parent
    if move_type == 'inside':
        catalogue_item.node_parent = catalogue_item_to
    else:
        catalogue_item.node_parent = catalogue_item_to.node_parent
    catalogue_item.level_order = 0
    catalogue_item.save()

Enfin on gère l’ordre, en décalant tous les éléments qu’il est nécessaire de décaler.
Cette partie est une des premières que j’avais réalisé, je m’aperçois aujourd’hui qu’elle est largement optimisable (éviter de parcourir tous les éléments)

    items_list = Catalogue.objects.filter(node_parent=catalogue_item.node_parent).order_by('level_order')
    offset = 0
    for item in items_list:
        if item.path == to_item:
            if move_type == 'before':
                offset = 1
                catalogue_item.level_order = item.level_order # on donne le numéro d'ordre à l'item inséré puis on ajoute l'offset aux items suivants
                catalogue_item.save()
            elif move_type == 'after':
                #En insertion after, l'augmentation d'offset des items ne doit se produire qu'au tour suivant, on va donc 'forcer' un tour
                offset = 1
                catalogue_item.level_order = item.level_order+1
                catalogue_item.save()
                continue
            elif move_type == 'inside':
                pass
        if offset != 0:
            debug_string = 'On ajoute %s' % offset + ' a item %s' % item.node_name
            debug(debug_string)
            item.level_order+=offset
            item.save()
        last_level_order = item.level_order

    if offset == 0:
        # on a pas trouvé, donc on insére à la fin
        catalogue_item.level_order = last_level_order+1
        catalogue_item.save()

    result = catalogue_item.path
    return HttpResponse(result)

Etape 4, le côté client en javascript

Résumé des flux AJAX

Voici un petit dessin qui résume les différentes interfaces que l’on a définie dans l’application django et donc ce que le côté client doit transmettre et recevoir :

Le code HTML

Le code html est constitué de deux parties :
le div qui va recevoir l’arbre :

les formulaires qui servent à gérer les différentes actions possibles sur les éléments du catalogue.
Ces formulaires sont très basiques et très moches. Le but est de montrer les fonctionnalités. Chacun intégrera ces fonctions à sa manière dans son site. Une implémentation sympa serait de gérer le bouton droit quand on est sur un élément de l’arbre et afficher un petit menu avec ces différentes possibilités. C’est éventuellement une évolution que j’apporterais à l’avenir.

Pour plus de lisibilité, j’ai séparé les différentes fonctions en différentes boites :

Le javascript

Au chargement de la page, la fonction main() est appelée, tout est à l’intérieur.

La première chose à faire est d’initaliser le mootree :

    function main() {
    tree = new MooTreeControl({
            div: 'mytree_catalogue',
            mode: 'files',
            theme: '/site_media/js/mootree.gif',
            grid: true,
            onSelect: function() {
                //alert('coucou');
                $('updateForm').node_name.value = this.selected.text;
                $('updateForm').node_path.value = this.selected.id;

            },
            onReplace: function(from,to,where){
                var myXHR = new XHR({
                    method: 'post',
                    onSuccess: function(new_path) {
                        from.id = new_path;

                    },
                    headers: {'Content-type': 'application/x-www-form-urlencoded; charset=utf-8'}
                    }).send('/catalogue/move/', 'item='+from.id+'&to_item='+to.id+'&move_type='+where);

                //alert([from.id,to.id,where])
            },
        nodeOptions: {
            text: 'Catalogue',
            open: true
        }
        });

L’évènement onReplace est un événement ajouté par moro sur le forum mootools il permet de gérer les déplacement d’items. Donc en cas d’événement de déplacement d’item, on lance cette fonction qui va réaliser un appel AJAX vers le serveur sur l’url /catalogue/move avec les bons paramètres.
En cas de retour ok, on met à jour l’id de l’élément du tree. (dans mootree, j’ai mappé l’id sur le ‘path’ du modèle de donnée python).
Avec cette seule fonction, on a déjà géré le déplacement d’items au sein de l’arbre (merci à mootree et à moro..)

le onSelect permet de faire des action lorsqu’on sélectionne un élément de l’arbre, cela sert ici à renseigner le champ ‘nom de l’arbre’ du formulaire de modification (c’est plus pratique et cela évite de le retaper).

Une fois le mootree initialisé, il faut le remplir, cela se fait avec la fonction ‘load’ :

tree.root.load('/catalogue/xml/')

N’ayant founi aucun paramètre à /catalogue/xml/, nous chargeons l’arbre en entier comme nous l’avons vu tout à l’heure.

Ensuite il faut gérer les différentes actions des formulaires.

Commençons par le formulaire d’insertion :

    $('insertForm').addEvent('submit', function(e) {
        // Prevent the submit event
        new Event(e).stop();

        // récupère l'item actuellement sélectionné
        if (tree.selected != null) {
            this.to_item.value = tree.selected.id;

            this.send({
                //update: log,
                onComplete: function(path_inserted) {
                    //log.removeClass('ajax-loading');
                    //alert(text);

                    if ($('insertForm').insert_type.value=='before') {
                        node = tree.selected.parent.insert({text:$('insertForm').node_name.value, id:path_inserted});
                        node.injectBefore(tree.selected);
                    }
                    if ($('insertForm').insert_type.value=='after') {
                        node = tree.selected.parent.insert({text:$('insertForm').node_name.value, id:path_inserted});
                        node.injectAfter(tree.selected);
                    }
                    if ($('insertForm').insert_type.value=='inside') {
                        node = tree.selected.insert({text:$('insertForm').node_name.value, id:path_inserted});
                    }
                }
            });
        }
    });

la fonction mootols $(‘insertForm’).addEvent permet d’ajouter un gestionnaire d’évenement sur le formulaire (ici sur l’évènement ’submit’). Donc a chaque fois que le formulaire sera validé, l’événement se déclenchera.
La variable ‘this’ au sein de cette fonction représente donc le formulaire.

Pour réaliser une insertion, il faut avoir sélectionné un élément de l’arbre.
On le récupère en javascript via tree.selected

ensuite le this.send est un raccouci mootools qui déclenche l’envoi en AJAX du formulaire vers l’url et en utilisant la méthode définie dans le formulaire (dans le code html du formulaire que l’on a vu plus haut).

Au retour, on déclenche l’événement ‘onComplete’.
Dans cette fonction, on va ajouter l’élément à l’arbre côté client (car à ce moment il est déjà ajouté côté serveur). L’insertion est différente en fonction des types d’insertion (before, after ou inside), mais le principe est le même : on utilise la méthode ‘insert’ de mootree.

Ensuite le formulaire de suppression :

Il est construit sur le même principe que l’insertion

    $('deleteForm').addEvent('submit', function(e) {
        new Event(e).stop();

        if (tree.selected != null) {
            this.node_path.value = tree.selected.id;
            this.send({
                onComplete: function(result) {
                    // On récupère le père (pour le rechargemetn de la partie du tree)
                    node_parent = tree.selected.parent;
                    // Ici effacer le node du tree
                    tree.selected.remove();
                    // reload du tree
                    // TODO: faire en sorte de ne reloader que à partir du père (nécessite aussi de changer le code serveur)
                    node_parent.load('/catalogue/xml/?node_path='+node_parent.id);
                    //tree.root.load('/catalogue/xml/');
                }
            });
        }

    });

Au retour de l’appel Ajax, une fois l’élément supprimé côté serveur, on le supprime dans l’arbre mootree.
Ensuite on déclenche un reload du sous arbre en partant du père de l’élément sélectionné : ceci est fait parceque la méthode remove() de mootree, contrairement à ce qu’on a choisit de faire côté serveur supprime tous les enfants avec. Donc il faut recharger cette partie de l’arbre.

Ensuite le formulaire de mise à jour :

    $('updateForm').addEvent('submit', function(e) {
        new Event(e).stop();

        if (tree.selected != null) {
            //this.node_path.value = tree.selected.id;
            this.send({
                onComplete: function(result) {
                    // On récupère le père (pour le rechargemetn de la partie du tree)
                    if (result != 'NOK') {
                        tree.selected.text=result;
                        tree.selected.update();
                    } else {
                        node_parent = tree.selected.parent;
                        node_parent.load('/catalogue/xml/?node_path='+node_parent.id);
                    }
                }
            });
        }
    });

Ici il y a un petit truc qui fait echo au côté serveur : nous avons vu précedemment que la fonction côté serveur renvoyait le nouveau nom en cas de réussite et « NOK » en cas d’échec. Donc ici, si la valeur retournée est différente de « NOK », on met à jour le noeud mootree avec cette valeur, mais si le retour est « NOK », nous ne sommes pas certain si c’était une erreur ou si l’utilisateur voulait vraiment renommer son noeud en « NOK », donc on recharge cette partie de l’arbre depuis le serveur, car c’est toujours le serveur qui a raison.
On voit ici les limites de ne renvoyer qu’une seule valeur à l’appel AJAX (qui d’ailleurs est un nom abusif dans ce cas ). Dans une version plus évolué de ce programme, il faudra passer à un retour JSON ou XML et bien gérer tous les cas d’erreurs côté client.

Enfin le formulaire de rechargement :

Le principe est simple : on recharge la partie de l’arbre qui est sous l’élément sélectionné :

    $('reloadForm').addEvent('submit', function(e) {
        new Event(e).stop();

        if (tree.selected != null) {
            node = tree.selected;
            node.load('/catalogue/xml/?node_path='+node.id);
        }

    });

Telechargement et Live Démo

Le serveur de chiroux.com n’est pas -encore- compatible python / Django, donc pour héberger la démo j’ai choisi de le mettre sur alwaysdata suite aux conseils de jehaisleprintemps.

Vous pouvez donc trouver la démo ici. Amusez vous bien.

L’admin est également disponible en suivant ce lien. Le login et pass sont : admin/admin

Vous pouvez télécharger l’archive d’un site django complet qui inclu cette seule application ‘catalogue’ ci-dessous (archive extraite du site de démo) :

Note: There is a file embedded within this post, please visit this post to download the file.

Remplacer mon tablet PC, oui mais par lequel ?

Thomas — Wed, 13 Jun 2007 23:03:00 +0000

Je commence sérieusement à envisager le remplacement de mon vieillissant Toshiba M200, mais aucun des produits actuellement disponible ne m’excite vraiment.
En attendant, je vais essayer de décrire mon futur tablet PC idéal (tout en essayant d’être un peu réaliste : je ne me contraint pas sur le prix, mais sur des technos existantes ou arrivant tout juste…)

Je vais essayer de classer dans l’ordre ce qui est le plus important pour moi et mon usage.

J’utilise mon tablet au bureau, constamment. Il remplace avantageusement mon bloc note papier depuis quelques années.

hybride ou sans clavier / form factor ?
- Cest la première question que je me pose. Mon expérience du M200 me fait dire que le clavier cest quand même vraiment pratique… mais il reste inutile dans environ 90% de mon temps dutilisation. En mode bloc-note, finalement il ne me sert quà mettre mes mots de passe pour délocker windows et pour mounter mon volume crypté (voir partie sécurité pour ce point).
- J’opterais donc pour un tablet SANS clavier afin de gagner en place et épaisseur, mais j’achèterais en plus un petit clavier bluetooth et/ou USB
l’écran
- La résolution élevée du M200 (1400×1050 sur un 12) me va parfaitement. J’ai eu l’occasion de tester et d’utiliser d’autres tablets en 1024×768 et je trouve que c’est trop faible. Depuis par contre, on voit arriver des écrans pour portables en 16/9 ou 16/10 genre 1280×800. J’ai peur que ce soit aussi un peu trop faible, mais mettons la limite à cette valeur.
- Conclusion : entre 12 » et 13 », mini 1280×800, idéal 1680×1050, ok en 1400×1050.
le processeur
- un core2 un peu puissant et low power comme le Santa Rosa serait parfait. Pas besoin a priori dune puissance absolue.
le disque dur
- Bon là, je n’ai pas à réfléchir longtemps : SSD !
- Je n’ai pas besoin d’une place folle, un SSD de 32Go serait suffisant, même si un 64Go ou un peu plus serait appréciable. Mais il est clair que pour des raisons d’autonomie, de perf et de solidité je préfère un SSD 32Go à un 2,5 ou 1,8 de 100Go ou plus.
RAM
- plein de RAM, surtout avec Vista, au moins 2gig, 4gig si possible, mais alors en Vista 64bits
batterie/autonomie/alimentation
- L’idéal serait d’avoir entre 8h et 10h de VRAIE autonomie en fonctionnement, en ayant activé les modes déconomies. Cela me permettrait de me promener en réunion uniquement avec le tablet et non avec tout l’attirail de câbles d’alimentations.
Sécurité
- Comme je l’indiquait plus haut, les moments où j’ai besoin du clavier sont principalement pour inscrire mes mots de passe. Donc il me parrait vraiment utile d’avoir un lecteur d’empreintes, mais couplé à un vrai bon soft qui me permette d’attribuer des mots de passes à dautres applications, de manière vraiment sécurisée. J’utilise notamment Truecrypt (http://www.truecrypt.org) pour mes données avec de belles passphrases. Je sais bien qu’utiliser le lecteur d’empreinte baissera mon niveau de sécurité, mais je vais gagner beaucoup en usabilité.
carte Video
- Le sujet prête à réflexion : je joue pas mal sur PC, mais en fait jamais avec mon tablet. J’aurais donc tendance à dire qu’une petite carte video, capable de décoder et d’afficher des films video en full screen/full résolution ainsi que faire tourner vista avec Aero est suffisante (pas besoin de fonction 3D avancée). Mais pour des raisons d’autonomie, il est peut-être souhaitable de ne même pas activer Aero en mode batterie.
autres fonctions et accessoires que je souhaiterais avoir dans ce Tablet :
- Tablet en techno wacom (of course !)
- wifi N
- bluetooth
- USB 2.0 : au moins 2, mais 4 serait mieux
- un ou des boutons hardware pour activer/désactiver wifi et bluetooth
Ce que je ne veux pas particulièrement :
- lecteur ou graveur DVD : je vis très bien sans avec mon M200 et comme cela permet de gagner place et poid, je préfère donc un tablet sans.

Bon c’est a peu près tout. Si vous voyez mon graal dans les magasins ou en annonce sur le net, n’hésitez pas à me prévenir ici !!

Ultimate Tag Cloud : un nuage de tags pour MODx

Thomas — Sun, 07 Jan 2007 17:59:52 +0000

Depuis que j’ai basculé sur Modx, j’avais envie de m’amuser avec les tags. J’ai d’abord utilisé directement le snippet tagcloud, puis ce week-end je me suis dit qu’on pouvait faire mieux, beaucoup mieux, à l’image de zoomclouds par exemple.

J’utilise sur ce site depuis le début le snippet TagCloud, et j’ai décidé de l’améliorer fortement.
Voici quelques unes de ces fonctionnalités :

Construction automatique, sans besoin de préciser des tags pour chaque page (compte les mots et les range par quantité)
Recherche récursive
Exclusion de mots ‘courants’ via des fichiers de langues (pour l’instant seul un fichier français a été réalisé)
Exclusion des caractères de contrôles via des fichiers de langues
Detection automatique des pluriels courants des mots et ‘fusion’ des mots singuliers et pluriels dans un même tag (tout au moins fonctionne en français)
Le rendu est paramétrable par templates (chunks ou fichiers) et css
Plusieurs tagClouds différents sont possibles sur une même page
Colorisation des mots, possibilité de nombre de couleurs différentes potentiellement illimité (nécéssite autant de configuration des css)
Possibilité de paramétrer lors du lancement un certain nombre d’éléments consititutif du nuage :
- nombre d’occurences minimales des mots à afficher
- nombre de lettre minimales pour un mot
- nombre total de mots maximum dans le nuage
- taille minimale de la police
- taille maximale de la police

Installation

L’installation est classique pour un snippet modx :

créez un répertoire UtagCloud dans le répertoire assets/snippets/ de votre site
copiez le contenu de l’archive dans ce UtagCloud
dans modx, créez un snippet nommé ‘UtagCloud’
copiez le contenu du fichier UtagCloud_snippet.php.txt dans le contenu du snippet
Ensuite dans une page, invoquez le snippet comme vous avez l’habitude de le faire (voir les exemples plus bas)

Paramètres

Voici l’explication des paramètres en français. Pour une explication en anglais, veuillez vous référer à l’entête du fichier UtagCloud_snippet.php.txt

&parent = liste des répertoires modx contenant des documents, séparés par une virgule. Si vous utilisez le paramètre récusif ci-après, vous pouvez mettre `0` dans parent pour parcourir tout le site.
&recursive = [ 0 | 1 ] : Détermine si UtagCloud scanne les répertoires et documents modx récursivement ou non.
&min = [ number ] : Nombre minimum d’occurence d’un mot afin qu’il soit affiché dans le nuage.
&landing = [ number ] : l’ID de page de résultat de la recherche : chaque clic sur un mot du tag générera une recherche (FlexSearch) et aboutira sur cette page de résultat. Si vous n’avez pas de page de résultat, créez en une avec à l’intérieur :
&minsize = [ number ] : Nombre de lettres minimale d’un mot pour qu’il soit affiché dans le nuage.
&wordsmax = [ number ] : Nombre maximum de mots du nuage. Indiquez zéro (`0`) pour un nombre illimité.
&fontmin = [ number ] : Taille minimum de la police de caractère en % (pour les mots avec la plus petite occurence).
&fontmax = [ number ] : Taille maximum de la police de caractère en % (pour les mots avec la plus grande occurence).
&lang = [ text ] : Paramètre de langue pour lire les fichiers d’exclusion.
&template = [ text ] : nom d’un Chunk ou d’un fichier dans templates/ qui sera utilisé pour affiche le contenu du nuage.
&css = [ text ] : nom du fichier css qui sera inclus au document. Pratique si vous utilisez styleid, pour séparer les styles différents de vos nuages.
&styleid = [ text | number ] : nouvelle instance de style (css) pour votre nuage. Permet d’avoir plusieurs nuages de style différents sur une même page.
&colors = [ number ] : nombre de couleurs différentes pour les mots du nuage.
&plural_letter = [ text ] : définit la lettre qui sert à mettre au pluriel les mots de façon la plus courante (en français c’est le ’s’). Permet de regrouper les mots singuliers et pluriels en un seul mot pour tout compter d’un coup. Si vous ne souhaitez pas utiliser cette fonctionnalité, définisez `#` comme valeur à ce paramètre.

Styles d’affichage (css)

UtagCloud utilise principalement deux classes de style, mais qui sont déclinable en fonction du styleid et du nombre de couleurs définies :

.Utagcloud_XXX : où XXX est le styleid (par défaut c’est `0`)
.Utagcloudtext_XXX_CCC : où XXX est toujours le styleid et où CCC est la couleurID

par exemple, si nous avons paramétré 5 couleurs, et que le styleid est celui par défaut, il faudra définir dans la css les styles suivants :

.UtagCloud_0 {} : pour le div contenant le nuage.
.UtagCloudtext_0_1 {} : pour le texte de couleur numéro 1
.UtagCloudtext_0_2 {} : pour le texte de couleur numéro 2
.UtagCloudtext_0_3 {} : pour le texte de couleur numéro 3
.UtagCloudtext_0_4 {} : pour le texte de couleur numéro 4
.UtagCloudtext_0_5 {} : pour le texte de couleur numéro 5

Ensuite, tout dépend du template et de ce que vous avez envie de faire. Vous pouvez par exemple avoir envie de paramétrer les :hover afin de changer le comportement quand on passe la souris.

Télécharger l’archive

Note: There is a file embedded within this post, please visit this post to download the file.

Changement du système de commentaires

Thomas — Sat, 30 Dec 2006 01:18:52 +0000

Suite à l’upgrade à la dernière version de Modx, j’ai décidé de changer de système pour les commentaires.
Je passe maintenant au module Jot!
L’avantage principal pour chacun est que vous pouvez maintenant poster un commentaire sans être enregistré dans le site.

Enjoy!

Informations complémentaires pour les ‘anciens’ posteurs : je n’ai pas pu migrer directement les anciens commentaires vers Jot.
Je les ai donc recrés directement, de ce fait j’ai perdu l’identifiant du posteur et la date.

Pour l’indentifiant, je l’ai remis en bas du post en signature.

Bon, il y en avait assez peu (c’est une des raisons de ma volonté de passer à un système plus ouvert), donc le travail n’était pas trop difficile.

J’en ai également profité pour ajouter un module d’automatisation des downloads, qui me permet notamment de les compter.
Par la suite, je pourrais aussi m’amuser à modifier un peu le template par défaut qui n’est pas très sexy.

Tutoriel pour un formulaire Ajax

Thomas — Tue, 23 May 2006 23:06:50 +0000

Ayant eu le besoin de réaliser un formulaire, j’ai choisi de tester un peu la techno Ajax et d’en mesurer les avantages et inconvénients

Introduction

Vous trouverez ci-dessous un petit tutoriel pour installer et utiliser un système de formulaires web utilisant la technologie AJAX, très facile et rapide d’installation et de configuration une fois que vous en avez compris les principes.

Le cahier des charges que je me suis fixé était le suivant :

faire un système de formulaire simple à implémenter
qu’il soit générique et ne nécessite quasiment pas de programmation pour implémenter un nouveau formulaire
que les validations soient réalisées au niveau serveur
que les informations de validation soient communiquées en temps réél au client
qu’il soit le plus sécurisé possible (notamment : impossibilité pour le client de passer outre les validations en modifiant les javascript par exemple)
en Php et Mysql
en séparant clairement fond et forme (xhtml 1.1)

J’ai commencé par tout coder directement manuellement, puis à force d’améliorations, je me suis orienté vers des librairies plus génériques : prototype et script.aculo.us.

Structure

Le formulaire est très simple, il s’appuie sur :

une table dans une base de donnée Mysql
une page php ‘backend’ qui réalise les validations et les updates en base
une page php ‘frontend’ qui affiche le formulaire

ci-dessous le schéma général, y compris les includes.

Logique générale

Le principe est de surveiller un événement sur les champs du formulaire (par exemple, focus, blur, keyup) et sur cet évènement on déclenche un appel Ajax vers la page en back office. On transmet à cette page l’id de l’enregistrement, le nom du champ qui est en train d’être mis à jour et sa valeur. La page en backoffice effectue la validation et si cette validation est ok, on l’update en base. Elle renvoie une structure XML avec les informations des actions réalisées et les messages d’erreur si nécessaire.

L’ID de l’enregistrement à mettre à jour est généré au début de l’appel de la page ‘formulaire’ et, afin de garder une persistence du formulaire non terminé, cet ID est stocké dans un cookie chez le client. Le cookie est effacé une fois le formulaire validé ou annulé (ainsi le client peut commencer à saisir un formulaire, fermer son navigateur, aller boire un café, partir en vacances.. et revenir le terminer quelques jours plus tard sans avoir perdu une seule information ; la seule contrainte de persistence est la durée de vie du cookie.

La page de backoffice effectue un traitement particulier lorsqu’elle reçoit l’ordre de validation complète du formulaire : elle repasse une validation de chaque champ, et vérifie également si tous les champs obligatoire sont présents. Si c’est ok, elle update en base, sinon renvoie une erreur.

Un peu plus de technique

Afin que le code html / php soit le plus propre possible, j’ai utilisé la fonction Event.observe de prototype afin de déclencher les observateurs d’évennements de mise à jour des champs du formulaire, ne vous étonnez donc pas de ne pas trouver de ‘onclick’, ‘onblur’, etc.. un peu partout dans le code, c’est normal, tout est géré dans le javascript init() dans formulaire.php. Ce script n’a pas besoin d’être paramétré lorsqu’on ajoute ou supprime des champs du formulaire : il scanne automatiquement tous les champs du formulaire et détermine les actions. Par défaut, les actions sont réalisées en keyup, c’est à dire que à chaque fois qu’on tape un caractère, on réalise l’appel AJAX. C’est peut-être un peu dangereux pour les performances de gros sites, vous pouvez alors par exemple remplacer les keyup par des blur.
Selon les types de champs du formulaire, on appelle une fonction spécifique située dans formulaire_backoffice.js qui a pour objet de récupérer le nom du champ et sa valeur afin de déclencher l’appel AJAX.
La fonction de call-back ajax interprête le XML de résultat et affiche l’erreur si nécessaire.

L’enregistrement en base est créé par le php la première fois qu’on appelle formulaire.php, ensuite, le cookie enregistré sur le poste client permet de garder le contexte.
A chaque modification d’un champ, l’appel AJAX lance une mise à jour du champ qui est en train d’être modifié. Avant la mise à jour, le php appelé par l’appel XMLHttpRequest fait d’abord une validation. Les validations sont gérées à l’aide d’expressions régulières, c’est donc assez facile d’ajouter d’autres types de validations plus évoluées (la fonction est dans inc_validation.php). Si la validation est ok, alors on update ce champ en base.

Une conséquence importante de ce mode de fonctionnement est ce que j’appelle la fonctionnalité ‘big brother’ : le formulaire enregistre tout : il suffit de venir au moins une fois sur le formulaire, commencer à le remplir. Même en ne le terminant jamais, il restera toujour un enregistrement en base reflétant ce formulaire à moitié rempli (toutefois, seuls les valeurs des champs qui passent la validation sont enregistrés en base).

L’appui sur ‘valider le formulaire’ fait également un simple update en base sur ce même enregistrement et passe le champ ‘formulairevalide’ à 1. Ainsi, on peut distinguer les formulaires terminés et validés (ils ont le champ ‘formulairevalide’ à 1) et ceux jamais terminé (le champ est alors à zéro).

L’appui sur ‘annuler’ efface simplement le cookie : l’utilisateur aura donc l’impression de repartir sur un formulaire vide, mais ce qui a été saisi dans le formulaire précédent est resté en base…

Pour les sites à fort taux de fréquentation, cette fonctionnalité peut éventuellement générer beaucoup d’enregistrements, il faudra peut-être prévoir une tache de ‘purge’ des formulaires non validés dont la date de dernière modification est trop ancienne par exemple.

Installation et Configuration

Installation

Téléchargez l’archive située en bas de cette page, dézippez cette archive dans un répertoire quelconque de votre site web (ex: http://www.monsite.com/formulaire/)

Création de la base de donnée

Pour l’instant, vous allez juste créer la base et l’utilisateur qui a le droit d’y accéder.
Si votre hébergeur ne vous laisse le droit qu’à une seule base, vous pouvez passer cette section, nous créeront la table plus tard.
Sinon, créez une nouvelle base du nom de votre choix (dans notre exemple : ‘formulaire’).
Créez ensuite un utilisateur mysql avec, au minimum, les droits d’accès SELECT, INSERT, UPDATE sur la base (vous pouvez choisir si vous le souhaitez, plus tard, une fois la table créée, de limiter ces grants à uniquement la table du formulaire)

Paramétrage des fichiers de configuration.

Il y a deux fichiers de configuration : un pour le côté client et un pour le côté serveur.
Commençont par le côté client :
Editez le fichier ‘parameters.js‘ :

gs_Base_url: indiquez l’utl d’accès de votre formulaire (dans notre exemple : http://www.monsite.com/formulaire/) [attention de ne pas oublier le slash (/) à la fin]
gs_Redirect_url: indiquez l’url qui sera appelée à la fin de la validation de votre formulaire (dans notre exemple, on retourne à la home page : http://www.monsite.com/
gs_Cookie_name: indiquez le nom du cookie qui sera stocké sur le poste client (dans notre exemple : formulaire)
gl_Cookie_time: on indique la durée de vie de ce cookie. Par défaut elle est de 30Jours après la date de création.

Editez ensuite le fichier ‘inc_parameters.php‘ :

dans $DBnombase, indiquez le nom de la base que l’on a créé tout à l’heure (ou le nom de la base donnée par votre hébergeur)
dans $DBnomtable, indiquez le nom de la table que l’on créera ensuite (dans notre exemple : t_formulaire)
dans les paramètres de mysql_connect, indiquez où se situe votre serveur (ici : localhost) et le login et password de connexion à la base (ici : login et password)
dans $gs_Cookie_name et $gl_Cookie_time indiquez exactement les même valeurs que ce que vous avez paramétré dans parameters.js

Personnalisation du formulaire

Il est temps maintenant de définir le contenu des champs du formulaire, pour cela, Editez le fichier ‘formulaire.php‘ :

Paramétrage généraux de la page

Choisissez un titre à l’intérieur des tags (dans le Head)
Dans le
- Laissez tel que le
- Entez un titre dans les tags
- Mettez le texte que vous voulez devant le formulaire (en utilisant les classes de style ‘explication’ et ‘question’)

Le formulaire

Organisation générale

Les éléments du formulaire sont organisés par groupe, un groupe est un ensemble de champs du formulaire à l’intérieur d’un

Les fieldset sont des éléments de présentation, vous pouvez choisir de mettre tout le formulaire dans un seul fieldset ou à l’opposé de faire un fieldset par champ à remplir, c’est votre choix.
Dans le formulaire par défaut, je montre quelques exemples différents.

Chaque fieldset doit avoir une légende qui est représentée par les tags

la classe « noerreur » : chaque élément de formulaire (input, checkbox, radio, etc..) doit être encadré par un div de classe « noerreur ». Cette classe sera changée dynamiquement en classe « erreur » en cas de pb de validation de cet élément de formulaire.

Principe de l’organisation des champs du formulaire

Ce principe est un des points les plus structurant de ce formulaire, revenons donc sur un des élements de mon cahier des charges : « impossibilité pour le client de passer outre les validations en modifiant les javascript ».

D’habitude, dans la plupart des formulaires classiques, on réalise une validation en javascript du côté du client (par exemple la vérification : est-ce qu’un email est bien un email). Bien sûr cette validation n’est pas suffisante, car il suffit d’interdire les javascripts pour passer outre la validation. Donc les formulaires un peu plus évolués (tous devraient le faire) doublent cette validation javascript par une validation côté serveur. Mais encore une fois, il faut bien passer les paramètres de validation au serveur. Pour un formulaire non AJAX, cela se fait par exemple dans les infos de POST. J’aurais pu également faire la même chose et simplement éviter le POST et le rechargement de page en utilisant XMLHttpRequest. Mais rien n’empèche non plus une personne mal intentionnée de recopier le formulaire sur un poste local, d’en changer les paramètres et d’appeler le script serveur avec d’autres types de validation (changer une validation email en simple validation txt par exemple).

J’ai donc choisi de passer les paramètres de validation directement dans le nom des champs du formulaires. Et ce sont ces même noms qui structurent la table d’enregistrement de la base de donnée. Ainsi si une personne mal intentionnée cherche à changer une validation, elle doit changer le nom du champ et même si la validation passe, l’enregistrement en base de donnée ne passera pas.

Cette solution est plus sécurisante, mais elle a l’inconvénient de générer des noms de champs un peu compliqués et peut-être un peu compliqué à faire évoluer (dans le cas de nouveau types de validation par exemple qui nécessiteraient de nouveaux paramètres).

Les noms des champs ont donc une structure qu’il faut respecter, en voici les règles :

Structure du nom du champ

La Structure du champ est la suivante : ttt_x_y_z_mmm

ttt : représente le type du champ, il peut prendre les valeurs suivantes :
- num : numérique entier
- real : numérique à virgules
- tel : téléphone (français)
- date : date de type JJ/MM/AAAA
- cp : code postal
- email : email
- txt : texte libre
x : prends deux valeurs possibles :
- m : mandatory (champ obligatoire)
- o : optionnal (champ optionnel)
y : nombre de caractères minimum : valable uniquement pour les type de champs txt et email, mettre 0 dans les autres cas
z : nombre de caractères maximum : valable uniquement pour les type de champs txt et email, mettre 0 dans les autres cas
mmm : nom du champ

exemples :

txt_m_1_100_nom : nom est un champ texte obligatoire qui doit comporter entre 1 et 100 caractères
email_m_4_50_couriel : couriel est un champ de type email obligatoire qui doit comporter entre 4 et 50 caractères
num_o_0_0_quantite : quantite est un champ numérique entier optionnel
etc…

type de champ et type de formulaire

Voici les associations que vous pouvez utiliser sans risque entre les types de champs du formulaire et les champs en html :

input type = « text » : num | real | tel | date | cp | email | txt
textarea : num | real | tel | date | cp | email | txt
input type = « checkbox » : num
input type = « radio » : num
select : num | txt (dans l’absolu, même si c’est moins logique : num | real | tel | date | cp | email | txt)

Dans l’archive, vous trouverez un exemple de chaque cas d’input afin de vous permettre de copier/coller ce qui vous interesse.
Attention : il y a une petite subtilité avec les input radio : le champ ‘name’ doit avoir la même valeur pour tout les inputs radio du même groupe (ainsi donc que l’appel de la fonction php ‘RecupereValeur’ qui doit avoir ce même champ name comme paramètre). Par contre, les champs ‘id’ doivent être uniques (même un numéro incrémental en plus du name par exemple), ceci afin de faire correspondre l’id de l’input et le label associé.

Création de la table dans la base de donnée

La table a quelques colonnes obligatoires :

idformulaire : la clef principale de la table : un id incrémental
idsession : la valeur du cookie qui sert à garder la persistence du formulaire
datecreation : la date de la première insertion de l’enregistrement
datemodification : la date de dernière modification de l’enregistrement
adresseIP : l’adresseIP du poste client qui a inscrit le formulaire
formulairevalide : est-ce que le formulaire est validé par l’utilisateur (la valeur est a zéro tant que le formulaire n’est pas terminé)

Les autres colonnes représentent exactement les noms des champs input de votre formulaire
(ex : `txt_m_1_100_nom` varchar(100) NOT NULL default » qui correspond à l’imput ‘nom’ de votre formulaire). Notez bien que le nom du champ doit être exactement le même que le paramètre ‘name’ de l’inputField.

Regardez le fichier table.sql dans l’archive d’exemple pour plus de détails.

La Forme

Toute la forme est gérée dans la feuille de style (style.css)
L’objet de cet article n’est pas de faire un détail sur les feuilles de style : l’utilisation des styles pour ce formulaire est très simple. N’hésitez pas à aller faire un tour sur Alsacréations par exemple, un excellent site français qui vous apprendra un tas de choses très pratiques sur les css et sur bien d’autres choses.

Conclusion / Reste à faire

J’espère que ce petit formulaire et ce tutoriel pourront vous aider dans vos projets. En tout cas, sentez vous libre de l’exploiter, le modifier, l’améliorer, le triturer. Si toutefois vous avez réalisé des améliorations, rencontré des bugs, souhaitez des améliorations, n’hésitez pas à m’en faire part en utilisant les commentaires ci-dessous.
Ce formulaire est encore très incomplet et il reste pas mal de choses à faire si on voulait le rentre véritablement professionnel. Voici une petite todoList qui résume les points à améliorer :

être tolérant aux browser qui n’ont pas XMLHttpRequest (revenir en mode post classique par exemple)
faire un système de validation multichamps (par exemple n checkbox doivent être coché parmi n)
faire évoluer les messages d’erreur :
- afficher l’erreur de validation directement à côté du champ (paramètre optionnel par exemple)
- afficher le faire que le champ est obligatoire ou non
faire un système d’auto config (wizard ?) / d’install plus simplifié

Live Demo

J’ai mis en ligne le formulaire de démo situé dans l’archive, vous pourrez le retrouver en suivant ce lien.

Télécharger l’archive

Note: There is a file embedded within this post, please visit this post to download the file.

Réalisation d’un phare de plongée à LED

Thomas — Tue, 14 Aug 2001 15:02:40 +0000

Vous trouverez ci-dessous commentaires et avancée sur la construction de la lampe.

Schéma Logique

Dans un premier temps, je me suis attaché à réaliser un circuit simple, mais fonctionnel qui me permette de réaliser rapidement des premiers tests en réel.

Afin de délivrer du 5V constant quelle que soit la source, il est nécessaire d’utiliser un régulateur de tension. Pour cela, j’ai choisi d’utiliser un L7805CV, dont vous trouverez le datasheet ici.

En respect de ce datasheet et pour assurer une bonne régulation, il faut ajouter un condensateur de 0,33 µf et un condensateur de 0,1 µf.

En sortie du régulateur, on retrouve le schéma de principe simple : 23 couples résistances/led en parallèle.

Voici le schéma logique (cliquez dessus pour agrandir) :

Vous devez vous demander pourquoi 23 Leds et pas 24 puisqu’il me reste une connexion de libre en sortie de RSX2. La raison est purement "geographique" : lors de la création du PCB (routage et circuit imprimé), je me suis limité à un certain diamètre pour y mettre les leds, et il n’y avait pas moyen d’en mettre 24. Il y en aura donc 23. Cela ne devrait pas avoir d’impact fort sur la luminosité.

Tests en banc d’essai

L’étape suivante est la simulation de ce circuit. Je suis donc parti acheter les composants nécessaires, en particulier les LEDS.

J’ai acheté le tout chez Conrad à Lille. Les références des composants sont les suivants (les pages sont celles du catalogue 2002) :

Composant	Valeur	Ref Conrad	Prix	Qté	Prix Tot
C1	330 nf	0458 104-17 (p418)	0,53€	1	0,53€
U1	L7805CV ou CT	0175 030-17 (p430)	1,36€	1	1,36€
C2	100 nf	0455 270-17 (p418)	0,30€	1	0,30€
RSX1, RSX2, RSX3	100 Ohm	0414 077-17 (p411)	0,50€	3	0,50€
LED blanche 5600mcd	20mA à 3,6 V	0153 745-17 (p442)	3,11€ (par 10)	23	71,53€
TOTAL					74,22€

Pour les resistances, il vaudrait mieux 70 ohm pour utiliser au max les leds, mais je n’en ai pas trouvé. Une autre solution est d’utiliser un 7806 au lieu du 7805. Des tests seront réalisés prochainement.

En attendant, voici le circuit sur plaquette d’essai (cliquez dessus pour agrandir) :

Et voici, vu du dessus le circuit allumé (cliquez pour agrandir) :

Le circuit fonctionne bien, mais je trouve que le 7805 chauffe énormément. Il apparaît indispensable d’y mettre un radiateur : en quelques minutes, la température extérieure du 7805 monte à plus de 70°.

Par contre, grâce (ou à cause) des résistances à 100 ohm, les LEDs ne sont pas utilisées à leur maximum, la consommation globale est donc relativement faible :

285 mA pour 23 leds, soit une moyenne rapporté à la LED de 12,39 mA. C’est aussi pourquoi j’ai choisi de continuer mes tests en alimentant principalement à 9V car j’ai bien l’intention d’utiliser une ou deux batteries 9V dans cette première version de lampe : avec 2 batteries 9V, on peut compter à priori sur au moins 1 heure d’autonomie.

Circuit physique

Le circuit n’est pas encore gravé, mais voici le schéma d’implémentation physique des LEDs : j’ai chercher à limiter la taille du circuit imprimé à un diamètre de 50mm.

Actuellement, le diamètre total du circuit fait 45,5mm et le diamètre "intérieur" (celui délimité par les LEDs), fait 34,5mm, ce qui laisse la place pour mettre un petit cône réflecteur que je compte découper d’une lampe allogène de 50mm de diamètre.

Construction

Pour fabriquer cette lampe, j’ai utilisé des tuyaux de plomberie en PVC de diamètre 63mm, acheté chez Casto.

Il faut :

2 bouchons à vis de 63mm
1 manchon de raccordement pour tuyaux 63mm
1 bout de tuyaux 63mm (j’ai du acheter un tuyau d’1m pour en couper un bout)
1 collier pour tuyaux 63mm
1 plaque de plexiglas cristal (transparent) d’épaisseur 4mm
de la colle ultra forte pour PVC
du silicone (comme pour les joints de salle de bain)

Comme outils, prévoir :

une scie pour découpes de précision (lame très fine pour pouvoir faire des tournants)
une dremel avec outils de découpe, de fraisage et de ponçage.
un compas
…

Voici un schéma en vrac des tuyaux (cliquez sur l’image pour agrandir) :

La première chose à faire est de découper un trou circulaire dans un des bouchons. Ce trou fera la taille exacte du diamètre formé par les Led sur le circuit imprimé. Attention de laisser suffisamment de bord pour pouvoir coller par la suite la plaque de plexiglas qui servira de vitre.

Il y a un truc très pratique avec ces bouchons en PVC c’est que le diamètre intérieur n’est pas le même d’un côté et de l’autre du bouchon. Ainsi, il suffit de bien couper le circuit imprimé afin qu’une fois enfoncé dans le bouchon, les Led affleurent le bord du trou. Le circuit est naturellement bloqué par le rétrécissement du diamètre à l’intérieur du bouchon.

Ensuite, mesurer le diamètre exact bord à bord du creux du bouchon, tracer un cercle du diamètre correspondant sur la plaque de plexiglas et découper le disque de plexiglas qui sera collé sur le bouchon (photos à venir).

Maintenant, attaquons nous au corps de la lampe. On pourrait se contenter de mettre les bouchons de chaque côté du raccord et de coller, et le tour est joué. Mais j’ai préféré rigidifier un peu la structure en insérant au milieu un morceau de tuyau. Ainsi, il y a une double épaisseur de paroi : le manchon + le tuyau à l’intérieur. Cela a deux avantages : l’intérieur est uniformément lisse et je peux "creuser" dans ce bout de tuyau central une fente dans laquelle je vais placer le relais ILS qui servira à allumer la lampe (photos à venir).

Dans le manchon, il est possible qu’il y ait 3 petits ergots en plastique au milieu, initialement prévu pour bloquer les tuyaux que l’on raccorde. Pour pouvoir placer mon morceau de tuyau au milieu du manchon, il faut enlever ces ergots. Utiliser un outils de ponçage grossier de la dremel pour les enlever.

Voici ci dessous les trois éléments qui vont venir s’encastrer dans le manchon, ainsi que le manchon.

Pour le relais ILS, avec ma dremel et un disque de découpe, j’ai creusé une fente horizontale (en se référant à la photo ci dessous), et j’ai placé le relais dans cette fente. Une fois glissé le bout de tuyau au centre du manchon, le relais sera donc séparé de l’extérieur par juste une épaisseur de tuyau.

Il reste à monter la lampe entièrement. Pour l’instant elle n’est pas encore collée (c’est pour demain normalement).

Voici toutefois une idée du résultat finit ainsi qu’une idée de la taille en la comparant à la canette :

La lampe n’est donc pas encombrante et la prise en main est bonne.

Le rôle du collier n’est pas neutre : il sert d’interrupteur : sur la partie haute du collier, là ou il y a une partie circulaire, j’ai encastré un aimant, côté intérieur. Pour allumer ou éteindre la lampe, il suffit de tourner ce collier autour du corps de la lampe. On ne le voit pas sur la photo, mais une sorte de poinçon en relief sur le manchon bloque la rotation du collier, donc il tourne d’environ 1/4 de tour, ce qui est parfait pour un interrupteur. Il reste juste à coller un guide sur le corps pour éviter que le collier puisse glisser de haut en bas. De plus, il est possible d’utiliser le haut du collier pour mettre une poignée par exemple.

Attention de bien placer le morceau de tube à l’intérieur, de telle façon que le relais ILS soit juste en face de l’aimant lorsque la bague est bloqué d’un côté par le "poinçon" situé sur le manchon.

Collage

J’ai utilisé de la colle Araldite pour coller les différents éléments. C’est a priorio la colle la plus forte que j’ai pu trouver. Elle est séparée en deux tubes, que l’on mélange à l’aide d’une spatule.

Attention : il faut obligatoirement mettre des gants de protection, cette colle est assez dangereuse au toucher, surtout pour des personnes comme moi qui sont sujettes à diverses allergies.

Une fois le produit mélangé, on a juste 4 minutes pour l’étaler sur les deux surfaces. Je vous conseille également de passer un peu de toile émeri sur les surfaces pour les rendre plus rugueuses.

Alimentation électriques

Grâce au régulateur, on peut mettre en entrée n’importe quelle source électrique entre 7V et 20V environ. A l’origine, je pensais mettre 2 piles 9V afin d’avoir environ 1 H d’autonomie (150 mAh par pile pour 300 mA de conso).

En fin de compte, j’ai utilisé un bloc de 6 piles (acheté 7 F chez Conrad) et j’y ai mis des piles AA NiMH 1,2 V de 1700 mAh. J’ai donc 1700 mAh max, soit entre 5 et 6 heures d’autonomie théorique. Le prix d’une pile de ce type est de 30 FF TTC chez Conrad, au rayon modélisme.

Je n’ai pas encore pu valider cette autonomie par manque de temps, mais j’ai déjà validé plus de 2H d’autonomie.

Le bloc de 6 piles 1,2V délivre 7,2V, ce qui est également plus optimal en terme de dissipation électrique. J’arrive à une efficacité d’environ 50%, ce qui reste bien sûr très faible, mais comme je l’ai déjà dis, le but de cette première version n’est pas d’optimiser l’efficacité, d’autant plus que j’ai déjà ici largement suffisamment d’autonomie pour faire une journée de plongée, même à 3 plongées par jour.

Il est toujours possible bien sûr de mettre des piles AA normales dans ce bloc en backup, ou même une pile 9V.

Test en baignoire

J’ai placé la lampe plusieurs heures dans ma baignoire, en l’ayant préalablement bourrée de sopalin. En la ressortant, aucun problème, le sopalin était parfaitement sec. Par contre, comme je n’ai pas trouvé de joints toriques à la taille des pas de vis des bouchons, j’utilise encore les joints plats en caoutchouc livrés avec.

J’ai un peu peur du comportement de ces joints à plus grande profondeur. J’espère encore trouver des joints toriques à la bonne taille (ou en rouleau comme j’ai pu voir dans un autre site)

Test en grandeur nature

Je viens de passer une semaine (du 22 au 29 septembre 2001) à Saint Raphaël. J’ai plongé au C.I.P. de Port Frejus, centre de plongée très sympa et très sérieux.

Ma première plongée a eu lieu le dimanche matin. Juste après la mise a l’eau, j’essaye d’allumer la lampe, mais sans succès…sniff.. alors que je venais de la tester sur le bateau. Donc je prends ma petite lampe de backup (une Mares Lucilla) et je continue la plongée. Nous sommes descendus à 27,7m. Vers la fin de la plongée, je trouvais bien que ma Lucilla n’éclairait plus très bien, mais je n’avais pas vérifié les piles. Malheureusement, ce n’était pas sa : ma lucilla a pris l’eau et elle est foutue. [bravo à décathlon qui me l'a reprise sans aucune discussion].

En remontant, j’ai checké la lampe à led ; déjà une bonne nouvelle : elle n’a pas pris l’eau. En l’ouvrant, j’ai vite vu le problème : une des 6 piles AA du bloc s’est décrochée et donc il n’y avait plus de contact. Donc, pour remédier à cela avec les moyens du bord, j’ai mis un gros élastique très serré autours du bloc de piles afin d’éviter qu’elles se décrochent suite aux chocs et aux mouvements.

Au total, j’ai fait 8 plongées dans la semaine, sans aucun soucis d’étanchéité et sans jamais recharger les 6 piles NiMh (c’était un test volontaire, et j’avais racheté une lampe du style de la lucilla en backup). Je suis descendu au max à 33m et la plupart des plongées étaient dans la zone des 30m.

Par contre, au niveau éclairage, ce n’est pas vraiment l’idéal. Il n’y a pas vraiment de faisceau lumineux, l’éclairage en "plein jour" n’est vraiment pas efficace.

Les seuls cas où la lampe est efficace, c’est dans les trous : en éclairant l’intérieurs des trous et cavités, qui eux sont normalement très sombre, on voit bien une réelle différence et un éclairage très blanc comparé aux phares des autres plongeurs de la palanquée. N’ayant pas fait de plongée de nuit, je ne sais pas si cela marcherais mieux, mais j’estime que oui.

Il faut donc que je travaille à améliorer l’efficacité de la lampe ; je vais donc continuer ce site en travaillant sur différentes pistes d’amélioration et de moyens me permettant de mesurer "scientifiquement" ces améliorations en plein air.

Cette première version de lampe a permis de valider l’aspect mécanique de la lampe, l’étanchéité, la validité du système d’allumage qui fonctionne à merveille, l’ergonomie de la lampe (la taille, le poids sont vraiment pratique).