Vous avez probablement constaté sur ce site un changement d'envergure : l'ajout d'une médiathèque. Celle-ci est gérée de façon quasi automatique grâce à Movable Type et quelques plugins astucieux. 

Quelques prérequis

Déjà il vous faut movable type... j'utilise la version 4.1 et donc tout ce que je vais écrire là se rapporte à cette version. Cependant cette idée de gérer ma médiathèque avec movable type est née à partir d'une expérience similaire datant de 2002. Idée qu'il a fallut adapter pour suivre les évolutions de Movable Type notamment. On va supposer ici que Movable Type est installé correctement et que vous savez vous en servir. Le but n'est pas ici de faire un mode d'emploi exhaustif de ce logiciel (!).

Ensuite il vous faut une clé d'API Amazon. Là il faut causer un peu anglais pour pouvoir l'obtenir sur le site dédié.

Il vous faudra aussi le greffon Media Manager pour Movable Type 4. Il est pour l'instant disponible uniquement en version beta. Il inclue MTAmazon dont on aura besoin pour afficher les pages du site. Il est disponible sur le site de majordojo.

L'installation sur le PC du logiciel s'est bien déroulée. Je vous passe le temps interminable nécessité pour la synchro de la carte en bluetooth lors de la hotsync (la prochaine fois je prends le mode avancé et je copie la carte sur la SD via mon lecteur de cartes, ça ira plus vite !). Je lance et là... erreur ! En gros la mémoire du palm a besoin d'être optimisée et ça se fait par un soft reset. Pas de soucis, ViaMichelin va se relancer tout seul. Sauf qu'à la fin du soft reset pouf j'ai à nouveau ce message d'erreur et ça boucle.

