Networked - CC - auteur: http://www.flickr.com/photos/superkimbo/1727117782/

Pour l’installation de base, il suffit de suivre le tuto d’installation d’un serveur ubuntu, en s’arrêtant juste avant l’install de lighttpd qui n’est pas nécessaire ici (mais cela marche aussi avec bien sûr).

Le tuto a l’air assez long mais il est relativement simple et rapide à mettre en oeuvre : en partant de deux serveurs vides, non installés, suivre les deux tutos d’install générique et celui ci de dhcp+dns, il suffit d’a peine 2H pour tout terminer et avoir ses serveurs fonctionnels.

• Nous allons utiliser, classiquement, les serveurs bind et dhcpd 3
• L’installation s’effectue sur deux machines, que l’on nommera respectivement ns1 et ns2
• Le domaine installé est volontairement local et sera appelé : monentreprise.local
• Le réseau local sera la classe C : 192.168.1.0/24
• et les machines ns1 et ns2 auront respectivement les ips : 192.168.1.10 et 192.168.1.11
• la passerelle internet sera 192.168.1.1

toutes ces valeurs sont des hypothèses et doivent être adaptées en fonction de votre config.

A la fin de l’installation, nous devrions avoir deux serveurs, un ‘maitre’ dhcp et dns (ns1) et son ‘esclave’ (ns2).
Les baux dhcp délivrés par le maitre étant mis à jour automatiquement dans le dns, le tout répliqué automatiquement sur l’esclave.
L’esclave prenant le relais automatiquement si le maître ne marche plus.

Comme son nom l’indique, il faut donc executer ces lignes de façon identique sur chacun des deux serveurs.

sudo apt-get install dhcp3-server

on stoppe le serveur tant qu’il n’est pas configuré pour éviter de mettre la grouille sur le réseau :

sudo /etc/init.d/dhcp3-server stop

sudo apt-get install bind9

Dans le firewall, il est nécessaire d’ouvrir explicitement quelques ports pour :

• le dns
• la mise a jour dynamique des dns suite aux baux délivrés par le dhcp
• la synchronisation des dhcps entre eux

Editer le fichier du firewall :

sudo vim /etc/init.d/server_iptables

et ajouter les lignes suivantes :

# Autorise les requetes DNS
iptables -A INPUT -s 192.168.1.0/24 -p tcp -i eth0 --dport 53 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p udp -i eth0 --dport 53 -j ACCEPT
# Autorise les MAJ DDNS
iptables -A INPUT -s 192.168.1.0/24 -p tcp -i eth0 --dport 953 -j ACCEPT
# Autorise le failover dhcp
iptables -A INPUT -s 192.168.1.0/24 -p tcp -i eth0 --dport 647 -j ACCEPT

On remarque ici qu’on autorise ces ports uniquement depuis les adresses de notre réseau local. On pourrait encore durir les règles en autorisant les maj ddns et les synchros dhcp uniquement depuis nos deux serveurs.

Relancer les règles du Firewall:

sudo /etc/init.d/server_iptables

sudo vim /etc/bind/named.conf.debug.log

logging {
  category "default" { "debug"; };
  category "general" { "debug"; };
  category "database" { "debug"; };
  category "security" { "debug"; };
  category "config" { "debug"; };
  category "resolver" { "warning"; };
  category "xfer-in" { "debug"; };
  category "xfer-out" { "debug"; };
  category "notify" { "debug"; };
  category "client" { "debug"; };
  category "unmatched" { "debug"; };
  category "network" { "debug"; };
  category "update" { "debug"; };
  category "queries" { "warning"; };
  category "dispatch" { "debug"; };
  category "dnssec" { "debug"; };
  category "lame-servers" { "debug"; };

  channel "debug" {
    file "/var/log/bind9/nameddbg" versions 2 size 50m;
    print-time yes;
    print-category yes;
    print-severity yes;
  };

  channel "warning" {
    file "/var/log/bind9/nameddbg" versions 2 size 50m;
    severity warning;
    print-time yes;
    print-category yes;
    print-severity yes;
  };
};

Cette conf est très verbose, il sera peut-être nécessaire de la réduire une fois l’installation achevée et fonctionnelle.

Par défault, le répertoire /var/log/bind9 n’existe pas et est bloqué par apparmor, il faut donc le créer et l’autoriser :

sudo mkdir /var/log/bind9
sudo chown bind:bind /var/log/bind9

