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]

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)

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

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

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.

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

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.

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

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)

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)

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)

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)

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 est constitué de deux parties :
le div qui va recevoir l’arbre :

<div id="mytree_catalogue">
</div>

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 :

<div id="boite1" class="form_div">
    <input type="button" value=" expand all " onclick="tree.expand()" />
    <input type="button" value=" collapse all " onclick="tree.collapse()" />
</div>
<div id="boite2" class="form_div">
    <form id="insertForm" action="/catalogue/insert/" method="post" name="insertForm">
        <input type="text" value="" name="node_name" /><br />
        <input type="hidden" value="" name="to_item" />
        <input type="hidden" value="before" name="insert_type" />
        <input type="submit" value=" insert before" name = "button" onclick="$('insertForm').insert_type.value='before';" />
        <input type="submit" value=" insert after" name = "button" onclick="$('insertForm').insert_type.value='after'; " />
        <input type="submit" value=" insert inside" name = "button" onclick="$('insertForm').insert_type.value='inside';" />
    </form>
</div>
<div id="boite3" class="form_div">
    <form id="deleteForm" action="/catalogue/delete/" method="post" name="deleteForm">
        <input type="hidden" value="" name="node_path" />
        <input type="submit" value=" delete selected " name= "button" />
    </form>
</div>
<div id="boite4" class="form_div">
    <form id="updateForm" action="/catalogue/update/" method="post" name="updateForm">
        <input type="text" value="" name="node_name" />
        <input type="hidden" value="" name="node_path" />
        <input type="submit" value=" update selected " name= "button" />
    </form>
</div>

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

    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.

    $('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.

    $('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.

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);
        }

    });

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

Neuf, avec la NB4, propose un routeur évolué et ouvert. Une petite API permet notamment d’interroger la NB4 et de récupérer les valeurs de différents paramètres en temps réél. Il n’y avait qu’un petit pas à franchir pour l’utiliser et afficher ces paramètres directement dans notre PC.