Pour arrêter la boucle des softs resets le plus simple c'est de faire un warm reset (bouton à l'arrière + flèche vers le haut maintenue) puis un nouveau soft reset (bouton à l'arrière seul). Mais ça ne résout pas le problème de lancement de ViaMichelin.

Alors comment faire ?

Et comme ça ne suffisait pas (et surtout que je l'utilise pas mal...) j'ai aussi adapté pour la version 1.2.7 de dotclear le plugin filemanager. Là encore ce sont les modifications de sécurité de cette nouvelle version qui plantait le plugin (lors de la modification de fichiers... le reste fonctionnait encore !)

Et comme je suis gentil (et que la license GPL du plugin l'impose ;-)) je vous livre le tout ci-dessous :

• plugin-smiliesmanager-0.6.tar.gz : l'archive au format .tar.gz (12 ko)
• plugin-smiliesmanager-0.6.pkg.gz : l'installeur (19 ko)
• plugin-filemanager-0.5.1.tar.gz : l'archive au format .tar.gz (9 ko)
• plugin-filemanager-0.5.1.pkg.gz : l'installeur (12 ko)

Mise à jour : nouvelle version 0.4 qui corrige les instructions de modification manuelle de poster.php et qui permet d'utiliser le greffon même quand on a renommer son dossier ecrire (si vous ne comprenez pas ce que ça veut dire, c'est pas grave... c'est juste que c'est mieux comme ça !).

Mise à jour : la version 0.5 corrige la modification d'un smiley qui n'était pas compatible avec dotclear 1.2.7 (precondition failed).

Mise à jour : la version 0.6 affiche un avertissement si l'affichage des smilies est désactivé dans la configuration de dotclear.

Tout a commencé avec la démocratisation des GPS autonomes. Il devient facile de se procurer un petit GPS bluetooth (par exemple) pour le brancher sur son PDA. Souvent couplé à un logiciel de cartographie / navigation cela permet de retrouver son chemin facilement (et quand on connait mon sens de l'orientation on se doute que j'ai fait rapidement l'acquisition de ce petit gadget technologique)...

Le but de ce plugin est de permettre d'identifier un auteur de commentaire à partir de son adresse email. A quoi ça sert ? Par exemple à ajouter une classe dans le code HTML afin de changer la couleur et ainsi reconnaître un auteur du blog.

Il était une fois un blogueur qui était bien tranquille avec son site perso. Il utilisait blogger.com pour mettre à jour ses pages pour éviter de les modifier à la main. Et puis, le temps faisant, d'autres personnes dans son entourage ont commencé à écrire dans des blogs. Sa maman, ses amis, sa frangine... à tel point que tout le monde écrit sur son blog et met des commentaires dans ceux des autres (voire parfois utilise des rétroliens).

On suppose ici, pour simplifier, que la terre est une sphère. Je sais, ce n'est pas exact et le relief peut également intervenir (c'est pour ça que j'ai écrit à vol d'oiseau !). On suppose aussi que l'on dispose des coordonnées GPS (lattitude et longitude) en degrés et non pas en degrés, minutes, secondes.

La première étape consiste à convertir nos degrés en radians. Ca c'est facile, il suffit de tout multiplier par 2?/360.

Ensuite la distance c'est, si le point source a comme coordonnées (sourceLat, sourceLong) et le point destination (destLat, destLong) :

d = R * (Pi/2 - ArcSin( sin(destLat) * sin(sourceLat) + cos(destLong - sourceLong) * cos(destLat) * cos(sourceLat)))

L'unité de d dépendra de l'unité prise pour le rayon. Si celui-ci est exprimé en km alors la distance sera elle aussi en kilomètres.

Pour R je prend généralement 6378km.

• AdBlock. Celle-là je crois que tout le monde devrait l'avoir. C'est un filtre qui permet de réécrire les pages à la volées pour faire disparaître un maximum de pub. Ca ne gère pas forcément les intersticiels mais c'est assez efficace pour certaines pubs envahissantes ! Remplace efficacement le proxomitron.
  
• Html Validator. Ca c'est mon côté développeur web qui resort ! Ca ajoute une chtite icône en bas de la page qui dit si la page est valide ou non ou s'il y a des avertissements. En pratique ça utilise HtmlTidy qui n'est pas parfait et signale parfois des erreurs là où le validateur du W3C n'en voit pas (l'inverse est parfois vrai mais nettement plus rare). Une extension pratique donc mais qui ne dispense pas de vérifier.
• Live HTTP Header. Là encore c'est pour du développement (90%) et la curiosité (10%). Ca permet de voir tout ce qui s'est passé entre le navigateur et le serveur web. Ca remplace la fenêtre de log du proxomitron.
• Tabbrowser Preferences permet d'améliorer la gestion des onglets de firefox (qui est déjà exemplaire !).
• Fasterfox... Ca je l'ai installé mais je ne sais pas si ça accélère vraiment. Quoi qu'il en soit ça me dit en combien de temps une page a été chargée ce qui peut-être rigolo :-)
• TabFx est une autre extension pour les onglets. Ca permet de rajouter un bouton de fermeture sur chaque onglet (plutôt que d'utiliser celui qui est tout à droite, qu'on peut conserver ou cacher).
• Bookmarks Synchronizer (édition SiteBar). Celui là je ne peux plus m'en passer ! Ca permet d'avoir un fichier de signets quelque part sur internet et de le partager sur tous ses ordinateurs. Par exemple le navigateur à la maison, le navigateur au travail, etc. En plus ça génère des fichiers compatibles XBEL ce qui permet d'afficher le fichier sur mon site (oui, c'est la page liens !)
• FxIF permet de visualiser les métadonnées EXIF d'une image en affichant les propriétés de cette dernière.
• Web Developer ajoute une barre dédiée au développement web. Elle permet de torturer une page directement depuis le navigateur ou d'aller directement sur les sites de validation.
• Performancing (que je suis en train d'utiliser à l'instant même) est un éditeur de blogs (en anglais). Ca permet d'ajouter des notes sur son blog sans pour autant devoir se connecter à l'interface de celui-ci. On verra à l'usage si je le conserve ou non mais quand on a plusieurs blogs ça évite de se souvenir des URL de chacun et de son login / pass. Bref à voir !

Le seul soucis c'est que cette fonction OTG ne fonctionne QUE si le disque dur est formatté en FAT32. Cela semble assez logique puisque le NTFS est bien plus compliqué à gérer...

Les préliminaires

Le nombre de sites web qui expliquent comment configurer apache par un .htaccess pour interdire l'accès non autorisé à des pages d'un site ne manquent pas. Cependant comme c'est un pré-requis pour aller plus loin je vais faire un rapide résumé.

On peut, dans Apache, modifier l'accès à des pages. Ceci se fait au niveau du fichier de configuration du serveur. On peut cependant autorisé les utilisateurs à reparamétrer à la volée l'accès à certain répertoires en utilisant des fichiers spéciaux (généralement nommé .htaccess mais c'est paramétrable). A noter aussi qu'un FAI peut interdire l'utilisation des .htaccess pour améliorer les performances de son serveur web (qui n'a plus à vérifier l'existance de ces fichiers à chaque nouvel accès à un répertoire).

Pour sécuriser l'accès à un répertoire on utilise généralement un fichier de login / mot de passe stockés dans un répertoire non visible depuis le web (soit en dehors de l'arborescence du serveur - ce qui est le plus sécurisé - soit dans un dossier lui-même protégé par une interdiction totale d'accès en HTTP). On peut également utiliser la notion de groupes qui permet de limiter l'accès à un ou plusieurs groupes.

Ensuite il suffit d'écrire un petit .htaccess qui pourrait resembler à ceci, en partant du plus contraignant :

AuthUserFile /auth/.htpasswd
AuthName "Secure Access"
AuthType Basic require user toto 

AuthUserFile /auth/.htpasswd
AuthGroupFile /auth/.htgroups
AuthName "Secure Access"
AuthType Basic require group admin 

AuthUserFile /auth/.htpasswd
AuthName "Secure Access"
AuthType Basic require valid-user 

Dans le premier exemple seul l'utilisateur toto peut accéder aux pages. Dans le deuxième exemple tout membre du groupe admin peut accéder aux pages. Enfin dans le troisième tout utilisateur déclaré dans le fichier .htpasswd peut accéder aux pages. Bien entendu ceci suppose d'avoir connaissance du mot de passe !

Les fichier .htpasswd et .htgroups peuvent resembler à ceci :

# Fichier .htpasswd
toto:CryptedPassword
tutu:OtherCryptedPass
titi:SecurePass!

# Fichier .htgroups
admin: titi toto
test: tutu titi 

L'avantage des groupes c'est que quand vous ajoutez un utilisateur à votre système, si vous avez plusieurs zones logiques, il suffit d'ajouter l'utilisateur aux différents groupes auxquels il a droit et hop tout le site est bon. Sans cela il faut aller éditer tous les fichier .htaccess (ou modifier le fichier de config du serveur) pour ajouter / enlever l'utilisateur avec toujours le risque d'en oublier un quelque part. Bref d'un point de vue maintenance cela permet de tout centraliser... bien entendu si votre fichier central est mal protégé le château de cartes s'écroule !

Hey, c'est récursif cette protection !

Une fois un répertoire sécurisé, tous ses sous-répertoires se voient appliquer les même restrictions. C'est dans 99,999% des cas une bonne chose mais il peut arriver qu'on désire modifier voire supprimer la sécurité d'un répertoire. Pourquoi ? Parce-que ! Bon disons que par exemple vous sécurisez une zone de votre site web en l'appelant extranet. Dedans vous mettez les outils qui sont accessibles à votre collaborateurs et vous spécifiez que cette zone est cryptée SSL. Et puis vous vous dites tient je vais mettre tel outil que j'ai trouvé qui a l'air sympa (IMP pour lire son mail ?)... et comme de juste cet outil propose sa propre authentification. Donc pour éviter le double login vous devez supprimer l'une ou l'autre des protection d'accès. Généralement pour le logiciel c'est pas évident... donc il faut supprimer la protection apache. Oui mais comment ?

Une tentative pour mettre un .htaccess vide ne fonctionne pas. Zut, bien essayé. Mais alors comment lui faire comprendre à l'animal ? En fait il suffit de ruser un peu. Il existe une directive permettant de restreindre les adresses IP qui peuvent se connecter au répertoire. Ainsi on peut sécuriser une zone en n'autorisant que les adresses IP du réseau interne. C'est pas 100% sûr (on peut usurper une adresse IP) mais c'est déjà un bon début. On peut aussi dire j'autorise/interdit n'importe quelle adresse IP.

Voici par exemple un fichier qui interdit tout acces à un répertoire et ce quelle que soit l'adresse utilisée. Un tel fichier est souvent placé pour interdire à un client web de lire le contenu du répertoire qui peut contenir, au hasard, un fichier .htpasswd

Deny from all 

On peut donc se dire que si on utilise la directive Allow from all celle-ci va remplacer la sécurité du répertoire... un rapide essai vous prouvera le contraire. En fait les directives se complètent. On pourrait en effet expliquer au serveur web qu'il faut que l'utilisateur soit valide ET qu'il se connecte depuis une adresse IP valide.

Heureusement il y a une solution. En fouillant un peu dans la documentation Apache on trouve la directive magique Satisfy. Celle-ci permet de modifier le mode de sécurisation par défaut (un ET de toutes les directives) pour, par exemple, dire qu'une seule directive suffit. Exemple :

AuthUserFile /auth/.htpasswd
AuthName "Secure Access"

AuthType Basic
require valid-user

Order allow,deny
Allow from all

Satisfy any 

J'ai remis la directive de protection par utilisateur mais en réalité elle ne sera jamais utilisée puisque dans cet exemple j'ai mis un "Allow from all". La directive Order permet de dire qu'on commence par autoriser l'accès puis ensuite on applique les restrictions. Je ne pense pas que dans ce cas préci cela change quelque chose mais je n'ai pas vérifié !

Autre exemple d'utilisation de la directive satisfy. Revenons à notre exemple d'extranet. Disons que depuis internet nous trouvions normal que les utilisateurs saisissent un login et un mot de passe (à noter que cela pourrait tout aussi bien être "présenter un certificat SSL... mais là n'est pas notre propos). Cependant en interne on peut décider d'autoriser toutes les machines à se connecter sans mot de passe.

Première mauvaise idée utiliser le nom de domaine pour le allow. Il ne faut surtout pas dire Allow from .mondomaine.com car il est plus facile d'usurper un nom qu'une adresse IP (du moins je pense, je ne suis pas expert en sécurité !). Il faut donc donner le domaine d'adresse IP autorisées (adresses qui si c'est bien fait ne seront pas routables sur internet).

Pour en savoir plus sur ce domaine je vous invite à lire en détail la documentation du serveur Apache. On trouve toujours plein de choses amusantes. A noter que tout ceci est valable pour une version 1.3 du serveur. Je n'ai pas expérimenté sur une version 2.x donc si ça ne fonctionne pas merci de m'envoyer un petit message !

Si comme moi vous aimez le PHP et que vous le mettez à toutes les sauces sur votre site web, vous vous êtes certainement posé un certain nombre de questions. Je vais donc essayer ici de donner quelques éléments de réponses... qui ne sont pas exhaustifs mais seulement ce que j'ai personnellement retenu comme solution.

Avoir son site web sur son PC et sur Free

Je n'ai pas encore l'ADSL et donc je ne suis pas connecté en permanence à Internet. Or il faut bien tester son site perso pour se rendre compte de ce qu'il va donner. J'ai testé plusieurs solutions :

• Apache + PHP
• IIS + PHP
• PWS + PHP

Apache est la solution qui se rapproche le plus de la configuration de Free. Pourquoi Free ? Parce que c'est un hébergeur français (comme moi) qui propose PHP (à l'exception de la fonction mail()), 100 Mo d'espace disque et qui est très rapide.

Cependant comme vous pouvez le constater Apache n'est pas obligatoire. J'ai réussi à faire fonctionner mes sites web avec IIS (serveur Web de Microsoft sous NT/Windows 2000) et sous PWS (version de IIS adapté à windows 98 et ME). Cependant le but de cette page n'est pas d'expliquer comment faire fonctionner PHP avec ces serveurs web. D'autre sites le font très bien !

Ma configuration personnelle est PHP 4.0.5. Ce choix peut parraître surprenant étant donné que Free fonctionne toujours en version 3. Cependant avec un peu de rigueur et en regardant dans la doc à partir de quelle version une fonction est valide on s'en sort très bien. J'ai modifié le fichier php.ini et la configuration de mon serveur pour accepter les extensions .php et .php3. Cette dernière est la seule utilisable sur free (pour le moment bien entendu).

Je n'ai pas installé MySQL (ce qui est une grave erreur ;-)) mais c'est en projet. Donc pour le moment mes scripts fonctionnent avec base sur free et sans base de données chez moi... Ce qui n'est pas trop grave !

Gestion des Includes

Une des force de PHP est de pouvoir faire des include et des require. La différence entre ces deux fonctions est expliquée dans la FAQ du newsgroup français consacré à PHP et je vous conseille fortement de la lire.

Cependant, je gère plusieurs sites web... Donc l'utilisation de chemins absolus dans mes includes même si elle fonctionne parfaitement sur le site de free ne me convient vraiment pas. Donc je m'arrange toujours pour que mes includes soient relatifs.

A un moment j'avais pensé utiliser la variable $PHP_SELF avec une fonction pour extraire la "racine" de mon site. Ca fonctionnait parfaitement sur mon PC mais je me suis aperçu par la suite que $PHP_SELF prenait des valeurs "étranges" chez Free... et avec PHP4 configuré en module sur apache c'est pas mieux ;-)