Configurer apparmor pour autoriser l’écriture dans le repertoire du log:

sudo vim /etc/apparmor.d/usr.sbin.named

et ajouter à la fin (dans la zone sur les logs):

/var/log/bind9/** rw,
   /var/log/bind9/ rw,

redémarrer apparmor (on relancera bind à la fin de la config)

sudo /etc/init.d/apparmor restart

des clefs seront nécessaires pour la mise à jour du dns par le dhcp, ainsi que pour la configuration rndc (rndc est un outil de configuration pour bind, optionnel, mais bind aime bien qu’il soit là). On va donc aussi configurer rndc sur le maitre.

cd /etc/bind
sudo dnssec-keygen -a hmac-md5 -b 256 -n HOST ns1

ce programme va générer deux fichier nommés Kns1.xxxxxxxx.key et Kns1.xxxxxxxx.private
le fichier .key va devenir notre clef rndc :

sudo mv Kns1.xxxxxxxxx.key rndc.key

(remplacer les xxxxxxxx par le bon nom)

ensuite afficher le contenu du fichier private :

sudo cat Kns1.xxxxxxxxx.private

et copier le texte après ‘Key:’
ensuite créer le fichier de conf rndc :

sudo vim /etc/bind/rndc.conf

et coller les éléments suivants:

key rdnc-key {
  algorithm hmac-md5;
  secret "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";
};

options {
  // what host should rndc attempt to control by default
  default-server 127.0.0.1;
  // and what key should it use to communicate with named
  default-key "rdnc-key";
};

server 127.0.0.1 {
  // always use this key with this host
  key "rdnc-key";
};

et remplacer les XXXXX du secret par ce qu’on a copié après ‘Key:’ du fichier Kns1.xxxxxxxxx.private

on peut maintenant effacer le fichier .private :

sudo rm Kns1.xxxxxxxxx.private

cd /etc/bind
sudo dnssec-keygen -a hmac-md5 -b 128 -n USER dhcpupdate

Dans le fichier .key genéré, copier la clef : La clef est la dernière chaine de caractère du fichier .key, par exemple ici : dhcpupdate. IN KEY 0 3 157 Zihefb3NqqepA/5RgzbicM==
la clef est : Zihefb3NqqepA/5RgzbicM==

avec cette clef, on a généré des directives de configuration pour le dhcp et pour le dns, elles auront l’aspect suivant :
pour le dns :

key dhcpupdate {
  algorithm hmac-md5;
  secret "ICICOLLERLACLEFSECRETEGENEREE";
};

pour le dhcp (pareil que pour le dns, mais sans les guillemets) :

key dhcpupdate {
  algorithm hmac-md5;
  secret ICICOLLERLACLEFSECRETEGENEREE;
};

sudo vim /etc/dhcp3/dhcpd.conf

et mettre le fichier de conf suivant :

#
# Sample dhcpd.conf file
#

# ======== Mise a jour DDNS ========
ddns-domainname "monentreprise.local";
ddns-rev-domainname "1.168.192.in-addr.arpa";
#Mehode de mise a  jour du DNS
ddns-update-style interim;
#Mise a  jour autorisee
ddns-updates on;
#ici on force la maj par le dhcp et non par le client
ignore client-updates;
#on force la maj des ipfixes
update-static-leases on;
# Clef partagee dhcpd et bind9
key dhcpupdate {
    algorithm hmac-md5;
    secret ICICOLLERLACLEFSECRETEGENEREE;
};

# ======== Option Generales du dhcp ========

# Server name
server-name "dhcp.monentreprise.local";

# option definitions common to all supported networks...
option domain-name "monentreprise.local";
option domain-name-servers 192.168.1.10, 192.168.1.11;

default-lease-time 3600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.
subnet 192.168.1.0 netmask 255.255.255.0 {
}

#Zones
zone 1.168.192.in-addr.arpa. {
  primary 127.0.0.1;
  key dhcpupdate;
}

zone linkcareservices.local. {
  primary 127.0.0.1;
  key dhcpupdate;
}

# ======== Failover configuration ========
failover peer "dhcp-failover" {
  primary; # declare this to be the primary server
  address 192.168.1.10;
  port 647;
  peer address 192.168.1.11;
  peer port 647;
  max-response-delay 30;
  max-unacked-updates 10;
  load balance max seconds 3;
  mclt 1800;
  split 128;
}

# ======== Reseaux ========
## déclaration sous réseau 192.168.1.*
subnet 192.168.1.0 netmask 255.255.255.0 {
  # Si vous voulez spécifier un domaine différent de celui par défaut :
  #option domain-name "mon_domaine.qqc";
  ## Adresse de diffusion
  option broadcast-address 192.168.1.255;
  ## routeur par défaut
  option routers 192.168.1.1;
        ## Plage d'attribution d'adresse
        ## Ici on ouvre pour l'instant une 'petite' plage entre .50 et .99, c'est un exemple, on peut mettre plus.
  pool {
    failover peer "dhcp-failover";
    range 192.168.1.50 192.168.1.99;
  }
  # évalue si l'adresse est déjà attribuée
  ping-check = 1;
}

host ns1 {
  hardware ethernet 00:00:00:00:00:00;
  fixed-address 192.168.1.10;
}

host ns2 {
  hardware ethernet 00:00:00:00:00:00;
  fixed-address 192.168.1.11;
}

Pour que le fichier de configuration soit complet, il faudra remplacer les ICICOLLERLACLEFSECRETEGENEREE de la clef par la clef générée précedemment.
Il y a également deux baux statiques dans le fichier de configuration pour nos serveurs ns1 et ns2, il faut remplacer les 00:00… des adresses MAC par les vraies adresses mac de vos machines.

ce fichier représente la configuration principale du dns, on va juste ajouter quelques directives en début de fichier :

sudo vim /etc/bind/named.conf

et ajouter en début de fichier les éléments suivants:

acl internals { 127.0.0.0/8; 192.168.1.0/24; };

controls {
  inet 127.0.0.1 allow { 127.0.0.1; localhost; } keys { "rdnc-key"; };
};

key rdnc-key {
  algorithm hmac-md5;
  secret "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";
};

key dhcpupdate {
  algorithm hmac-md5;
  secret "ICICOLLERLACLEFSECRETEGENEREE";
};

en remplaçant XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX par la clef rndc générée précedemment, et en remplaçant ICICOLLERLACLEFSECRETEGENEREE par la clef dhcpupdate générée plus haut.

sudo vim /etc/bind/named.conf.options

Comme on est en train de construire des serveurs pour un petit réseau interne, nous n’avons pas besoin que les dns résolvent tout internet, on va donc les configurer pour faire relais vers d’autre dns. L’avantage, c’est qu’on peut choisir ceux qu’on veut, et pas obligatoirement ceux de son ISP, même si au final il est quand même préférable d’en choisir des pas trop loin et si possible performants. Les DNS des ISP répondent souvent à ces problématiques.
Vous pouvez aussi mettre simplement le dns de votre routeur/box en relais, nos dns internes servant au final à gérer les zones internes.

Le fichier complet ressemble donc à ceci :

options {
        directory "/var/lib/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        // forwarders {
        //      0.0.0.0;
        // };
  forwarders {
    aa.bb.cc.dd;
    ee.ff.gg.hh;
    192.168.1.1;
  };

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { none; };
  listen-on { 127.0.0.1; 192.168.1.10; 192.168.1.11; };

  // transférer les informations de zones aux DNS secondaires
  allow-transfer { 192.168.1.11; };

  // Accepter les requêtes pour le réseau interne uniquement
  allow-query { internals; };

  // Autoriser les requêtes récursives pour les hôtes locaux
  allow-recursion { internals; };

  // Ne pas rendre publique la version de BIND
  version none; 

};

dans la zone ‘forwarders’, vous pouvez donc remplacer les ips aa.bb.cc.dd et ee.ff.gg.hh par deux dns publics ou ceux de votre isp, ou vous pouvez enlever les lignes pour ne garder que le dns du routeur.
Dans cette config, on autorise le transfert des infos de DNS vers notre futur secondaire.

Il y a un autre élément important dans ce fichier de config : le répertoire par défaut de travail de bind qui doit être /var/lib/bind : sous ubuntu 9.04, par défaut, seul ce répertoire autorise bind à écrire dans le fichier et c’est nécessaire pour la maj ddns venant du dhcp.

sudo vim /etc/bind/named.conf.local

insérer les zones et les reverses :

///
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

include "/etc/bind/named.conf.debug.log"; 

zone "monentreprise.local" {
    type master;
    notify yes;
    allow-transfer { 192.168.1.11; } ;
    file "monentreprise.local.hosts";
};

zone "1.168.192.in-addr.arpa" {
    type master;
    notify yes;
    allow-transfer { 192.168.1.11; } ;
    file "1.168.192.in-addr.arpa.zone";
};

Cette config indique que ce dns est ‘master’ pour les deux zones et qu’il notifie et transfère les infos de zones vers le secondaire.
De plus, il pointe sur une configuration de debug particulière qui est utile pour l’analyse des problème de la configuration et que l’on a paramétré précédemment.

Il faut maintenant créer les fichier de la zone et du reverse. On va les créer dans /etc/bind, puis les lier dans /var/lib/bind/ où va vraiment aller les chercher bind, suite à notre config dans options.

sudo vim /etc/bind/monentreprise.local.hosts

et mettre les infos suivantes (c’est un exemple, mais qui est paramétré avec deux serveurs DNS pour préparer la conf/maitre-esclave)

@      IN     SOA     ns1.monentreprise.local. email.monentreprise.com. (
            20092909003 ; serial
            600 ; refresh after 10 minutes (for testing purpose)
            3600 ; retry after 1 hour
            604800 ; expires after 1 week
            86400 ) ; minimum TTL of 1 day
@     IN     NS     ns1.monentreprise.local.
@     IN     NS     ns2.monentreprise.local.
gw          IN  A       192.168.1.1
ns1         IN  A       192.168.1.10
ns2         IN  A       192.168.1.11
dhcp        IN  CNAME   ns1
dhcp2         IN  CNAME   ns2

Dans la premiere ligne, il faut indiquer un email après le serveur (ne pas oublier les ‘.’ à la fin). bizarrement, l’email est de la forme email.domaine.suffixe. alors que cela veut dire email@domaine.suffixe

faire de même avec le reverse:

sudo vim /etc/bind/1.168.192.in-addr.arpa.zone

@       IN    SOA     ns1.monentreprise.local. email.monentreprise.com. (
            20090929002 ; serial
            600 ; refresh after 10 minutes (for testing purpose)
            3600 ; retry after 1 hour
            604800 ; expires after 1 week
            86400 ) ; minimum TTL of 1 day
@       IN     NS     ns1.monentreprise.local.
@       IN     NS     ns2.monentreprise.local.
1       IN     PTR    gw.monentreprise.local.
10     IN     PTR    ns1.monentreprise.local.
11     IN     PTR    ns2.monentreprise.local.

Pour ces deux fichiers, si vous les modifiez à la main, il est important de faire évoluer le sérial à chaque modification. Sinon le DNS principal n’ira pas notifier le secondaire.

maintenant on va faire en sorte que ces fichiers soient dispos dans /var/lib/bind et modifiables par bind:

sudo chown bind:bind /etc/bind/monentreprise.local.hosts
sudo chown bind:bind /etc/bind/1.168.192.in-addr.arpa.zone
sudo ln -s /etc/bind/monentreprise.local.hosts  /var/lib/bind/monentreprise.local.hosts
sudo ln -s /etc/bind/1.168.192.in-addr.arpa.zone  /var/lib/bind/1.168.192.in-addr.arpa.zone

on peut enfin redémarrer bind et démarrer le dhcp

sudo /etc/init.d/bind9 restart
sudo /etc/init.d/dhcp3-server start

Attention : il ne faut pas oublier de désactiver le ou les précédents serveurs dhcp sur le réseau (celui du routeur/de la box par exemple).

La conf sur l’esclave est plus simple car il n’y a pas de système de maj ddns et les fichiers de zones dns sur récupérées automatiquement du maitre.

sudo vim /etc/dhcp3/dhcpd.conf

et mettre la conf suivante :

#
# Sample dhcpd.conf file
#

# ======== Mise a jour DDNS ========
ddns-update-style none;

# ======== Option Generales du dhcp ========
# Server name
server-name "dhcp2.monentreprise.local";

# option definitions common to all supported networks...
option domain-name "monentreprise.local";
option domain-name-servers 192.168.1.10, 192.168.1.11;

default-lease-time 3600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.
subnet 192.168.1.0 netmask 255.255.255.0 {
}

# ======== Failover configuration ========
failover peer "dhcp-failover" {
  secondary; # declare this to be the secondary server
  address 192.168.1.11;
  port 647;
  peer address 192.168.1.10;
  peer port 647;
  max-response-delay 30;
  max-unacked-updates 10;
  load balance max seconds 3;
}

# ======== Reseaux ========
## déclaration sous réseau 192.168.1.*
subnet 192.168.1.0 netmask 255.255.255.0 {
  # Si vous voulez spécifier un domaine différent de celui par défaut :
  #option domain-name "mon_domaine.qqc";
  ## Adresse de diffusion
  option broadcast-address 192.168.1.255;
  ## routeur par défaut
  option routers 192.168.1.1;
        ## Plage d'attribution d'adresse
        # Ici on ouvre pour l'instant une 'petite' plage entre .50 et .99, c'est un exemple, on peut mettre plus.
  pool {
    failover peer "dhcp-failover";
    range 192.168.1.50 192.168.1.99;
  }
  # évalue si l'adresse est déjà attribuée
  ping-check = 1;
}

host ns1 {
  hardware ethernet 00:00:00:00:00:00;
  fixed-address 192.168.1.10;
}

host ns2 {
  hardware ethernet 00:00:00:00:00:00;
  fixed-address 192.168.1.11;
}

Comme pour le dhcp maître, il y a deux baux statiques dans le fichier de configuration pour nos serveurs ns1 et ns2, il faut remplacer les 00:00… des adresses MAC par les vraies adresses mac de vos machines.

sudo vim /etc/bind/named.conf

ajouter juste, en début de fichier, l’acl internals :

acl internals { 127.0.0.0/8; 192.168.1.0/24; };

sudo vim /etc/bind/named.conf.options

Ce fichier est très proche de celui du maitre, sauf qu’il n’a plus la directive ‘allow-transfer’:

options {
        directory "/var/lib/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        // forwarders {
        //      0.0.0.0;
        // };
  forwarders {
    aa.bb.cc.dd;
    ee.ff.gg.hh;
    192.168.1.1;
  };

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { none; };
  listen-on { 127.0.0.1; 192.168.1.10; 192.168.1.11; };

  // transférer les informations de zones aux DNS secondaires
  allow-transfer { 192.168.1.11; };

  // Accepter les requêtes pour le réseau interne uniquement
  allow-query { internals; };

  // Autoriser les requêtes récursives pour les hôtes locaux
  allow-recursion { internals; };

  // Ne pas rendre publique la version de BIND
  version none; 

};

sudo vim /etc/bind/named.conf.local

Ici la conf est sensiblement différente, car on précise que les zones sont ‘esclaves’ :

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

include "/etc/bind/named.conf.debug.log"; 

zone "linkcareservices.local" {
    type slave;
    masters {192.168.1.10;} ;
    file "linkcareservices.local.hosts";
};

zone "1.168.192.in-addr.arpa" {
    type slave;
    masters {192.168.1.10;} ;
    file "1.168.192.in-addr.arpa.zone";
};

Il n’y a pas besoin de créer à la main les fichiers de zones : ils seront transférés automatiquement depuis le maitre.

on peut enfin redémarrer bind et démarrer le dhcp

sudo /etc/init.d/bind9 restart
sudo /etc/init.d/dhcp3-server start

Ce tuto est censé marcher directement, mais vous rencontrez des problèmes, voici quelques infos / trucs pour débugger les problèmes. J’essaierais de faire évoluer cette zone au fur et à mesure.

les logs du dhcp sont dans /var/log/syslog
les logs du dns sont dans /var/log/bind9/nameddbg

Avant tout, il faut bien regarder ces logs à la recherce de problèmes

Je me suis cassé la tête des heures durant sur des problèmes de MAJ ddns du dhcp vers le dns qui ne marchaient pas.
Au final, le pb était qu’il y avait deux dns qui tournaient sur la machine.
Ce pb a l’air plus courant qu’il n’y parait : ça m’est déjà arrivé deux fois (et deux fois je suis tombé dans le panneau). C’est peut-être un pb dans le restart du serveur dans init.d qui ne marche pas bien.
Donc si vous avez un doute :

sudo /etc/init.d/bind9 stop

puis :

ps -ef | grep named

et si le ps montre un process named qui tourne encore, alors ne pas hésiter à le killer sauvagement :

sudo kill -9 XXXXXX

XXXXXX étant le numéro du process.
puis :

sudo /etc/init.d/bind9 start

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

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 !!

Le besoin est assez simple :
j’ai deux PC sous linux qui stockent des fichiers et qui se sauvegardent en croisé (via d’autres scripts déjà écrits ; vu la simplicité et la puissance de python, je m’amuserais peut-être à les réécrire à l’occasion).
Prenons par exemple le serveur 1, le script de sauvegarde qui tourne dessus copie son fichier sur le serveur 2 et s’arrange pour garder n générations.

Mon inquiétude (et donc ce que j’ai envie de vérifier) c’est que ce script de sauvegarde s’execute mal ou encore que la copie du serveur 1 vers le serveur 2 plante en plein milieu.

Mon but est donc de faire tourner localement sur le serveur 2 un script qui va vérifier que les sauvegardes sont bien présentes, de la bonne date et de la bonne taille.

Je suis désolé si vous autres experts de python trouvent ce script complètement horrible, ne respectant pas la phylosophie de python ou que sais-je. C’est mon premier script python et m’a permis de découvrir globalement ses possibilités, et je dois dire que je suis plutôt enthousiaste car c’est un langage a la fois simple et puissant.

Pour chaque sauvegarde à vérifier, je voulais pouvoir en contrôler sa présence, sa fraicheur, ainsi que sa taille.
Comme beaucoup de sauvegardes, mes fichiers backups ont une date/heure dans leur nom, j’ai donc choisit d’utiliser les expressions régulières pour essayer de trouver mes sauvegardes :
Imaginons que dans le répertoire /home/backups, nous avons les fichiers suivants :

• sav_serveur1_MesSitesWebs_20061226200232.tar.gz
• sav_serveur1_MesSitesWebs_20061227200227.tar.gz
• sav_serveur1_MesSitesWebs_20061228200335.tar.gz

Dans le programme, je vais donc lui dire de vérifier, dans le répertoire /home/backups (par exemple) les fichiers du type ‘.*MesSitesWebs.+\.tar\.gz’

Ensuite, je passe simplement 3 paramétres supplémentaires : un pour la vérification de la date et deux pour la taille :

Le principe est qu’il faut trouver au moins un fichier sauvegardé dont la date est dans l’intervalle ‘acceptable’ de sauvegarde. J’ai défini des intervalles journalières, hebdo, mensuelles ou annuelles.
Prenons par exemple journalière (‘d’) : si le vérificateur ne trouve pas de fichier (dont le nom correspond à l’expression régulière bien sûr et) dont la date de modification est inférieure aux 24 dernières heures, alors le test échoue et une erreur est remontée.

le premier paramètre est la taille de comparaison
le second est le type de comparaision :

• ‘eq’ : la taille du fichier doit être exactement la même que la taille de comparaison
• ’sup’ : la taille du fichier doit être plus grande que la taille entrée en paramètre (c’est souvent le cas pour une archive qui grossit un peu chaque jour)
• ‘inf’ : la taille du fichier doit être plus petite que la taille entrée en paramètre

Dans la fonction main(), il est possible d’enchaîner plusieurs vérifications de suite (en copiant/collant un bloc de vérification et en modifiant les paramètres appropriés)

En cas d’échec d’au moins une des vérifications, un email sera envoyé au destinataire paramétré avec le détail des erreurs rencontrées.

La quasi totalité de la personnalisation est dans la fonction main() :

ajouter / modifier les blocs de vérifications et en mettre autant que souhaité (mais au moins 1 bien sûr).
exemple d’un bloc :

# Check d'un fichier backupé
 TmpIsOk, TmpTexte = VerifFilesInDirectory('/home/backups/', '.*_BACKUP_MYSQL.+\.tar\.gz', 'd', 1600000, 'sup')
 if TmpIsOk == -1:
 EmailTexte = EmailTexte + "\\n" + TmpTexte + "\\n"

Il faut simplement changer les paramètres de l’appel de la fonction SendEmail :

SendEmail('admin@example.com', 'dest@domain.com', 'PB de SAUVEGARDE', EmailTexte, 'localhost')

• La première adresse est l’adresse de l’expéditeur
• La seconde celle du destinataire
• Le troisième paramètre est l’objet du mail
• Le quatrième doit être laissé tel quel, c’est le texte contruit par les vérifications de fichiers
• Le dernier est l’adresse du serveur smtp, il peut être local comme dans l’exemple ou celui de votre isp (smtp.monisp.fr par exemple)

Pour découvrir python, j’ai parcouru un certains nombre de sites très bien faits, dont voici un aperçu :

• Le livre ‘plongez au coeur de python’
• La référence officielle
• L’index officiel des modules