Archives janvier 2005

Ne vous méprenez pas sur le but de cet article. Le but n'est pas de casser le serveur web Apache mais plutôt de jouer avec ses options de configuration. Le but est de vous montrer comment améliorer la gestion de la sécurité d'accès a ses pages.

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 !

Tester le format PNG

Cette page vous permet de tester la compatibilité de votre navigateur avec le format graphique PNG (qui présente plein d'avantages). Je suis parti d'une image avec un fond dégradé blanc vers bleu + transparence de 100% pour le haut pour atteindre 0% dans le bas. J'ai ajouté une sphère sans transparence sur le tout avec un dégradé de couleurs difficile à reproduire en GIF ou même en JPEG. Enfin j'ai coupé un morceau de sphère pour qu'il soit 100% transparent et ainsi mieux constater les différences avec le dégradé de transparence. À titre de comparaison j'ai mis le .gif généré. Voici le résultat final.

Couleur transparente, 16 millions de couleurs Test PNG
Alpha chanel, 16 millions de couleurs Test PNG
Couleur transparente, palette Test PNG
Pas de transparence Test PNG
Format gif Test GIF

Mise en page de mes sites web

Introduction

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

Gestion des objets COM/DCOM en PHP4.

Bonjour... Comme beaucoup de monde se demande comment ça fonctionne COM avec PHP4, et que je me suis aussi posé la question, voici un petit exemple de code source et un objet COM pour le faire fonctionner. Comme cet objet n'est pas révolutionnaire (il fourni un nombre aléatoire... difficile non ?) je vous le livre "tel quel" avec son code source (comme ça les paranoïaques pourront vérifier ce qu'il fait). Pour des raisons de facilité, je l'ai programmé avec Delphi 5, mais n'importe quel langage capable de produire des objets COM fera tout aussi bien l'affaire.

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";
?>

Les behaviors, mais qu'est-ce donc ?

Table des Matières

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 :

Attribut personnalisé inexistant
Attribut personnalisé white

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

Retrouvez-moi sur

Facebook LinkedIn Viadeo

Photo aléatoire