Ma solution est donc toute simple. En début de chaque page j'identifie une variable $srcInclude que je positionne sur un répertoire dans lequel je stocke mes fichiers à include. Ensuite ça va tout seul.

Mise en page du site

Pour la mise en page de mes sites, je suis parti d'une constatation simple : la structure des fichiers HTML est toujours la même :

• Début de page HTML (principalement le doctype et la balise <HTML>)
• Début de la section <HEAD> avec scripts, feuille de style, etc.
• Fin de la section <HEAD>
• Début de la section principale (<BODY>)
• Fin de la section principale
• Fin de la page HTML

Je crée donc un fichier PHP par section... ou presque ;-) En effet entre la fin du HEAD et le début du BODY on n'ajoute généralement pas de code HTML.

Exemple

Par exemple, cette page web a la structure suivante :

<?php
 $srcInclude = "../include";
 $pageTitle  = "Includes sur Free";
 require ("$srcInclude/dpage.inc");
?>
<html>
   <head>
<?php
 require ("$srcInclude/head.inc");
?>
   </head>
   <body>
<?php
 require ("$srcInclude/dbody.inc");
?>
<p>Mes explications...</p>
<?php
 require ("$srcInclude/fbody.inc");
?>
   </body>
</html>
<?php
 require ("$srcInclude/fpage.inc");