Etant sous vista sur mon PC ‘principal’ (celui sur lequel je joue..), c’est tout naturellement que je me suis orienté sur cette plate-forme pour faire ce gadget. (Je vous rassure, tous mes autres PC sont sous linux Il doit être possible avec un minimum d’adaptation de le faire fonctionner sous mac ou sous d’autres outils style konfabulator (Yahoo widgets). Nous verrons cela peut-être dans une prochaine version.

[Je suis curieux mais paresseux et je voudrais tester tout de suite : envoyez moi directement au téléchargement]

Construire un gadget vista c’est assez simple : il suffit de placer les bons fichiers dans un répertoire.
Les tutos officiels se trouvent ici : http://gallery.live.com/devcenter.aspx

il nous faut donc au minimum :

• un fichier gadget.xml, dans lequel nous allons décrire notre gadget
• un fichier html, dont le nom est décrit dans le xml ci-dessus
• un fichier d’icône (optionnel)
• un css si on veut que ce soit joli

A ce jour, dans la version de dev actuelle, le gadget permet d’afficher deux type d’informations :

• des infos de type booléennes (on/off, oui/non, etc…) sous la forme (par défaut dans l’exemple) d’un petit feu rouge ou vert (mais vous pouvez mettre les graphismes que vous souhaitez)
• des infos ‘historiques’ (un graphique historique) basé sur des valeurs numériques retournées par la NB4

Dans l’exemple, le gadget va chercher le status du lien DSL, le status du PPP, le status du wifi, ainsi que l’évolution du rapport signal/bruit de votre ligne :

(Oui, il est moche, je sais, mais je suis assez nul en design et graphisme, je laisse ça aux spécialiste… le but est avant tout de démontrer la faisabilité de ce gadget. Si vous vous sentez l’âme d’un artiste, n’hésitez surtout pas

Le gadget est encore loin d’être terminé. Il manque tout particulièrement les écrans d’options qui permettrait à l’utilisateur lambda de choisir parmi une liste de paramètre ceux qu’il souhaite monitorer.
Il faut pour cela construire les écrans de settins du gadget (ce qui n’est pas très compliqué en soit), mais également rendre plus générique un certain nombre d’éléments (comme les images on/off par exemple).
J’ai souhaité quand même publier cet article avec ce qui avait déjà était fait, cela permettra aux plus bidouilleurs d’entre vous de continuer ou de partir sur d’autres orientations. Les grands principes sont là en tout cas.

Comme d’habitude, j’utilise mootools comme librairie javascript, elle va notamment nous servir à réaliser les appels asynchrone vers la NB4 et récupérer les résultat à afficher.

Regardons maintenant un peu le contenu des fichiers :

Pas grand chose à dire sur ce fichier, on doit y updader le numéro de version, pointer sur le bon fichier d’icône et le bon fichier html. Les tutos microsofts sont assez clairs sur les contenus possible de ce fichier.

<?xml version="1.0" encoding="utf-8" ?>
<gadget>
    <name>Neuf Box 4 DEV</name>
    <namespace>neuf.fr</namespace>
    <version>0.9.2</version>
    <author name="Thomas Chiroux">
        <info url="www.chiroux.com" />
    </author>
    <copyright>2007</copyright>
    <description>Etat de la NeufBox</description>
    <icons>
     <icon height="128" width="69" src="icon_dev.png" />
   </icons>
    <hosts>
        <host name="sidebar">
            <base type="HTML" apiVersion="1.0.0" src="NB4.html" />
            <permissions>full</permissions>
            <platform minPlatformVersion="0.1" />
        </host>
    </hosts>
</gadget>

C’est le fichier html qui est appelé par le moteur de gadget de vista et qui est rendu à l’écran. Il est lui aussi assez simple, car tout se fera dans le javascript.
Dans le fichier html, il faut placer les div des éléments qu’on souhaite afficher, dans l’ordre qu’on souhaite :

		<div id="ADSLStatus" class="NB4OnOff"> </div>
        <div id="PPPStatus" class="NB4OnOff"> </div>
        <div id="WlanStatus" class="NB4OnOff"> </div>
        <div id="HistoGraphSNR"><div id="SNRValue">  </div></div>

Nous avons donc ici 4 éléments : 3 éléments de type ‘NB4OnOff’ et un élément de type ‘Histo’.

C’est le fichier le plus important et c’est là que tout est fait aujourd’hui. Il est importé par NB4.html, juste après mootools.

Il est en gros composé de 2 parties :

• la définition des 2 classes (NB4OnOffClass et NB4HistoGraphClass) actuellement disponibles. Ces classes sont indépendantes de la structure ‘gadget’ et pourraient être réutilisée dans d’autres contextes
• le code javascript qui permet de gérer le gadget, notamment son initialisation

Passons d’abord sur le code ’spécial gadget’ et sur l’initialisation. Les plus courageux pourront ensuite creuser le code des classes :

NB4.html, au chargement de la page, commence par lancer initGadget() :

initGadget() fait 2 choses :
Initialiser la gestion des évènements lié à la mise en dock (la barre de gadget) et à l’opération inverse (le dé-dockage ?) :

function initGadget() {
    // variables globales
    if (!DEBUG_BOUCHON)
      gDockFlag = System.Gadget.docked;
    gAjaxWorking = 0;

    // Initialise les évènements de Dock et UnDock
    if (!DEBUG_BOUCHON) {
      System.Gadget.onUndock = procUndockEvent;
      System.Gadget.onDock = procDockEvent;
    }

Donc ici, si le gadget revient dans sa barre, la fonction ‘procDockEvent’ sera exécutée et si il en sort, c’est la fonction ‘procUndockEvent’ qui le sera. Le principe et le fonctionnement de ces fonctions est assez bien décrit dans les exemples de microsoft. En gros elles s’occupent de redimentionner la fenêtre d’affichage pour que tout soit parfaitement affiché).

(ne vous préoccupez pas pour l’instant du ‘DEBUG-BOUCHON’, on en parlera dans la partie plus détaillée sur le développement)

Ensuite et c’est le plus important, cette fonction initalise les objets d’interrogations de la NB4 :

    objADSLStatus = new NB4OnOffClass('adsl_status', 'ADSLStatus', 'NB4_ADSL_On.png', 'NB4_ADSL_Off.png',5000);
    objPPPStatus = new NB4OnOffClass('ppp_status', 'PPPStatus', 'NB4_PPP_On.png', 'NB4_PPP_Off.png',5000);
    objWlanStatus = new NB4OnOffClass('wlan_active', 'WlanStatus', 'NB4_WIFI_On.png', 'NB4_WIFI_Off.png',5000);
    objSNRValue = new NB4HistoGraphClass('adsl_noise_down', 'SNRValue', 'SNR', 32, 'barre.gif', 10000);

Pour le ’simple’ utilisateur, c’est tout, il n’y a rien d’autre à faire que de changer ces valeurs. (plus tard, dans une version ultérieure, il y aura des écrans de paramétrages pour éviter d’avoir à toucher le code).

Prenons la première ligne et détaillons les paramètres :

• le premier (‘adsl_status’) est le nom du paramètre de la NB4. Attention il doit être exact, sinon la NB4 ne renvoie rien (plus exactement, elle renvoie ‘=’)
• le second (‘ADSLStatus’) est l’ID du <div> dans le code html qui va afficher le contenu
• les troisième et quatrièmes (‘NB4_ADSL_On.png’, ‘NB4_ADSL_Off.png’) sont les images à afficher (qui s’afficheront dans le div ci-dessus) lorsque les valeurs récupérées sont respectivement on ou off (ou up ou down, etc..)
• le cinquième et dernier (5000) est la fréquence de rafraichissement (en ms) : ici il est paramétré à 5s, donc cet objet ira interroger la NB4 toute les 5 secondes.

Donc si vous voulez interroger un autre paramètre de type ‘On/off’ dans la NB4, il faut changer une de ces valeurs par une autre et si vous voulez le faire clean, il faut adapter le nom de l’objet et celui du div dans le code html en fonction du paramètre choisi.

Ces deux classes sont construites sur des principes communs :

1. initalisation des paramètres
2. gestion d’un timer pour les interrogations régulières
3. appel de la fonction de la neufBox en AJAX (en utilisant les fonctions de mootools)
4. récupération et traitement du résultat
5. Mise à jour de l’affichage du gadget en fonction du résultat obtenu

Cette classe est la plus simple, son objectif est de récupérer une valeur de type ‘on’ ou ‘up’ ou encore ‘off’ ou ‘down’ venant de la NB4 et d’afficher l’image correspondante.

D’abord on va initaliser les variables de la classe avec des valeurs par défaut :

var NB4OnOffClass = new Class({
  c_parameterName : null,
  c_elementName : null,
  c_onOff : 0, // OFF par défaut
  c_oldOnOff : -1, // la valeur précédent du test onOff (au début -1 pour initialiser)
  c_imageON : null,
  c_imageOFF : null,
  c_time : 0,
  c_intervalTime : 0,
  c_timer : null,
  c_stoptimer : 0,
  c_urlNB4 : null,

Voici ensuite le constructeur : il est appelé lors de l’instanciation de la classe :
il va prendre les paramètres que l’on a choisi :

initialize: function(parameterName, elementName, imageON, imageOFF, delais){  // Contructeur

, les stocker au sein de la classe :

this.c_parameterName = parameterName;
    this.c_elementName = elementName;
    this.c_imageON = 'images/' + imageON;
    this.c_imageOFF = 'images/' + imageOFF;
    this.c_intervalTime = delais; // durée de rafraichissement
    var date = new Date();
    this.c_time = date.getTime();
    if (DEBUG_BOUCHON)
      this.c_urlNB4 = DEBUG_URL;
     else
      this.c_urlNB4 = 'http://192.168.1.1/kit/get'; // ici on met la valeur en dur car elle sera a terme stockée dans les params du gadget

et lancer une première mise à jour :

    // Aller chercher la valeur dans la NB4
    this.Update();
    }

La fonction update fait 3 choses :

• Affiche la petite icône typique des appels ajax dans le coin du gadget
• Remet à zéro le timer
• Lance l’appel AJAX (en méthode POST, avec en paramètre la valeur cherchée et en forçant l’encodage à vide (en utf-8 la NB4 ne renvoie rien)

Dans l’appel AJAX, nous avons définit la fonction de call back qui sera appelée lors du retour de la valeur (l’appel est asynchrone) : onComplete: this.callbackAjaxok.bind(this)
C’est donc la fonction callbackAjaxok de cette classe qui sera lancée au retour de la NB4

    Update: function() {
      gAjaxWorking += 1;
      $('AjaxIndicator').style.display = 'block';
        var date = new Date();
      this.c_time= date.getTime();
    new Ajax(this.c_urlNB4,{data:'name='+this.c_parameterName, onComplete: this.callbackAjaxok.bind(this), method: 'post', encoding: ''}).request();
  },

Cette fonction est donc appelé au retour OK, je laisse mootols gérer les cas d’erreur : dans notre gadget si il y a des erreurs, rien ne sera affiché.

Dans l’ordre cette fonction fait les choses suivantes :

• stoppe l’affichage de la petit icône ‘appel ajax en cours’
• récupère la valeur de retour et positionne le status de la classe en fonction de ce retour
• si la valeur a changé depuis la dernière fois, réaffiche l’image dans le gadget en fonction de la nouvelle valeur
• vérifie le temps écoulé et prépare le prochain update : soit immédiatement si l’intervalle de temps est déjà écoulée, soit plus tard (via la fonction delay) si le temps n’est pas encore écoulé. L’appel à update refait une boucle et ainsi de suite.

  callbackAjaxok: function(obj) {
    // ici récupère la valeur du paramètre on/off et le stocke dans c_onOff
    gAjaxWorking -= 1;
    if (gAjaxWorking==0) {
         $('AjaxIndicator').style.display = 'none';
      }

    if ($type(obj)=='string') {
      var lvalue = obj.split('=')[1].clean().toLowerCase();
      if (lvalue=='up' || lvalue=='on') {
        this.c_onOff=1;
      } else {
        this.c_onOff=0;
      }
      if (this.c_oldOnOff != this.c_onOff) {
          this.GetHTMLOutput();
      }
      this.c_oldOnOff = this.c_onOff;
    }
    if (!this.c_stoptimer) {
      var date = new Date();
      var currentIntervalTime = date.getTime() - this.c_time;
      if ( currentIntervalTime < this.c_intervalTime) { // on a encore du temps : on attends
        this.c_timer = this.Update.delay(this.c_intervalTime-currentIntervalTime, this); // lance update au bout du délais restant
      } else { // on a dépassé l'heure : on repart directement pour un tour
        this.Update();
      }
    }
  }

Cette fonction prépare simplement le bon tag <img> en fonction de la valeur on ou off et l’affiche dans le div concerné :

  GetHTMLOutput: function() {
    // Affiche l'image dans le div de destination
    var lHTMLoutput = '<img src="'; // <p style="writing-mode: tb-rl; filter: flipH() flipV();">TEST</p>
    if (this.c_onOff==0) {
      lHTMLoutput += this.c_imageOFF;
    } else {
      lHTMLoutput += this.c_imageON;
    }
    lHTMLoutput += '"/>';

    $(this.c_elementName).innerHTML=lHTMLoutput;
  }

Cette classe a pour but d’afficher une évolution dans le temps d’une valeur numérique. A chaque update, nous allons afficher une valeur supplémentaire (une barre de 1 pixel représentant la valeur plus précisément), à la manière du monitoring CPU et mémoire du perfmon de windows.

Le fonctionnement global de la classe est exactement le même que la NB4OnOff, je ne reviens donc pas sur les fonctions d’initialistion et d’update

Il y a un point important à noter dans callBackAjaxOk : au lieu d’écraser la valeur précédente comme c’est le cas dans la classe OnOff, ici on ajoute la valeur reçue à un tableau de valeur :

this.c_histo.extend([lvalue]);

Toutefois, la grosse différence se situe dans le code de rendu html : GetHTMLOutput :

• D’abord on récupère la taille de la zone d’affichage (elle peut varier en fonction notamment du mode docké ou non docké)
• Et on en déduit le nombre de barres verticales affichables (a noter que pour l’instant c_imgwidth est un paramètre fixé une fois pour toute)
• Puis enfin on réduit le tableau des valeurs à ce nombre :

	// Récupère la taille actuelle du div
   var divHeight = $(this.c_elementName).getStyle('height').toInt();
   var divWidth = $(this.c_elementName).getStyle('width').toInt();

   // nombre max de barres affichables (division entière)
   var maxBarres = (divWidth - (divWidth % this.c_imgwidth)) / this.c_imgwidth;
   // réduit le tableau avec les dernières valeurs affichables
   if (this.c_histo.length>maxBarres) {
     this.c_histo = this.c_histo.slice(this.c_histo.length - maxBarres);
   }

• Puis si on a définit une hauteur dynamique au graphe, on va chercher quelle est la plus grande valeur du tableau afin de positionner l’échelle. Sinon on positionne l’échelle à une valeur fixe

    if (this.c_maxHeightSize==0) { // taille dynamique
      var valeurMax= 0;
      this.c_histo.each( function(val) {
        if (val >= valeurMax) {
          valeurMax = val;
        }
      });
    } else {  // taille fixe
      valeurMax = this.c_maxHeightSize;
    }

• Enfin on parcoure le tableau de valeur en créant à chaque fois une image verticale dont la hauteur correspond à la valeur chiffrée du tableau et on l’affiche ainsi que le texte du paramètre de la NB4 qui est monitoré et la dernière valeur chiffrée :

    var derniereValeur = 0;
    // affiche le graph
    for(var i=0;i<this.c_histo.length;i++) {
      lHTMLoutput += '<img src="';
      lHTMLoutput += this.c_imageHisto; //this.c_imageHisto;
      lHTMLoutput += '"';
      lHTMLoutput += ' style="position: absolute; bottom: 0px; left:'+ i + 'px; width:'+ this.c_imgwidth + '; height:' + this.c_histo[i]*(divHeight/valeurMax) + ';"';
      lHTMLoutput += '/>';
      derniereValeur = this.c_histo[i];
    }
    $(this.c_elementName).innerHTML=lHTMLoutput;

Deux versions sont téléchargeables : une de devt et une ‘normale’ (on ne peut pas l’appeler ‘de production’ à partir du moment où ce gadget n’est pas encore terminé).
Le but est de montrer comme serait le package ‘minimal’ d’un gadget NB4. J’ai donc enlevé dans la version ‘normale’ tous les fichiers non nécessaires.

Pour l’installer, il suffit de télécharger l’archive, de le dézipper et de double cliquer sur le gadget, il devrait s’installer tout seul. Ensuite, normalement il devrait se trouver dans le répertoire windows suivant : Bureau\<votre nom de user>\AppData\Local\Microsoft\Windows Sidebar\Gadgets

La seconde archive (de développement) intégre un mootools non compressé (pratique pour le debug) ainsi que deux fichier supplémentaires et une icône de développement :

• testFormPost.html qui est une simple page pour interroger la NB4 en POST et récupérer le resultat, pratique pour tester des paramètres et ce qu’ils retournent
• bouchon.php : permet de simuler la NB4 :
  • paramétrez DEBUG_BOUCHON à true dans NB4.js
  • hébergez le repertoire du gadget sur un serveur php et appelez directement la page NB4.html depuis un firefox équipé de firebug
  • Cela permet de faire du débug pas à pas, ce qui est pratique dans certains cas quand on ne comprend pas ce qu’il se passe : un des gros problème du développement de gadgets est la difficulté de debug car le browser embarqué dans windows sidebar n’est pas du tout accessible ni modifiable.

Un canvas est un nouveau élément HTML qui permet de manipuler des graphiques en bitmap. Le canvas est intégré au draft du HTML 5 et a été originellement proposé par apple et son safari. Il est supporté nativement par firefox depuis la 1.5 et n’est pas encore supporté par IE (mais il y a moyen de le faire marcher sous IE, on en parlera plus bas)

Je ne vais pas refaire le tuto de canvas, vous pouvez suivre ce tuto sur le site de mozilla, il est très bien fait.

Mon but ici est de refaire le système de câbles entre deux boites comme dans yahoo pipes.

J’ai choisit d’utiliser mootools comme librairie javascript, parce que j’aime bien mootools. Cela permet de ne pas perdre de temps sur la gestion des box et des drag&drop.

Donc j’ai simplement commencé par définir un bout d’html avec un container, deux boites et le fameux canvas :

<body  onload = "start();">
<div id="containment">
  <canvas id="lien"></canvas>
  <div id="boite1">
  1
  </div>
  <div id="boite2">
  2
  </div>
</div>
</body>

le css qui va avec (rien de compliqué):

<style type="text/css">
 #containment {
 height: 500px;
 width: 600px;
 background: #ddd;
 position: relative;
 }
#boite1 {
 height: 60px;
 width: 40px;
 border: 2px solid black;
 background: #39f;
 color: white;
 position: absolute;
 top: 50;
 left: 50;
 }

#boite2 {
 height: 55px;
 width: 40px;
 border: 2px solid black;
 background: blue;
 color: white;
 position: absolute;
 top: 250;
 left: 250;
 }

canvas {
 /*border: 1px solid red;*/
 position: absolute;
 top: 0;
 left: 0;
 }
 </style>

Ensuite un peu de code mootools pour rendre les boites draggables :

function start() {
 var container = $('containment');
new Drag.Move('boite1', {'container': container});
 new Drag.Move('boite2', {'container': container});

$('boite1').addEvent('mousemove', function() {
 replaceLink();
 });
 $('boite2').addEvent('mousemove', function() {
 replaceLink();
 });
 replaceLink();
 }

Donc tout sera fait dans la fonction ‘replaceLink’
Cette fonction est en fait relativement simple :
Elle fait (dans l’ordre) :
- calculer les coordonnée du point de départ et du point d’arrivée du trait : dans cet exemple le point de départ est collé au bas de la boite 1 et le point d’arrivée en haut de la boite 2.

pointA_x = $('boite1').getStyle('left').toInt()+($('boite1').getStyle('width').toInt())/2;
pointA_y = $('boite1').getStyle('top').toInt()+($('boite1').getStyle('height').toInt());
pointB_x = $('boite2').getStyle('left').toInt()+($('boite2').getStyle('width').toInt())/2;
pointB_y = $('boite2').getStyle('top').toInt(); //+($('boite2').getStyle('height').toInt())/2;

- Traiter correctement le point de départ et d’arrivée en fonction de la position relative des boites l’une par rapport à l’autre (notamment quand la boite 2 se retrouve au dessus de la 1, etc..)

 pointA_x = $('boite1').getStyle('left').toInt()+($('boite1').getStyle('width').toInt())/2;
 pointA_y = $('boite1').getStyle('top').toInt()+($('boite1').getStyle('height').toInt());
 pointB_x = $('boite2').getStyle('left').toInt()+($('boite2').getStyle('width').toInt())/2;
 pointB_y = $('boite2').getStyle('top').toInt(); //+($('boite2').getStyle('height').toInt())/2;

- Préparer le contexte

 lien_width = Math.abs(pointB_x - pointA_x);
 lien_x = Math.min(pointA_x, pointB_x);
 lien_height = Math.abs(pointB_y - pointA_y);
 lien_y = Math.min(pointA_y,pointB_y);

- Effacer l’image précédente

ctx.clearRect(0,0,600,500);

- Dessiner un trait qui part bien du point de départ et qui arrive bien au point d’arrivée : ceci est fait en utilisant les fonctions ‘basiques’ du canvas : MoveTo et soit LineTo soit bezierCurveTo si on veut un trait tout arrondi.

Donc en fait c’est très simple.
Là où on passe un peu de temps c’est vraiment le rendre joli.

Au début, j’ai voulu adapter la taille du <canvas> au rectangle dont les coins sont formés par le point de départ du trait et le point d’arrivée (c’est ce qui me paraissait le plus logique). Cela fonctionne bien, me permet de travailler avec toujours le même système de coordonnées, mais le pb est que mon trait était alors rescallé automatiquement à la nouvelle taille du canvas (ce qui semble être un comportement standard). [cliquez ici pour voir ce que cela donnait en live : éloignez les boites pour le remarquer. (attention, cette version ne marche pas bien sous IE)]
Yahoo semble pourtant utiliser cette technique, mais je n’ai pas réussit à la faire fonctionner, j’ai donc changé d’angle d’approche : j’ai arrêté de resizer mon canvas, je l’ai directement initalisé à la taille du conteneur et ensuite j’ai joué avec la translation :

 ctx.save();
 ctx.translate(lien_x, lien_y);

Cela me permet d’avoir toujours le point (0,0) en haut à gauche du rectangle formé par le point de départ et le point d’arrivée.

Voici deux cas de figure en schéma :

- Ensuite il ne reste plus qu’à dessiner :
la suite de la fonction est simplement là pour gérer les 4 cas de figure de la position relative de la boîte 1 par rapport à la boite 2. Cela ne sert finalement qu’à donner des bons paramètres à la courbe de bézier pour que cela soit joli.
Il y a un autre élément où j’ai eu un peu de mal c’est pour faire en sorte que le trait ait un bord (plus foncé que l’intérieur dans l’exemple). J’ai essayé de jouer avec les propriétés border, mais c’est en fait beaucoup plus simple :
il faut faire un trait foncé plus gros, puis un trait plus clair et plus fin qui va se superposer, tout simplement.
Cette partie du code est optimisable (on peut la rendre plus compacte), mais je l’ai volontairement laissé tel quel pour gagner en lisibilité.

ctx.beginPath(); m_a = 100; // offset pour les beziers
 if (pointA_x < pointB_x) {
 if (pointA_y < pointB_y) {
 // coin en haut à gauche
 ctx.lineWidth = 12;
 ctx.strokeStyle = '#07c';
 ctx.moveTo(0, 0);
 ctx.bezierCurveTo(0,m_a, lien_width, lien_height-m_a, lien_width, lien_height);
 ctx.stroke();
 ctx.lineWidth = 8;
 ctx.strokeStyle = '#09f';
 ctx.moveTo(0, 0);
 ctx.bezierCurveTo(0,m_a, lien_width, lien_height-m_a, lien_width, lien_height);
 ctx.stroke();
 } else {
 // coin en bas à gauche
 ctx.lineWidth = 12;
 ctx.strokeStyle = '#07c';
 ctx.moveTo(lien_width, 0);
 ctx.bezierCurveTo(lien_width, -m_a, 0, lien_height+m_a, 0, lien_height);
 ctx.stroke();
 ctx.lineWidth = 8;
 ctx.strokeStyle = '#09f';
 ctx.moveTo(lien_width, 0);
 ctx.bezierCurveTo(lien_width, -m_a, 0, lien_height+m_a, 0, lien_height);
 ctx.stroke();
 }
 } else {
 if (pointA_y < pointB_y) {
 // coin en haut à droite
 ctx.lineWidth = 12;
 ctx.strokeStyle = '#07c';
 ctx.moveTo(lien_width, 0);
 ctx.bezierCurveTo(lien_width, m_a, 0, lien_height-m_a, 0, lien_height);
 ctx.stroke();
 ctx.lineWidth = 8;
 ctx.strokeStyle = '#09f';
 ctx.moveTo(lien_width, 0);
 ctx.bezierCurveTo(lien_width, m_a, 0, lien_height-m_a, 0, lien_height);
 ctx.stroke();
 } else {
 // coin en bas à droite
 ctx.lineWidth = 12;
 ctx.strokeStyle = '#07c';
 ctx.moveTo(0, 0);
 ctx.bezierCurveTo(0,-m_a, lien_width, lien_height+m_a, lien_width, lien_height);
 ctx.stroke();
 ctx.lineWidth = 8;
 ctx.strokeStyle = '#09f';
 ctx.moveTo(0, 0);
 ctx.bezierCurveTo(0,-m_a, lien_width, lien_height+m_a, lien_width, lien_height);
 ctx.stroke();
 }
 }
 ctx.restore();

IE ne supporte pas nativement les canvas (même pas IE7). Pour contourner ce pb, des gars de chez google ont eu l’excellente idée et le talent d’utiliser le support natif de VML dans IE pour émuler les canvas. Il suffit d’inclure cette librairie pour faire fonctionner canvas sous IE, pourquoi s’en priver…

Je ne suis pas complètement satisfait des perfomances de cette démo, notamment quand on bouge la souris très vite. Yahoo n’a pas ce pb.
A première vue, je supposerait que c’est du au clearRect que je fait pour effacer les dessins précédent, mais je n’ai pas trouvé d’autre solution pour l’instant. Si vous avez des idées, n’hésitez pas à les proposer en commentant cet article.

• Cliquez ici pour accéder à une démo live de ce code

Ci-dessous pour télécharger le sources (incluant mootools 1.11 et Exanvas 0002) :