?> 

Vous remarquerez que j'ai choisi, pour ce site, de laisser les balises HEAD et autres dans mon code... Je trouve que ça en simplifie la lecture tout en n'empêchant pas des effet de fond de page grâce aux feuilles de style (pourvu que le navigateur soit assez récent)... qui sont incluses dans le fichier head.inc (à noter aussi qu'il manque le DOCTYPE dans cet exemple !).

Avantages de ce système

L'avantage principal de ce système est de séparer le contenu de la présentation chez un prestataire proposant le PHP. En effet tout le monde n'a pas de prestataire proposant XML, XPATH, XMLT, XSL et autres ! L'autre avantage c'est que la présentation est gérée par PHP... et autorise donc tout un tas de trucs sympas comme :

• citation du jour (dans une base de données par exemple)
• anniversaire du jour
• modification de l'aspect du site en fonction de paramètres comme, par exemple :
  • préférences de l'utilisateur stockées dans un cookie (site msit.org par exemple)
  • la date du jour (si la date est le 25 décembre alors utiliser tels fichiers)
  • la résolution de l'écran (plus complexe... nécessite javascript).

Comme tous les fichiers sont appelés à chaque page il est également possible d'appeler une fonction à chaque fois (utilisation possible : statistiques de visite stockées en base).

L'objet COM

Vous pouvez le télécharger en cliquant ici (180ko). L'installation est la même que pour tout objet COM : il faut le copier dans un répertoire et dans une fenêtre de commande (cmd sous NT, command.com sous 9x) saisir la commande suivante :

• Installation : regsvr32 testPHP4.dll
• Désinstallation : regsvr32 /u testPHP4.dll

Exemple de source PHP4

Ce code appelle la commande n fois (paramétrable) et calcule le temps qu'il faut pour le faire.

<?php
 	if (!isset($nbAppels))
 	{
 		$nbAppels = 100;
 	}
 	$comName = "testPHP4.test";
 	$debMTime = microtime();
 	
 	$tst = new COM($comName) or die("Unable to instanciate $comName");
 	$stoquage = array();
 	for ($i=0; $i < $nbAppels; $i++)
 	{
 		$stoquage[$i] = $tst->randNumber();
 	}
 	sort($stoquage);
 	$endMTime = microtime();
 	
 	list($msec, $sec) = explode(" ", $debMTime);
 	$debut = $sec + $msec;
 	
 	list($msec, $sec) = explode(" ", $endMTime);
 	$fin = $sec + $msec;
 	
 	echo "<P><B>Résultats</B> : ".number_format($fin - $debut,4,',','')." s.<BR>\n";
 ?>
 

• Prérequis
• Aperçu
• Mais encore... ça fait quoi ?
• Comment ça fonctionne ?
• Et je met quoi dans le .htc ?
• Exemple complet
• C'est génial... mais...
• Conclusion

Prérequis

Pour pouvoir apprécier pleinement cette page il faut quelques prérequis. Le premier est de regarder la page sous Internet Explorer 5 (ou plus). Même si les autres navigateurs peuvent lire la page les behaviors sont spécifiques à Microsoft et donc l'exemple ne peut-être visualisé que sous cet environnement. Ensuite il faut quelques connaissances. Le HTML, les feuilles de style et le javascript sont un minimum à connaître pour apprécier complètement l'article (du moins dans les détails techniques).

Aperçu

Les behaviors ont été introduits par Microsoft dans la version 5 d'Internet Explorer. Comme d'habitude c'est une proposition pour le W3C, doux euphémisme pour dire que c'est une extension propriétaire. Le but des behaviors est de séparer encore plus le contenu de la présentation. A ce titre c'est donc une extension des feuilles de style... et d'ailleurs ça se positionne comme une feuille de style.

Mais encore... ça fait quoi ?

Il était une fois le javascript... c'est en gros ce que se dit tout développeur de pages web qui désire faire des effets un peu sympa dans sa page. Le seul problème c'est que pour écrire du javascript un peu générique il faut se lever de bonne heure. Et pour le réexploiter bof. On peut bien entendu mettre son code dans un fichier séparé mais la réutilisabilité est limitée.

L'autre problème de Javascript c'est que même si on a fait un joli script permettant de modifier quelque chose en dynamique, il faut tout de même l'appeler. Par exemple imaginons un tableau dont on désire modifier la couleur de fond des lignes quand la souris passe dedans. Ca veut dire que pour chaque ligne il faut écrire un gestionnaire onMouseOver et un gestionnaire onMouseOut. Sous IE ça pourrait donner ça :

<TABLE>
 <TR onMouseOver="this.bgColor='#CCCCCC';" onMouseOut="this.bgColor='white';">
    <td>Colonne 1</td>
    <td>Colonne 2</td>
 </TR>
 <TR onMouseOver="this.bgColor='#CCCCCC';" onMouseOut="this.bgColor='white';">
    <td>Colonne 1 ligne 2</td>
    <td>Colonne 2 ligne 2</td>
 </TR>
 [...]
 </TABLE> 

Bref on se rend compte que le comportement de la ligne est générique et on aimerait donc le factoriser. Ca tombe bien, c'est à ça que sert un behavior (dont la traduction en français est comportement... tient donc !).

Comment ça fonctionne ?

En gros on fait un fichier .htc dans lequel on va écrire notre behavior de façon générique. Comme le but c'est de gérer l'élément à la volée, le mot clé this est associé à l'élément sur lequel est attaché le behavior. On peut alors jouer avec des this.style voir même des this.className (attention tout de même à conserver un behavior sur la nouvelle classe).

Ce behavior est ensuite attaché à n'importe quel élément de la page HTML comme on attacherait un style. On a donc plusieurs options :

• le mettre dans une classe de la feuille de style
• utiliser le mot clé STYLE sur l'élément à modifier

Exemple de définition de style :

<STYLE TYPE="text/css"><!--
    .beh    { behavior: url('monbehavior.htc'); }
 //-->
 </STYLE> 

On peut bien entendu mettre d'autre choses sur la classe comme color et autres... mais ce n'est pas un article sur les feuilles de style que je suis en train d'écrire ! ;-)) La classe s'utilise très facilement de par la suite. Pour revenir sur le tableau :

<TABLE>
 
 <TR CLASS="beh">
    <td>Colonne 1</td>
    <td>Colonne 2</td>
 </TR>
 <TR CLASS="beh">
    <td>Colonne 1 ligne 2</td>
    <td>Colonne 2 ligne 2</td>
 </TR>
 [...]
 </TABLE> 

Et je met quoi dans le .htc ?

Le fichier .htc est en fait un fichier contenant deux parties distinctes : une partie déclarative et une partie script. La partie déclarative explique ce que fait le behavior et comment il s'insère dans la page tandis que la partie script implémente le comportement. C'est comme les packages en PL/SQL, les unités en Pascal ou les fichier .h / .cpp en C (sauf que pour les .htc tout est dans le même fichier).

Partie déclarative

C'est dans cette zone que l'on déclare quels événements on veut intercepter et que l'on déclare de nouveaux attributs. En effet les behaviors permettent d'enrichir les balises standards pour passer des paramètres au behavior, le rendant ainsi plus générique (mais rien n'empêche d'avoir des valeurs par défaut). Il est même possible de déclarer tout cela dynamiquement via un lot de fonctions spécialisées.

Le plus simple c'est de prendre un exemple. Voici donc la partie déclarative d'un fichier .htc assez simple.

<PUBLIC:ATTACH EVENT="onmouseover" ONEVENT="menuOver()" />
 <PUBLIC:ATTACH EVENT="onmouseout"  ONEVENT="menuOut()" />
 <PUBLIC:PROPERTY INTERNALNAME="hiliteColor" NAME="MOBGCOLOR" /> 

Comme vous pouvez le constater, la syntaxe est celle d'un fichier XML (comme l'indique le />). L'exemple ci-dessus est relativement simple. Les deux premières lignes indiquent que l'on veut gérer les événements onmouseover et onmouseout via les fonctions menuOver() et menuOut() qui sont alors automatiquement appelée lorsque l'événement source est déclenché. La dernière ligne permet de créer un nouvel attribut de balise qui s'appelle MOBGCOLOR. La valeur de cet attribut est stockée dans la variable hiliteColor. Il est possible de pré-initialiser cette variable dans la section script. Dans ce cas si l'attribut est présent c'est sa valeur qui compte, sinon c'est la valeur par défaut.

Le script

A chaque événement intercepté on a affecté une fonction que l'on peut écrire en JScript, JavaScript (il y a de subtiles différences), VBScript, etc. Personnellement j'utilise le JScript (implémentation enrichie de Javascript et d'ECMAScript) car les behavior sont déjà du pur spécifique IE... alors pourquoi se priver de fonctionnalités supplémentaires ?!

Comme pour tous les scripts, cette section commence par une balise <SCRIPT> et se termine par </SCRIPT>. Il faut spécifier le langage dans la balise script pour éviter les surprises. Ainsi peut avoir :

<SCRIPT LANGUAGE="JScript">
 
 // On peut avoir besoin de variables globales, alors hop on en met. Elles
 // seront de toutes façons locales au behavior (sauf si précisé autrement ;-)).
 var toto;
 
 function mouseOver()
 {
 	// Ici plein de choses à faire lorsque la souris passe sur
 	// un élément actif.
 }
 
 function mouseOut()
 {
 	// Rétablir l'état précédent
 }
 </SCRIPT> 

Vous remarquerez qu'il n'est pas nécessaire de protéger le script par les balises habituelle <!-- et --> car le script est inclus dans un fichier séparé. Il n'y a donc pas de risques de mauvaise interprétation par un vieux navigateur qui de toutes façons ne lira pas la feuille de style (protégée par commentaires) ni par les navigateurs plus récents incompatibles avec les behaviors qui, croisant un mot clé inconnu, ignorera la déclaration.

Exemple complet

Au début de cet article j'avais pris comme exemple un tableau dont les lignes réagissent à la présence de la souris en changeant leur couleur de fond. Voici comment l'implémenter avec les behaviors de façon assez générique :

<PUBLIC:ATTACH EVENT="onmouseover" ONEVENT="Hilite()" />
 <PUBLIC:ATTACH EVENT="onmouseout"  ONEVENT="Restore()" />
 <PUBLIC:PROPERTY INTERNALNAME="hiliteColor" NAME="MOBGCOLOR" />
 
 <SCRIPT LANGUAGE="JScript">
 
 var normalColor;
 var hiliteColor = "#CCCCCC";
 
 function Hilite()
 {
    normalColor = style.backgroundColor;  
    runtimeStyle.backgroundColor  = hiliteColor;
 }
 
 function Restore()
 {
     runtimeStyle.backgroundColor  = normalColor;
 }
 </SCRIPT> 

Vous remarquerez l'utilisation d'un attribut personnalisé ayant une valeur par défaut via l'initialisation du script. Il est cependant possible de procéder autrement en détournant l'événement ondocumentready (qui est déclenché lorsque le document parent est chargé) pour initialiser dynamiquement la variable et attacher les événements (ce qui évite leur utilisation tant que le document source n'est pas totalement chargé). Je trouve néanmoins ma solution plus lisible car il n'est plus alors utile de lire la fonction init() pour savoir quels événements sont gérés par le behavior. Voici un fichier HTML exemple :

<HTML>
 
 <HEAD>
 <TITLE>Exemple de behavior</TITLE>
 <STYLE type="text/css"><!--
 	// On suppose que l'exemple précédent est stocké dans le même répertoire que
 	// ce fichier et sous le nom test.htc.
 	exemple		{ behavior: url('test.htc'); }
 //-->
 </STYLE>
 </HEAD>
 <BODY>
 <TABLE WIDTH="100%" CELLPADDING="2" CELLSPACING="1">
 <TR CLASS="exemple">
     <TD>Attribut personnalisé</TD>
     <TD>inexistant</TD>
 </TR>
 <TR CLASS="exemple" MOBGCOLOR="white">
     <TD>Attribut personnalisé</TD>
     <TD>white</TD>
 </TR>
 </TABLE>
 </BODY>
 </HTML> 

Cet exemple donne :

C'est génial... mais...

Et oui, malheureusement, il y a un mais. Et de taille en plus. Le premier concerne l'utilisation de ces behaviors sur internet. Outre le fait que c'est spécifique à internet explorer il y a aussi la façon dont c'est déclaré. Si vous avez bien fait attention, on utilise la commande url soit dans le style, soit dans la classe. Or pour chaque instance élément de la page auquel on affecte le behavior il va y avoir une requête HTTP pour charger le fichier .htc. Vous allez me dire que ce n'est pas un problème avec le cache du navigateur... Certes... si le navigateur gardait le fichier en cache ce ne serait pas un problème (du moins chez moi il n'est pas conservé en cache... mais ça ne change rien car mes paramètres sont de vérifier la présence d'une nouvelle version des fichiers à chaque visite de la page... d'où des requêtes supplémentaires). Autrement dit si vous avez un tableau de 75 lignes il chargera 75 fois le fichier .htc ce qui n'est pas toujours très rapide (surtout par modem !).

Second problème... J'ai parlé des variables que l'on pouvait déclarer dans un script. J'ai même dit que la variable était locale à chaque instance du behavior. Ca signifie que si vous déclarez 5 variables et que vous avez 20 instances du behavior vous vous retrouvez avec une occupation mémoire de 5 x 20 = 100 variables. Sur des machines puissantes ce n'est pas trop un problèmes mais il faut conserver ce fait en mémoire. La solution consiste à créer des variables dans le document appelant via un script d'initialisation puis de faire référence à ces variables dans le script... Pour peu que l'on puisse globaliser les variables bien entendu.

Conclusion

Ma conclusion c'est que j'aime bien les behaviors. Ca comble une lacune du javascript et des feuilles de style et permet de créer des composants un peu complexes réutilisables. Sur le site de Microsoft par exemple ils utilisent les behaviors pour gérer des pseudo treeviews de façon très simple. En cherchant un peu on arrive à des résultats spectaculaires comme par exemple l'utilisation de HTML dans les infobulles de Internet Explorer (celles qui s'affichent quand il y a un attribut TITLE sur un lien par exemple) permettant ainsi de jouer sur les retour à la ligne ou de mettre des images.

Enfin une dernière remarque : je n'ai fait que vous donner un aperçu de la puissance des behaviors. Si je vous dit que depuis IE5.5 on peut créer des composants appelables comme des balises en HTML, que l'on peut se faire des behavior en C++ ou qu'il y en a d'inclus dans IE5 pour gérer la persistance vous aurez probablement envie d'aller plus loin... en lisant la doc complète sur le site de Microsoft (attention, c'est en anglais).