Martius Web

Nouveaux brouillons pour HTML 5 publiés par le W3C

Martin Richard — Fri, 05 Mar 2010 20:43:00 +0100

Le W3C, organisme de définition et de normalisation des langages qui font le web, a publié aujourd’hui sept documents sur HTML 5.

Ceux-ci sont toujours à l’état de “brouillons” (drafts), qui ont pour objectif, notamment, de permettre aux navigateurs de se préparer à implémenter les nouvelles fonctionnalités et de recueillir des commentaires de la part des contributeurs/utilisateurs.

Les principaux documents sont le brouillon de la spécification HTML 5, les différences entre HTML 4 et HTML 5, ou encore le document de spécification du langage HTML, se voulant être la référence du langage pour les intégrateurs souhaitant se conformer aux standards HTML. Contrairement à la spécification HTML 5, celui-ci ne vise pas a détailler le comportement prévu des navigateurs vis à vis des balises.

On apprend également que les canevas 2D et micro-données, jusqu’alors intégrés à HTML 5 ont maintenant leurs propres spécifications :

Enfin, les deux derniers documents concernent l’intégration du framework RDF en HTML 5 et la réalisation de pages bi-directionnelles (dont le texte va de gauche à droite et droite à gauche).

L’information vient bien sûr du W3C.

PHP et les sessions : durée de vie, utilisation avancée et quelques subtilités

Martin Richard — Thu, 18 Feb 2010 16:21:00 +0100

PHP met à disposition un ensemble de fonctions permettant de manipuler un mécanisme de sessions : un moyen efficace de conserver des données entre deux requêtes avec lequel vous êtes probablement familier. On s’en passe difficilement sur un site internet interactif !

Bien que ce mécanisme soit assez simple à manipuler, il reste néanmoins quelques subtilités qu’il faut connaître pour en profiter pleinement et éviter des erreurs regrettables. On s’intéressera tout particulièrement à la durée de vie des sessions.

Le mécanisme des sessions de PHP peut se comprendre assez simplement. Le serveur attribue un identifiant unique à l’utilisateur, qui sera retransmis à chaque requête (par le biais d’un cookie ou d’une variable dans l’URL). PHP utilisera cet identifiant pour retrouver les données de l’utilisateur qu’il stocke sur le serveur.

Dans un script php, une session démarre lors d’un appel à la fonction session_start(), cet appel est implicite si la directive session.auto_start du php.ini vaut on. Si aucun identifiant de session n’a été transmis dans la requête, alors PHP générera une valeur aléatoire renvoyée à l’utilisateur. Si un identifiant existe, PHP remplira la variable globale $_SESSION des données enregistrées.

<?php
// Initialisation des sessions
session_start();
 
// On accède à une variable de session, et
// on l'écrit si elle n'existe pas encore
if(!isset($_SESSION['foo']))
  $_SESSION['foo'] = 'bar';
 
echo $_SESSION['foo']; // La variable est utilisable dans le script courant

Les fonctions session_register() et session_unset() ne doivent plus être utilisées (elles sont considérées comme obsolètes).

Gestion des accès concurrents

Les données de sessions sont protégées en écritures : cela signifie qu’un seul script à la fois sera en mesure de les modifier. Ce comportement peut ralentir l’exécution de requêtes simultanées (avec les frames ou Ajax par exemple), l’enregistrement de la session sera retardé en attendant le (ou les) autre(s) script(s) soi(en)t terminé(s). Pour limiter cette attente, vous pouvez appeler explicitement la fonction session_write_close() (ou son alias session_commit()).

Sécurité

Fondamentalement, l’implémentation des sessions en PHP ne souffre pas de problèmes de sécurité, mais vous devrez néanmoins veiller à la manière dont vous les utiliserez. En effet, dans la mesure où une session est basée sur un identifiant transmis sur internet entre l’utilisateur et le serveur, cette donnée est très sensible. Si une personne mal intentionnée obtient l’identifiant de session d’un autre utilisateur, il devient assez facile d’usurper son identité.

Il existe plusieurs techniques (simples ou plus compliquées) permettant d’obtenir l’identifiant de session d’un utilisateur :

la capture : c’est simplement le vol de l’identifiant en le lisant chez l’utilisateur (risque qui doit être contrôlé par l’utilisateur),
la divination : l’identifiant est deviné par la personne mal intentionnée (pratiquement impossible),
la fixation : le pirate choisit et force l’identifiant de la session (que l’on peut éviter simplement).

D’une manière générale, on évitera de transmettre l’identifiant de session dans l’URL par sécurité (pour prévenir de la fixation). D’ailleurs, c’est assez mauvais pour le référencement. Ce comportement peut être désactivé avec la directive session.use_only_cookies à vrai. Bien entendu, un utilisateur interdisant l’utilisation des cookies ne pourra pas utiliser les sessions.

Dans tous les cas, quand le niveau de sensibilité d’une session est modifié (par exemple, quand l’utilisateur s’authentifie ou qu’il obtient de nouveaux droits d’accès), une bonne pratique consiste à générer de nouveau cet identifiant de session avec la fonction session_regenerate_id().

Par défaut, les données de sessions de PHP sont stockées dans un simple fichier de texte (dans le répertoire /tmp sous linux). Tous les scripts PHP peuvent lire ces fichiers car toute exécution de PHP est réalisée par un même utilisateur (à moins que le safe_mode soit activé). Sur un hébergeur mutualisé, il est peut-être plus prudent de stocker les données de sessions dans une base de données. Consultez la documentation de la fonction session_set_save_handler() pour en savoir plus sur la personnalisation de la gestion du stockage des données de sessions.

Durée de vie

L’un des points les plus délicats à appréhender dans le mécanisme des sessions concerne la durée de vie. Dans cette section, nous allons voir qu’il y a plusieurs facteurs qui permettent de déterminer la durée de vie d’une session.

On doit, dans un premier temps, distinguer le cas pour lequel l’identifiant de session est transmis par l’URL de celui où un cookie est utilisé.

Dans le premier cas, la session existera tant que l’identifiant sera transmis par l’URL. En fait, même recopiant la même adresse dans un autre navigateur, la session sera retrouvée.

Si on utilise un cookie, la durée de vie d’une session dépendra de la durée de vie d’un cookie. Cette durée est définie à l’aide de la directive session.cookie_lifetime. Si cette valeur vaut 0, alors le cookie sera maintenu par le navigateur tant que ce dernier ne sera pas quitté par l’utilisateur.

La plupart des directives de manipulation des sessions définies dans la configuration de PHP peuvent être modifiées dynamiquement pour un script, à condition que ces modifications interviennent avant le démarrage d’une session avec session_start(). Si le démarrage automatique est actif, vous ne pourrez pas manipuler ces valeurs. Pour pouvoir faire quelques tests, j’ai utilisé la fonction session_set_cookie_params().

Le script qui suit affiche la durée de vie restante du cookie de session et une chaine de caractère définie à la création de la session. Tant que cette valeur ne change pas, cela signifie que la session utilisée est toujours la même.

<?php
// Durée de vie de la session (Time To Live)
$ttl = 10;
session_set_cookie_params($ttl);
 
session_start();
 
if(!isset($_SESSION['foo']) || !isset($_SESSION['bar'])) {
  $_SESSION['bar'] = uniqid();
  $_SESSION['foo'] = time()+$ttl;
}
 
echo 'TTL de la session ('.$_SESSION['bar'].') : '.(($_SESSION['foo'])-time());

Voici quelques tests que j’ai effectué :

En choisissant la valeur 10 pour la variable $ttl et en actualisant régulièrement la page, on voit la valeur TTL diminuer puis la session se renouveler (nouvelle chaine de caractère affichée);
En choisissant la valeur 60, j’ai eu le temps de relancer mon navigateur avant la suppression du cookie, et de constater que la session était toujours active;
En choisissant la valeur 0, la session était toujours active plus d’une heure après sa création, mais elle n’a pas résisté à la fermeture d’un navigateur.

Ramasse-miettes

Nous avons vu ce qui causait la mort d’une session du côté du client, mais lorsque le cookie est supprimé, ou que l’identifiant n’est plus transmis, les données stockées sur le serveur ne sont pas supprimées pour autant.

PHP a donc mis en place un système de ramasse-miettes (ou garbage collector en anglais) chargé de supprimer ces données persistantes au bout d’un certain temps. Cependant, ce temps n’est pas nécessairement le même que celui de la durée de vie du cookie.

La durée de vie des données sur le serveur est définie par la directive session.gc_maxlifetime. Si les données ont été supprimées du serveur avant que la session ait expirée chez le client, cette dernière est tout de même réinitialisée. Il faut donc considérer (et c’est bien théorique, voir ci-dessous) que la durée de vie réelle d’une session est la plus petite des valeurs entre la durée de vie du cookie et la durée de vie des données sur le serveur.

La donnée ne sera effectivement supprimée que lorsque le ramasse-miette sera appelé. Cette action est effectuée aléatoirement lors du démarrage de la session, la probabilité de son déclenchement est défini par deux directives : session.gc_probability et session.gc_divisor. On a donc :

probabilité d'appel = gc_probability/gc_divisor

Les valeurs par défaut sont respectivement 1 et 100, la probabilité est donc 1/100.

Assurer la durée de vie de la session

Si vous choisissez de modifier la durée de vie de la session du côté du client (avec session_set_cookie_params()), il faudra appliquer les mêmes règles au ramasse-miettes. Cette opération ne peut être effectuée qu’en modifiant la directive session.gc_maxlifetime de php.ini.

Il est tout à fait possible de faire cette modification avec la fonction ini_set(), mais il faudra prendre certaines précautions. En effet : l’appel à ini_set() modifie dynamiquement la configuration, ainsi, lors d’une autre exécution, PHP considérera la valeur écrite statiquement dans les fichiers de configuration. Au passage, ce raisonnement est également valable lorsque la valeur de la directive est modifiée dans un fichier htaccess. Afin de garantir la durée de vie souhaitée à nos données de sessions, la méthode la plus simple consiste à les rendre inconnues pour un autre script ; autrement dit, s’affranchir plus profondément de la configuration statique de PHP.

La solution la plus simple consiste à choisir un autre répertoire de stockage des données de session, un sous-répertoire par exemple :

<?php
$ttl = 3600; // Une heure, en secondes
$local_sessions_save_path = ini_get('session.save_path').'/monsiteweb';
 
session_set_cookie_params($ttl);
ini_set('session.gc_maxlifetime', $ttl);
ini_set('session.save_path', $local_sessions_save_path);
 
session_start();

Avec cette solution, le garbage collector appelé dans le contexte d’un autre script supprimera les sessions périmées dans le répertoire défini par session.save_path, et non le sous répertoire que nous avons choisi. Pensez quand même à créer ce sous-répertoire !

Liaison d’autres données à la session

Dans certains cas, on peut souhaiter sauvegarder des donnés liées à une session sans utiliser la variable $_SESSION : un fichier envoyé par l’utilisateur, des données temporaires dans une base de données, etc.

Ces données ne seront pas supprimées par l’implémentation par défaut du ramasse-miettes. Nous allons donc devoir surcharger le gestionnaire de sessions par défaut, composé de six fonctions, qui se chargeront de :

l’ouverture de la session,
la fermeture,
la lecture des données de session,
l’écriture,
la suppression de la session,
le ramasse-miettes/garbage collector.

Une fois ces fonctions créés, il faudra les déclarer au moteur PHP avec session_set_save_handler().

Dans la suite de cet article, je vais surcharger le gestionnaire de sessions en reprenant le fonctionnement de celui apr défaut de PHP. Il est d’ailleurs très largement issu de l’exemple donné dans la documentation officielle. Dans certains cas, il aurait été utile de sauvegarder les données dans la base de données.

J’ai choisi d’utiliser une classe statique (MySessionHandler) pour centraliser ces fonctions, mais ce n’est pas une obligation.

<?php
class MySessionHandler
{
  protected $save_path = '';
 
 /**
  * On interdit la construction, puisque ce n'est pas nécessaire.
  */
  private function __construct() {}
 
 // Nous placerons ici les méthodes développées à la suite
}

Ouverture de la session

La fonction d’ouverture sera appelée avec deux paramètres : le chemin de sauvegarde et le nom de la session. Ces données seront transmises par le moteur de PHP. Cette fonction se chargera de conserver, pour le script courant, le répertoire de sauvegarde des sessions. Dans la mesure où cette donnée est transmise par le moteur de PHP lui-même, les autres fonctions de manipulation des sessions que nous avons vu avant sont toujours fonctionnelles.

Nous n’avons pas besoin de l’identifiant de session pour cette implémentation.

/**
  * Méthode d'ouverture de la session, c'est
  * @param string $save_path
  * @param string $session_name
  * @return bool
  */
  public static function open($save_path, $session_name)
  {
    self::$save_path = $save_path;
    return true;
  }

Fermeture de la session

Cette méthode est la plus simple : puisque rien de particulier n’est effectué à l’ouverture de la session, on ne fait rien à la fermeture :

/**
  * Fermeture de la session, exécutée à la fin du script
  * @return bool
  */
  public static function close() {
    return true;
  }

Lecture des données

La lecture des données consiste à récupérer les données écrites dans un fichier avant une précédente fermeture. Il faut donc vérifier que la session existait déjà, et n’a pas été supprimée.

Cette fonction doit impérativement retourner une chaine de caractères (string). Le moteur de PHP se charge lui-même de la sérialisation/désérialisation des données avant et après la lecture/écriture. Nous retournons donc directement le bloc de données lu, sans modifications :

/**
  * Lecture des données de session sérialisées.
  * @param string $id identifiant de la session
  * @return string
  */
  public static function read($id)
  {
    $return = '';
    $sess_file = self::$save_path.'/sess_'.$id;
    if(is_readable($sess_file))
    {
       $return = file_get_contents($sess_file);
    }
    return $return;
  }

Écriture des données

De la même manière, on écrira le bloc de données transmis par PHP directement dans le fichier de session. La méthode prendra deux paramètres : l’identifiant de session, et le bloc de données.

/**
  * Écriture des données de la session.
  * @param string $id
  * @param string $data
  * @return bool
  */
  public static function write($id, $data)
  {
    $res = false;
    $sess_file = self::$save_path.'/sess_'.$id;
    if(is_writable($sess_file))
    {
      $res = file_put_contents($sess_file, $data);
    }
    return $res;
  }

Destruction de la session et garbage collector

La suppression des données de session peut être effectuée à deux moments : lors de sa destruction explicite (avec session_destroy()) ou au passage du garbage collector. Nous allons donc implémenter une méthode delete() qui supprimera une session, et qui sera appelée par destroy() et gc().

Dans cet exemple, on supposera que certaines données, stockées dans un répertoire data/sessions/[identifiant de session] sont d’autres données liées aux session que nous souhaitons supprimer. On peut également imaginer devoir supprimer des données dans une base de données.

/**
  * Suppression des données d'une session.
  * @param string $id
  * @return void
  */
  protected function delete($id)
  {
    unlink(self::$save_path.'/sess_'.$id);
    // on suppose ici que le répertoire de session n'a pas de sous-répertoire.
    $sess_dir = 'data/sessions/'.$id;
    $to_delete = scandir($sess_dir);
    foreach($to_delete as &$file)
    {
      if($file == '.' || $file == '..') continue;
      unlink($sess_dir.'/'.$file);
    }
    rmdir($sess_dir);
  }
 
 /**
  * Destruction de la session.
  * @param string $id
  * @return bool
  */
  public static function destroy($id) {
    self::delete($id);
  }
 
 /**
  * Ramasse-miettes
  * @param int $maxlifetime
  */
  public static function gc($maxlifetime)
  {
    $toDelete = glob(self::$save_path.'/sess_*');
    foreach($toDelete as &$id)
    {
      self::delete($id);
    }
  }

Attention à l’identifiant de session !

Dans notre exemple ci-dessus, on se base sur l’identifiant de session pour connaître les fichiers associés à une session. N’oubliez pas que cette pratique n’est pas nécessairement idéale, puisque par sécurité, cet identifiant risque d’être modifié !

Conclusions

Attention, cet article permet de comprendre quelques points importants, mais ne prétend naturellement être complet (on en est même loin !). N’oubliez pas de faire vos propres tests et de lire d’autres articles pour en savoir plus, et plus particulièrement sur la sécurité, car je ne l’ai développé que pour mettre en garde quand à l’existence de risques liés aux sessions.

Facebook distribue sous licence open-source un traducteur PHP vers C++

Martin Richard — Tue, 02 Feb 2010 23:41:00 +0100

L’équipe des développeurs de Facebook a annoncé aujourd’hui la distribution (dans un futur proche) d’un outil permettant de traduire en C++ et compiler du code PHP : HipHop for PHP. D’après l’annonce officielle, cet outil permettrait à Facebook de réduire de près de 50% en moyenne la sollicitation du processeur sur la plupart des pages du service, dont le front-end a été essentiellement développé avec PHP.

PHP est un langage de programmation qui offre de nombreux avantages : une syntaxe souple, facile à apprendre et comprendre, une grande variété d’outils simplifiant le développement, une bibliothèque de fonction couvrant la plupart des besoins des développeurs d’applications web et c’est un produit libre. Ces avantages se traduisent facilement en excellents rapports coûts/temps de développement, ce qui rend le choix de PHP dans un processus de développement agile encore plus pertinent.

D’un autre côté, PHP est un langage interprété : le fichier source sera de nouveau lu et traduit en langage machine avant chaque exécution. Des outils permettent de mettre en cache une partie de ce traitement (les optimiseurs d’opcode) améliorent sensiblement les performances d’une exécution.

Pour les équipes d’ingénieurs de Facebook, ce n’était probablement pas suffisant, car ils ont développé en interne HipHop for PHP, afin de permettre à un script PHP d’approcher les performances d’un programme compilé en C++.

Des compilateurs PHP existent déjà, quelle est donc la valeur ajoutée de HipHop ?

Contrairement à Roadsend ou phpcompiler, HipHop n’est pas à proprement parler un compilateur. L’outil est en fait une chaine de traitement qui mènent à une version compilée, mais passant par une phase de traduction du langage en C++ optimisé pour les besoins. On supposera déjà qu’il est pratiquement inutile d’essayer d’analyser et modifier directement ce code C++ généré. Ce dernier sera compilé par le compilateur Gnu, g++.

La traduction s’effectue en trois étapes majeures :

Une analyse statique permet de collecter les informations sur les déclarations et les dépendances entre les fichiers composant le script : à priori, une table des symboles (classes/méthodes/fonctions) est dressée.
Une seconde analyse permet de choisir le type C++ optimal utilisé pour les symboles et variables (j’en reparle un peu plus bas).
Enfin, les instructions en PHP sont traduites en C++. Cette opération est essentiellement une conversion syntaxique (les deux langages sont assez proches du point de vue de la syntaxe).

Quelles sont les limites ?

A priori, la quasi-totalité de la grammaire du langage a été retranscrite, il est même probable que la plupart des librairies soient utilisables, dans la mesure où celles-ci, tout comme le moteur Zend de PHP, sont écrites en C.

La plupart des gains réalisés proviennent de l’optimisation de la “magie” de PHP, c’est à dire, l’ensemble des instructions qui nécessitent une évaluation dynamique. L’exemple le plus évident est probablement le transtypage à la volée. En effet, dans la mesure où PHP est un langage faiblement typé, il est possible de manipuler une variable sans restreindre son type : on peut facilement passer d’un entier à une chaine de caractères, par exemple. Cette souplesse à un coût, puisque le moteur PHP doit évaluer et déterminer le type de l’information manipulée (coût CPU), et en stocker une copie dans les principaux types (coût mémoire).

HipHop ne remplacera naturellement pas le travail d’optimisation du développeur, il est même possible de s’imposer quelques nouvelles contraintes, comme limiter les transtypages implicites.

Par ailleurs quelques fonctionnalités propres à un langage interprétés n’ont pas été portées en raison de la complexité de l’opération et du faible gain, comme la fonction eval(). On peut tout de même supposer que les noms de symbôles obtenus dynamiquement (voir ci-dessous) fonctionneront, puisque je suppose qu’on peut relativement facilement remplacer le mécanisme par des pointeurs sur fonctions en C++.

<?php
// Manipulation dynamique de symbole : on instancie une
// classe dont le nom est stocjé dans une variable
$classe = 'PDO';
$monObjet = new $classe(); // on vient d'appeler le constructeur de la classe PDO

En savoir plus

Pour ce soir (heure française), on doit se contenter de cette annonce : on ne sait pas encore exactement quelle licence sera choisie (on sait néanmoins que l’outil sera opensource), le code n’est pas encore disponible et le wiki mis en place n’est pas encore public. J’espère donc avoir rapidement l’occasion et le temps de faire des tests et des comparatifs de performance (avec un framework comme symfony par exemple).

Mise à jour : La licence retenue est la licence de PHP, le projet sera bientôt disponible publiquement sur le github de facebook.

HipHop for PHP serait déjà utilisé en production sur Facebook, on peut donc supposer que la première version mis à disposition sera déjà stable et bien avancée.

Annonce officielle sur le blog des développeurs de Facebook

BeGood Basketball Services

Martin Richard — Tue, 26 Jan 2010 17:12:00 +0100

BeGood Basketball services est une agence de placement de joueurs et de joueuses de basket professionnel. Martius Web à réalisé la charte graphique, l’intégration à Dotclear et un module d’accès restreint pour limiter la consultation des données des joueurs aux visiteurs s’étant enregistrés.

Visiter le Site Begood Basketball Services

Étudiant et Auto-entrepreneur : interview par La Manu

Martin Richard — Thu, 05 Nov 2009 21:57:00 +0100

La manu “fabrique le lien entre les étudiants et les entreprises”, par le biais de plusieurs actions, dont la publication d’un magazine à destination des étudiants de la fac. Dans le cadre d’un article sur l’auto-entrepreneur, on trouve notamment une intervention de votre serviteur !

Lire l’article “300 000 auto-entrepreneurs et moi, et moi, et moi ?”

Une opportunité tout aussi intéressante pour les étudiants qui veulent tester une idée ou financer leurs études. Du haut de ses 19 ans, Martin Richard conciliait DUT Informatique et services en développement de sites Internet dès le mois de février. Il s’est lancé avec 70 euros (pour ses cartes de visite) et l’aide de ses profs pour la rédaction des contrats et les aspects administratifs et comptables.

« Quand les gens me rencontrent, ils ne sont pas rassurés en raison de mon âge, reconnaît-il. Mais ils finissent par me faire confiance. » Sa technique ? La création d’un réseau qui débute par les cercles proches - famille, amis de la famille, etc., la publication régulière d’articles dans un magazine spécialisé et des risques bien calculés.

Martin mène bien sa barque, il n’en demeure pas moins que ses semaines sont très chargées et ses responsabilités importantes. De plus, il poursuit ses études en Master cette année.

Lire l’article “300 000 auto-entrepreneurs et moi, et moi, et moi ?”

PHP Solutions : Robots d'indexation et référencement

Martin Richard — Wed, 04 Nov 2009 23:33:00 +0100

Article paru dans le magazine PHP Solutions (Août 2008). Attention cet article n’est pas soumis à la licence Creative Commons : tous les droits de cet article sont réservés.

La visibilité de votre site internet est l’un des principaux atouts de son succès, et la maîtrise des moteurs de recherche et du référencement peut vous faire gagner de précieuses visites.

Note : Cet article contient plusieurs références n’étant pas à jour, notamment concernant les informations techniques liées aux traces laissées par les robots d’indexation des moteurs de recherche sur votre site, ou même le nom du moteur de recherche de Microsoft (qui s’appelle maintenant Bing, mais vous le savez déjà).

Cet article explique :

Les bases d’un algorithme d’exploration et d’indexation du web,
Les principales règles d’optimisation du référencement (SEO),
Comment concevoir un terrain d’accueil pour améliorer l’expérience de l’utilisateur.

Ce qu’il faut savoir :

Les principaux éléments de la syntaxe des expressions régulières,
Des bonnes notions du langage PHP et les bases de la programmation orientée objet.

Vous allez voir dans les grandes lignes comment se comporte un robot d’indexation (ou spider) afin de mieux en comprendre le fonctionnement. Pour cela, vous allez tenter de concevoir le notre. Un robot est un programme chargé de parcourir automatiquement le web pour enregistrer des informations issues des documents visités.La plupart du temps, les robots ne sont capables d’analyser que du contenu textuel, ce qui correspond à un grand nombre de types de fichiers. Le contenu binaire comme les images, la musique ou les vidéos est beaucoup plus difficile à indexer, c’est pourquoi nous n’en parlerons pas dans cette partie.

Les robots d’indexation sont utilisés par les moteurs de recherche avant tout, pour alimenter leur base de données. Mais ils sont aussi utilisés dans des outils de veille, souvent dans des projets d’études universitaires, comme les outils de statistiques d’utilisation et de modification du contenu de wikipédia, ou encore les institutions ou organismes nationaux chargés de contrôler pour certains la présence de contenu litigieux. Alors que certains
robots ont tout intérêt à signaler leur visite, les robots des moteurs de recherche notamment, d’autres chercheront à être plus discrets.

On décrit l’indexation des pages par les robots en deux phases. La première est couramment appelée crawling, elle correspond au parcours du web le plus largement possible. La seconde phase est l’indexation du document, c’est à dire l’analyse du contenu. À partir de ce principe simple, il est possible de créer des robots ayant des applications particulièrement variées.

Pour indexer correctement un document, il faut choisir les éléments porteurs de sens. L’analyse des fichiers comme les images, les applets Java ou les animations flash ne sera pas traitée ici car elle nécessite l’utilisation d’algorithmes complexes. On se limitera également à l’analyse d’une page HTML, mais le principe reste le même pour des documents comme les PDF, OpenDocument (format utilisé par OpenOffice) ou OpenXML (format apparu avec Microsoft Office 2007).

Certains éléments de la page n’ont aucune utilité pour un robot, il faut donc être capable de sélectionner ceux qui seront porteurs de contenu pour gagner en pertinence. On peut lister les principales balises HTML utiles. Les éléments d’en-tête et meta : ils contiennent des informations techniques ou sémantiques sur la page web fournies par le créateur de la page. Ils peuvent contenir des informations pertinentes, mais sont aussi utilisés de manière détournée pour spammer les robots, c’est pourquoi les moteurs de recherche y accordent de moins en moins d’importance. On pourra tout de même s’y intéresser car ils contiennent généralement quelques informations utiles.

La balise <title> est particulièrement utilisée par les moteurs de recherche, c’est pourquoi aujourd’hui elle contient généralement le titre de la page mais aussi des mots clés précieux et pertinents sur le contenu. Les balises <h1> à <h6> sont les titres de section. Ils ont le même intérêt que le titre de la page : ils donnent généralement des mots clés pertinents pour identifier le sujet du contenu qui le suit.

Les ancres et liens hypertextes <a> sont essentiels pour plusieurs raisons. Ils permettent d’établir une carte du web, utilisée pour le crawling, mais aussi pour évaluer la pertinence de la page dans le cadre étudié. Par exemple, le pagerank de Google consiste à attribuer une notre de pertinence en fonction du nombre de pages qui lient celle étudiée et le pagerank de celles-ci. Les emphases, telles que <strong> ou <em> peuvent permettre de mettre en valeur un mot ou une phrase particulièrement pertinente, mais leur intérêt reste relativement limité.

Par ailleurs, il faut également pouvoir détecter les commentaires HTML pour les ignorer : ils n’apportent pas de contenu pour la page puisqu’ils ne sont pas affichés, il n’est donc pas nécessaire d’en tenir compte pour indexer une page. On peut aussi lister un certains nombres d’attributs de balises HTML qu’il faut prendre en compte pour créer notre robot.

L’attribut href contient l’adresse d’un lien vers une page depuis la page que nous analysons,
src contient l’adresse d’un document inclus dans la page (une image ou un fichier javascript par exemple),
title est généralement utilisé pour commenter une image ou un lien,
alt contient du texte alternatif affiché à la place d’une image quand cela est impossible, comme il nous est impossible d’analyser une image, cet attribut doit être utilisé pour ne pas manquer d’informations,
les attributs rel et rev servent à préciser le comportement à avoir pour suivre les références avant et arrière de la page (href).

Même si nous n’essayerons pas de développer cette fonctionnalité, on peut envisager d’introduire un système de pondération permettant de valoriser différemment le contenu des différents types de balises, en intégrant par exemple un coefficient de 1 pour l’ensemble du contenu, de 10 pour l’ensemble des mots clés du titre <title> et 3 points pour les emphases comme <strong> ou <em>. Cette idée permettrait d’améliorer la qualité de l’analyse, mais rendrait l’indexation probablement beaucoup plus gourmande en mémoire.

Développer notre robot

Maintenant que nous avons fixé les éléments sur lesquels notre robot doit porter son attention, nous pouvons passer à son développement. PHP permet d’ouvrir certains fichiers sur des serveurs distant grâce à l’implémentation de certains protocoles, notamment HTTP et FTP. Cependant, pour que ceci soit possible, il faut que la directive allow_url_fopen soit activée dans le fichier de configuration php.ini, sachant qu’il est impossible de l’activer dynamiquement avec la fonction ini_set()pour des raisons de sécurité.

Nous pouvons donc simplement appeler notre fichier en utilisant file_get_contents($url);. Reportez vous au constructeur (__construct(), du code source) de la classe spider pour en savoir plus. Il serait judicieux de vérifier si le fichier téléchargé est bien un document HTML, voire même effectuer ce test avant l’appel à file_get_contents(), mais ce test n’est pas toujours évident à réaliser, nous effectuerons donc cette tâche pendant l’analyse du fichier.

On commencera par supprimer les commentaires puis séparer l’entête du contenu (le <head> du <body>) pour limiter le domaine de recherche des expressions, afin d’économiser un peu de temps d’exécution et de ressources. On utilisera plusieurs expressions régulières
dans cet article, elles fonctionnent dans un cas standard mais probablement moins bien quand le code est mal conçu, c’est à vous de les adapter aux usages rencontrés, ce qui constitue probablement le principal défi posé par le développement d’un robot de ce type. Idéalement, si toutes les pages analysées étaient bien conçues, nous aurions pu utiliser l’implémentation en PHP de l’API DOM, rendant
l’analyse moins hasardeuse et plus commode à développer.

Pour supprimer les commentaires, on utilisera l’expression régulière PERL ``im. Elle n’est peut-être pas idéale mais n’est pas très lourde. Voici son fonctionnement :

Les caractères ` délimitent la chaîne recherchée,
i est un modificateur qui indique à PHP que la recherche est insensible à la casse,
m est un second modificateur permettant de faire une recherche sur plusieurs lignes,
une assertion (entre parenthèses) est définie comme «non-capturante» par les caractères ?:, par souci d’économie,
\s|. permet de choisir n’importe quel caractère (.) ou un caractère blanc (\s, espace, retour à la ligne, etc),
enfin, le quantificateur * permet de sélectionner ce motif zéro, une ou plusieurs fois, il est suivi de ? qui rend ce quantificateur non-gourmand, il capturera donc la chaîne la plus courte possible qui satisfait le motif, et s’arrête donc avant le premier motif -->.

On remplace le motif précédant par une chaîne vide de cette façon : preg_replace('``im', '', $contenu);. Les autres motifs utiliseront généralement une syntaxe similaire, c’est pourquoi nous ne détaillerons que les éléments variants. Pour obtenir séparément le contenu de l’entête, on utilise cette expression régulière : `<body(?:[^>]*)?>((?:\s|.)*?)</body>`im, qui ne change pas beaucoup de la précédente : on ajoute la prise en charge des différents attributs possibles de la balise <body> grâce au motif (?: [^>]*)?, ce qui correspond à un nombre quelconque de caractères différents du > ([^>]*).

On peut maintenant analyser les méta-tags et vérifier le type de fichier que nous analysons. On retiendra deux types mime : text/htmltext/xhtml+xml, même si ce dernier est peu utilisé car les navigateurs trop anciens ne le reconnaissent pas. Pour analyser l’ensemble des métas, on utilise la fonction preg_match_all() et le motif `<meta (?:http-equiv|name)="(.+?)" +content="(.+?)"(?:/)?>`im qui n’apporte rien de nouveau dans sa syntaxe, sauf l’ajout de l’éventuel / présent en XHTML. Il est maintenant possible d’analyser le contenu. Les balises comme <p>, <h[1-6]>, et <strong> utilisent des expressions régulières presque identiques, c’est pourquoi je ne détaillerai que l’analyse des paragraphes <p>. Le contenu de la page étant placé dans le corps, la recherche est limitée à notre section <body>. On utilisera une expression régulière basée sur la même syntaxe que les précédentes : `<p(?: [^>]*)?>((?:\s|.)*?)?</p>`im, c’est pourquoi je ne la détaillerai pas non plus. Après avoir capturé le contenu des paragraphes, nous pouvons le débarrasser des balises HTML avec la fonction strip_tags() pour compter les caractères avec strlen() et les mots (c’est à dire chaque suite de caractères entourée d’espaces) avec sizeof(explode(' ', $chaine)).

L’analyse des liens et des images utilise à nouveau les même filons, comme présenté dans la fonction Parse() du code source de la classe, vous constaterez que le code est relativement répétitif. L’analyse des liens permet de dresser la carte des pages accessibles depuis la page étudiée, c’est pourquoi elle est importante pour la suite (l’étape de crawling). Les liens peuvent être indiqués de manière relative dans la page, il faut donc que nous les modifions pour obtenir l’adresse absolue de chaque lien sur la page. La première étape est de vérifier si on trouve un schéma d’adresse tel que http:// (indiquant qu’elle est exprimée de manière absolue) en début de chaîne, si il est absent, l’adresse doit être complétée. Sinon, on remplace une éventuelle chaîne ./ par le complément.

On devine généralement le complément grâce à l’adresse de la page courante, mais il peut arriver que les liens soient définis relativement à une autre adresse, définie par la balise <base />. Vous pouvez vérifier en détail comment sont analysées les liens dans la fonction Link() et comment est devinée la racine des liens avec la fonction Root() de la classe. Une fois notre classe Spider terminée, nous pouvons ajouter une fonction statique qui permet de lancer les opérations de crawling et d’analyse (appelée Analyse()).

Code source de la classe Spiders

Apprivoiser les robots et les moteurs de recherche sur son site

La plupart des robots des moteurs de recherche visitent votre site en s’annonçant, il peut donc être pratique de les détecter pour par exemple, les compter séparément des visiteurs dans les statistiques. Commençons par dresser une liste (non exhaustive) des principaux robots connus. Googlebot, le principal robot de Google visite le web très régulièrement en mode Fresh Bot, il peut faire plusieurs passages sur une page par jour. Le Fresh Bot analyse le texte et non la structure, tandis que le Deep Bot visite une page plus rarement mais l’analyse, comme son nom l’indique, plus en profondeur.

Le robot Slurp d’inktomi, racheté par Yahoo! fonctionne d’une manière assez similaire à Googlebot, mais ne classe pas pour autant les pages de la même manière. Par ailleurs le crawling semble moins régulier, mais généralement assez profond. Le robot de MSN Live est un peu moins célèbre, mais possède quelques options intéressantes, comme la possibilité, depuis peu, de lui conseiller la fréquence des visites la plus pertinente pour indexer vos pages (liée à la fréquence des mises à jour).

Ces robots peuvent analyser une page en profondeur grâce aux balises HTML et leur sens, c’est pourquoi les respecter vous permet d’optimiser intelligemment vos pages pour un meilleur référencement. Il est temps de dire définitivement adieu à la mise en page basée sur les tableaux.

L’art du référencement et de la SEO (pour Search Engine Optimization) est assez complexe mais puissant, et il impose de suivre quelques règles dont certains sont devenus spécialistes. La règle absolue, c’est la qualité du contenu : plus il est intéressant, plus votre site aura de chances de devenir populaire. Les artifices techniques ne permettront pas à eux seuls une bonne visibilité sur internet, mais ils ne sont pas non plus négligeables. Les robots ne parcourent pas toujours toute la page, stratégiquement, placer les liens en début de page et au sein du contenu, sur des mots clés choisis avec soin, valorisera le référencement des pages cibles. Par exemple, lorsque vous publiez un article, n’hésitez pas à faire des liens vers d’autres pages sur le même sujet, car le robot pourra l’étudier avec le contenu autour de ce lien pour multiplier les mots clés. Par ailleurs, remplissez aussi les attributs title des liens avec d’autres mots clés, vous multiplierez ainsi vos chances d’apparaître dans des listes de résultats. Par ailleurs, des organismes travaillent sur des nouvelles normes et technologies pour qu’un document numérique soit le plus efficacement compréhensible par les systèmes informatiques.

Ces technologies pourraient permettre d’indexer efficacement un maximum de pages, elles servent aujourd’hui certaines bibliothèques et archives (comme la banque de données de l’organisation mondiale de la santé). L’une des normes les plus prometteuses est probablement RDF (pour Resource Description Framework), appliquée notamment à la syntaxe XML. Elle permet de décrire intelligemment une grande variété de contenu comme des ressources web et leurs métadonnées (données à propos d’autres données). Vous pouvez commencer à travailler avec ces technologies dans vos documents XML, car des robots d’indexation de fils XML (comme les flux RSS et ATOM) apparaissent depuis quelques années.

Le projet Dublin Core, avec l’utilisation du couple XML/RDF permet de décrire 15 propriétés sur un document numérique, comme le titre, la description, le format ou l’auteur. Il permet donc de mettre une certaine ressource numérique en lien avec d’autres ressources. Dans une page HTML, il est possible d’introduire les métadonnées Dublin Core à l’aide de la balise meta, comme présenté ci-dessous. Vous aurez plus de détails sur cette syntaxe sur le site officiel du projet Dublin Core : http://dublincore.org/documents/dcq-html/.

<meta name="DC.Title" content="Titre de document" />

Pour en savoir plus sur les métadonnées et leur utilisation, rendez vous sur la page http://peccatte.karefil.com/software/metadata.htm qui vous renseignera sur un bon nombre d’initiatives lancées ces dernières années.

Il est important aussi de faire un point sur le comportement des robots vis-à-vis du contenu binaire, comme les images ou les animations Flash. Bien que Google étudie une manière d’analyser le contenu direct des images dans ses laboratoires, aucun moteur de recherche n’est actuellement capable de référencer directement une illustration. Dublin Core par exemple, pourrait palier à ce soucis, mais son application en ligne n’est pas vraiment développée. Par ailleurs, d’autres architectures de métadonnées comme EXIF permettent d’inclure des tags ou des détails sur l’image, mais celle-ci n’est pas réellement standardisée et n’est donc pas plus utilisée sur le web.

On peut faire une petite exception pour les photographies prises avec un appareil numérique qui contiennent des informations sur la date de prise de vue et le type d’appareil, mais généralement, les logiciels de retouche d’image font disparaître ces informations, on les trouve donc vraiment peu sur Internet. La meilleure manière actuellement pour référencer une image est de placer des mots clés dans le nom du fichier, et en renseignant les attributs title et alt des balises HTML img. Par ailleurs, les robots utilisent souvent les mots clés trouvés dans le texte entourant l’image, quelques lignes avant et après la balise img, les robots ne s’occupent pas de la mise en forme réalisée grâce aux CSS.

Le référencement des animations Flash est lui aussi problématique, en fonction de son utilisation. Un site entièrement basé sur une animation (schématiquement un nombre minimal de pages HTML avec une animation principale dynamique) sera presque impossible à référencer correctement. Si l’unité du site reste la page, une utilisation, même intensive, de Flash n’est plus vraiment un problème, et des solutions pour une intégration valide selon les normes du W3C et accessible (pour les victimes d’un handicap et les robots) on été trouvées.

Le code suivant présente la solution la plus facile et pratique, son inconvénient majeur est la perte de la détection automatique de la version du lecteur flash minimum requise.

<object type="application/x-shockwave-flash" data="animation.swf">
   <param value="animation.swf" name="movie">
   <p>Contenu alternatif.</p>
</object>

D’autres solutions sont proposées sur l’excellent site Web Rank Info : http://www.webrankinfo.com/actualites/200705-referencement-flash.htm, notamment une technique très à la mode le Flash satay, où un fichier flash fait office de contrôleur frontal pour toutes les autres animations, chargées en fonction des paramètres passés. Cette technique est également applicable aux applets Java, par exemple.

Enfin, une dernière problématique qu’il convient d’étudier concerne le référencement des sites internet intégrant la technologie Ajax ou d’autres fonctionnant avec Javascript. En effet, du contenu rendu disponible uniquement par un appel Javascript est rarement lu par un robot, bien qu’il semble que certains (Googlebot notamment) soient capables d’interpréter certaines fonctions Javascript basiques. Le meilleur moyen de rendre le contenu d’une page facile à référencer est de suivre les recommandations liées à l’accessibilité des pages dynamiques, notamment proposer une alternative plus classique pour obtenir le contenu.

Identifier et gérer le passage d’un robot

Les robots d’indexation des moteurs de recherche peuvent être identifiés grâce au client qu’ils annoncent utiliser ou leurs adresses. Ces informations sont disponibles dans les variables $_SERVER['HTTP_USER_AGENT'] ou $_SERVER['REMOTE_ADDR'].

Googlebot se présentera par l’une de ces chaînes :

Googlebot/2.1 (+http://www.google.com/bot.html),
Mozilla/5.0 (compatible; Googlebot/2.1;+http://www.google.com/bot.html),
Googlebot-Image/1.0.

et sera connu grâce à une adresse au format crawl*.googlebot.com.

Slurp, d’inktomi et Yahoo! peut être identifié par ces chaînes User-Agent :

Mozilla/5.0 (compatible; Yahoo! Slurp;http://help.yahoo.com/help/us/ysearch/slurp),
Mozilla/5.0 (compatible; Yahoo! Slurp China; http://misc.yahoo.com.cn/help.html)

et l’adresse sera au format crawl.yahoo.net.

Le troisième robot le plus connu est le robot utilisé par MSN :

msnbot/1.* (+http://search.msn.com/msnbot.htm),
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322),
Mozilla/4.0 (compatible; MSIE 4.01; Windows NT; MSN Mobile Proxy),
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12).

Les principaux hôtes utilisés sont msnbot*.search.msn.com ou livebot-*.search.live.com.

Vous pouvez obtenir plus de détails et références sur les autres robots d’indexation, leurs User-Agent ou leurs adresses sur ces pages :

http://www.robots.darkseoteam.com/ qui est une excellente référence informative, bien que tous les conseils ne soient pas à appliquer,

http://www.actulab.com/identification-des-robots.php qui propose une liste assez complète, bien qu’un peu datée des hôtes et User-Agent des principaux robots. qui est une excellente référence informative, bien que tous les conseils ne soient pas à appliquer,

L’identification des robots peut vous permettre d’améliorer le comptage de vos visiteurs et d’optimiser la fréquence de mise à jour de vos pages (les robots aiment les pages mises à jour).

Vous pouvez également demander à un robot de ne pas indexer certaines parties de votre site internet en plaçant à la racine d’un répertoire un fichier robots.txt contenant les règles User-Agent et Disallow, comme ceci :

User-agent: * # commentaire : tous les robots
Disallow: /cgi-bin/
Disallow: /perso/
Disallow: /entravaux/
Disallow: /abonnes/prix.html

La règle Allow est comprise par certains robots, mais n’existe pas réellement et n’est pas standardisée, il est donc déconseillé de l’utiliser. La règle User-Agent prend une valeur différente par robot (par exemple msnbot, googlebot) ou la valeur * pour concerner tous les robots. La règle Disallow précise quelles ressources ne doivent pas être indexées. Notez que vous ne devez pas laisser de ligne vide dans ce fichier, et qu’il est possible d’introduire des commentaires avec le symbole #.

Vous pouvez également indiquer d’autres règles de conduites au robots dans les balises HTML meta, en utilisant cette syntaxe :

<meta name="robots" content="attribut1,attribut2" />

où attribut1, peut prendre la valeur index (autorise l’indexation) ou noindex (pour l’interdire), et attribut2 peut prendre la valeur follow, pour que le robot suive les liens contenus dans la page et nofollow pour lui demander de ne pas suivre les liens de la page. Ce comportement peut également être décidé lien par lien grâce à l’attribut rel="nofollow" de la balise HTML a. Par défaut, un robot appliquera logiquement les règles index et follow. Par ailleurs, les robots peuvent également faire le choix de ne pas tenir compte de ces mesures (ce peut être le cas d’un robot de contrôle cherchant à être discret ou d’un renifleur utilisée à des fins parfois litigieuses), elles ne permettent donc pas rendre du contenu invisible sur internet.

Limites et dangers des techniques de Black Hat

Les techniques dites de Black Hat sont des techniques permettant de modifier l’analyse d’une page en détournant le comportement d’un robot. Ces techniques peuvent avoir différentes natures : insérer dans son code des mots clés rendus invisibles pour le visiteur par les CSS, ou retourner une page différente de la page publique quand le robot est détecté. D’autres techniques beaucoup plus poussées existent, mais le but cet article n’est pas de les détailler.

Ces techniques sont dangereuses car elles peuvent très rapidement pénaliser le référencement plus que l’améliorer. En effet, la plupart des moteurs de recherches sont capables de détecter ces techniques, même les plus poussées, et peuvent mettre les pages concernées ou le site en liste noire et le bannir définitivement de ses résultats.

Concevoir son terrain d’accueil

Un terrain d’accueil (ou page d’atterrissage, landing page) est une page (ou un élément de la page) qui apparaît quand un utilisateur accède au site internet depuis un moteur de recherche et qui contient généralement du contenu adapté à la requête du visiteur. Un terrain d’accueil est particulièrement intéressant pour proposer du contenu qui pourrait intéresser le visiteur même si il n’est pas n’est pas arrivé sur une page correspondant à sa recherche.

Un terrain d’accueil efficace doit fonctionner avec plusieurs moteurs de recherche. Pour vérifier qu’un utilisateur vient d’un moteur de recherche, on utilise la variable $_SERVER['HTTP_REFERER']. On vérifie alors si l’adresse de la page d’origine est l’adresse d’un moteur de recherche. Nous allons faire la vérification avec les trois principaux moteurs de recherche du marché : Google, Yahoo! et MSN.

Les adresses des pages de résultats de ces trois moteurs de recherche sont les suivantes :

http://www.google.fr/search?hl=fr&q=mon+mot+cle,
http://www.google.fr/search?hl=fr&q=mon+mot+cle,
http://search.msn.fr/results.aspx?q=mon+mot+cle.

Elles peuvent admettre d’autres paramètres qui ne sont pas intéressants, mais il sera nécessaire d’en tenir compte dans notre analyse du referer. On tiendra aussi compte de l’extension du nom de domaine qui peut varier. Il reste à étudier les expressions régulières à créer d’après ces adresses.

`http: //www\.google\.[a-z\.]+/search?.*?&?q=([\w%:+]+?)(?:&|$)`i,
`http://\w+\.search.yahoo.com /search?.*?&?p=([\w%:+]+?)(?:&|$)`i,
`http://search.msn.fr/results.aspx?.*?&?q=([\w%:+]+?)(?:&|$)`i.

On utilise une fois de plus la fonction preg_match() pour tester si l’adresse du referer est celle d’un moteur connu et récupérer les mots clés tapés par l’utilisateur grâce aux parenthèses capturantes, et urldecode() pour que ces mots clés soient exploitables.

$kw = array();
if(preg_match('`http://www\.google\.[a-z\.]+/search?.*?&?q=([\w%:+]+)(?:&|$)`i', $_SERVER['HTTP_REFERER'], $kw) > 0)
{
	$keywords = urldecode($kw[1]);
}
elseif(preg_match('`http://\w+\.search.yahoo.com/search?.*?&?p=([\w%:+]+)(?:&|$)`i', $_SERVER['HTTP_REFERER'], $kw) > 0)
{
       $keywords = urldecode($kw[1]);
}
elseif(preg_match('`http://search.msn.fr/results.aspx?.*?&?q=([\w%:+]+)(?:&|$)`i', $_SERVER['HTTP_REFERER'], $kw) > 0)
{
	$keywords = urldecode($kw[1]);
}
else
{
	$keywords = null;
}

Avec ces mots clés, vous pourrez effectuer une recherche interne à votre site pour proposer d’autres de vos pages susceptibles d’intéresser le visiteur, mettre en valeur ces mots clés dans la page ou encore proposer d’autres références pour l’inciter à rester sur votre site.

Les terrains d’accueil permettent d’améliorer le taux de rebond (ou taux de visite à une page) d’un site internet, et donc de le faire découvrir plus en détail au visiteur.

Conclusion

Vous avez maintenant quelques pistes pour analyser vos pages et améliorer leur référencement. Cependant, gardez en tête que le succès de votre site sera principalement lié à son contenu aux efforts de communication que vous ferez. N’hésitez pas à partir en quête d’informations sur internet, la SEO est devenue une discipline très à la mode depuis quelques années.

Aidez-nous à faire mieux ! Répondez à notre sondage !

Martin Richard — Sun, 01 Nov 2009 19:48:00 +0100

Un sondage (court, pas d’inquiétudes) a été mis en place pour permettre à Martius Web de faire mieux. Y répondre ne prend que quelques minutes, et peut nous filer un vrai coup de main ! N’hésitez pas à le transmettre si vous jugez ça bon

Merci !

Chargement…

Chargement automatique de classes avancé avec PHP 5

Martin Richard — Thu, 29 Oct 2009 16:04:00 +0100

PHP 5 a introduit de nombreux nouveaux concepts intéressants, notamment le chargement automatique des dépendances lors de l’utilisation d’une classe non définie. On utilise généralement à cette fin la fonction magique __autoload(). Mais depuis PHP 5.1.2, une séries de fonctions issues de la SPL (Standard PHP Library) spl_autoload_*() sont apparues.

Cet ensemble de fonction permet de mettre en place une stratégie de chargement dynamique plus fin, et nous allons ici essayer de découvrir pourquoi et comment.

Autoloading simple

Avant de rentrer dans les détails violents, nous allons commencer par faire un petit rappel (ou tout du moins une introduction) sur la notion. Les développeurs qui ne sont pas vraiment familiers avec le langage ne seront pas perdus : les mécanismes mis en place ici sont tout à fait accessibles.

On donne généralement plusieurs noms à cette fonctionnalité apparue avec PHP 5 : autoloading, chargement dynamique (ou automatique) de classes, inclusion implicite, et j’en passe. En fait, tous ces noms sont corrects… en fonction de la manière dont vous l’utiliserez. Disons qu’à la base, l’autoloading est arrivé pour faciliter la vie des développeurs dans la gestion des dépendances.

Dans un projet où l’orienté objet prend une place importante, on se retrouve souvent avec de nombreuses classes, elles-mêmes généralement réparties dans de nombreux fichiers (souvent une ou deux classes par fichier). Le développeur devait alors vérifier l’existence d’une classe avant de l’utiliser : il est nécessaire de demander à PHP d’interpréter sa définition pour qu’elle “existe”. On observait alors souvent une série de directives include ou require en tête de fichier, voire include_once et require_once pour éviter une inclusion multiple, causant une erreur fatale puisque PHP interdit la redéfinition d’un symbole existant. C’était un peu abstrait, mais j’imagine que vous ne découvrez pas ces problèmes si vous prenez la peine de vous renseigner sur le chargement automatique.

La fonction magique __autoload() a donc été introduite pour supprimer ces nombreuses inclusions, dont la maintenance devient fastidieuse dès que l’organisation des fichiers de l’application change un peu. On dit que cette fonction est magique, pas seulement parce qu’elle rend un grand service, mais aussi parce que PHP va être capable de l’appeler tout seul au bon moment, sans l’aide du développeur, afin d’alléger l’écriture du code. En fait, lorsque l’interpréteur rencontrera un nom (ou symbole) de classe inconnu, il appellera implicitement cette fonction en passant ce nom en paramètre.

À titre informatif, il est impossible de lancer une exception dans la fonction __autoload() car elle est exécuté à un moment qui ne peut être défini à priori (lors de l’interprétation du fichier ou de l’exécution du code utilisant la classe, par exemple ?). Plusieurs solutions basées sur la création dynamique d’une classe à l’aide de la fonction eval() on été proposées. Je les trouve généralement inutiles et dangereuses.

On peut imaginer une implémentation sommaire sous cette forme :

<?php
define('CLASSES_DIR', 'myproject/classes');
 
function __autoload($classname)
{
  require(CLASSES_DIR.'/class.'.$classname.'.php');
}

Ouf, du code ! Ici, on fait en sorte que pour une classe MyClass, PHP charge le fichier myproject/classes/class.MyClass.php, qui devrait, le cas échéant, contenir la définition de MyClass. C’est bien, mais encore un peu light dès qu’on cherche à décomposer l’organisation des fichiers en plusieurs répertoires.

On a alors plusieurs solutions : on peut demander à PHP de parcourir l’ensemble de nos répertoires pour trouver la classe, à l’aide de différentes implémentations :

<?php
 
define('CLASSES_DIR', 'myproject/classes');
 
function __autoload($classname)
{
  $classes_dirs = array('core', 'tools', 'model', 'dblayer');
  foreach($classes_dir as $dir)
  {
    $classpath = CLASSES_DIR.'/'.$dir.'/class.'.$classname.'.php';
    if(file_exists($classpath))
    {
      require $classpath;
      return;
    }
  }
}

On peut aussi faire encore pire : parcourir les répertoires à la recherche du bon fichier et l’inclure ensuite ! Ces méthodes, en plus d’être hasardeuses, sont très couteuses en ressources : on utilise une boucle et on réalise plusieurs opérations sur le système de fichier (qui font partie des opérations les plus lentes d’un programme, à cause notamment du temps d’accès au disque dur).

Une méthode plus élégante serait d’enregistrer dans un tableau la liste de chaque classe associé au fichier qui contient sa définition, on aurait alors, par exemple :

<?php
$_autoload['MyClass'] = 'core/class.MyClass.php';
$_autoload['MyModelClass'] = 'model/class.MyModelClass.php';
$_autoload['EmailEasing'] = 'tools/class.EmailEasing.php';

dans un fichier autoloading.php, et une implémentation de la fonction __autoload comme celle-ci :

<?php
define('CLASSES_DIR', 'myproject/classes');
 
function __autoload($classname)
{
  static $_autoload = null;
  if(is_null($_autoload))
    require 'autoloading.php';
 
  require CLASSES_DIR.'/'.$_autoload;
}

On fait un travail plus propre : le fichier contenant la liste des dépendances est inclus une seule fois grâce au fait que la variable soit statique et on évite des recherches inutiles. D’un autre côté, on perd une partie des avantages du chargement dynamique, puisque le développeur devra tout de même maintenir le fameux fichier de dépendances. Quand il n’y en a que quelques unes, ça va, mais c’est quand il y en a beaucoup…

De nombreuses solutions plus ou moins compliquées existent : effectuer une recherche puis mettre en cache, créer un script qui générera le fichier de dépendances qu’on appellera lors de la mise à jour du code, et plus exotique encore.

Un chargement dynamique natif avec `spl_autoload()`

Depuis PHP 5.1.2, les développeurs nous simplifient un peu la vie et offrent une réponse toute prête au dilemme posé plus tôt. Chouette !

Si aucune fonction __autoload() n’est définie, alors PHP utilisera la function native spl_autoload() par défaut à condition qu’on lui demande :

<?php
spl_autoload_register();

Son comportement est assez simple et se base sur une stratégie bien connue avec include et require : on cherche partout où la configuration dit de chercher, et on prend le premier trouvé. Pour ma fameuse MyClass, spl_autoload() va parcourir chaque répertoire définit dans la directive include_path à la recherche d’un fichier appelé MyClass.php ou MyClass.inc.

On peut obtenir une solution proche de celle décrite dans le deuxième exemple avec deux avantages : d’une part l’implémentation sera légèrement plus rapide et plus souple, d’autre part, elle fera appel à des fonctions natives, donc écrites en C, et donc qui seront presque à tous les coups plus rapides que notre propre version de __autoload().

Tout ceci est bien entendu paramétrable. Pour modifier la liste des répertoires parcourus, on peut modifier la valeur de la directive include_path dans le php.ini, ou utiliser le couple de fonctions set_include_path() et get_include_path(). Il est également possible d’ajouter des extensions à la recherche grâce à spl_autoload_extensions().

Pour reprendre notre second exemple, on pourra l’implémenter ainsi :

<?php
define('CLASSES_DIR', 'myproject/classes');
 
spl_autoload_extensions('.class.php');
 
set_include_path(
  CLASSES_DIR.'/core'.PATH_SEPARATOR.
  CLASSES_DIR.'/tools'.PATH_SEPARATOR.
  CLASSES_DIR.'/model'.PATH_SEPARATOR.
  CLASSES_DIR.'/dblayer'.
  PATH_SEPARATOR.get_include_path()
);
 
spl_autoload_register();

On place nos répertoires en premier pour qu’ils soient prioritaires, sans oublier d’ajouter les valeurs déjà définies avec get_include_path(). Par ailleurs, il est nécessaire de modifier légèrement notre convention de nommage des fichiers : class.MyClass.php devient nécessairement MyClass.class.php. Finalement, tout ça n’est pas très satisfaisant : comme on l’a évoqué tout à l’heure, les opérations sur le système de fichier ne sont pas très amies avec l’optimisation temporelle d’un script.

Avec des tests correspondant à votre situation, vous pourrez probablement choisir entre l’implémentation suivante et celle proposée dans le troisième exemple.

Concurrence d’autoloads

Sur un gros projet, vous allez parfois devoir manipuler plusieurs bibliothèques ou frameworks qui devront travailler en collaboration lors de l’exécution d’un script. Imaginez que chacune de ces bibliothèques possèdent leur propre implémentation de la fonction __autoload(). Ce cas de figure ne se présentera pas puisque PHP ne supporte pas la surcharge de fonctions, et le seul résultat qu’on pourra obtenir est une erreur fatale…

Grâce aux fonctions spl_autoload_*(), il est possible de manipuler plusieurs implémentations de chargement dynamique sans collisions. On utilise alors les méthodes spl_autoload_register() et éventuellement spl_autoload_unregister(). Ces fonctions permettent de gérer une file de fonctions exécutées les unes après les autres jusqu’à ce que le problème de dépendance soit résolu. Un petit exemple sera peut-être plus parlant :

<?php
 
function fantastic_framework_autoload($classname)
{
  file_exists('fantasticframework/classes/class.'.$classname.'.php') &&
  require 'fantasticframework/classes/class.'.$classname.'.php';
}
 
function helperslib_autoload($classname)
{
  file_exists('helpers/class.'.$classname.'.php') &&
  require 'helpers/class.'.$classname.'.php';
}
 
function __autoload($classname)
{
  static $_autoload = null;
  if(is_null($_autoload))
    require 'autoloading.php';
 
  require CLASSES_DIR.'/'.$_autoload;
}
 
spl_autoload_register('fantastic_framework_autoload');
spl_autoload_register('helperslib_autoload');
spl_autoload_register('__autoload');

Ici, pour chaque dépendance non satisfaite, PHP exécutera chaque fonction une à une jusqu’à ce que le problème soit résolu. Permettant ainsi de définir plusieurs stratégies différentes en fonction du contexte. L’ordre d’exécution est celui définit par l’ordre d’enregistrement des fonctions : ici fantastic_framework_autoload, helperslib_autoload et enfin __autoload.

Notez qu’il est nécessaire d’enregistrer manuellement __autoload(), spl_autoload_register remplace en effet le comportement par défaut de PHP. Il sera également nécessaire d’enregistrer manuellement la fonction spl_autoload() vue plus tôt si vous souhaitez l’utiliser.

Il est également important de noter qu’ici, il est nécessaire que les différentes fonctions utilisées ne puissent pas retourner d’erreur : le test de l’existence du fichier avant l’inclusion est obligatoire, sinon PHP affichera une erreur (causant l’arrêt du script avec require).

Synchroniser le système de fichier et le nom des classes

Une méthode qui peut être explorée consiste à utiliser le nom de la classe à charger pour deviner l’emplacement du fichier dans notre organisation. Ce cas de figure est particulièrement intéressant quand l’organisation est découpée en modules.

Par exemple, mon programme contient, entre autres, les classes suivantes : MyAppRequest, MyAppContext, MyAppConfig, ViewTemplate, ViewCache, DbConnection, et pour finir, EmailEasing.

Comme le projet a été réfléchi en amont et que ces noms correspondent à des conventions définies, tout ceci a un sens facilitant l’organisation du code :

le préfixe MyApp correspond aux classes faisant partie du coeur de l’application,
View correspond aux classes composant la partie vue (moteur de templates, etc),
Db aux outils permettant de manipuler la base de données,
et enfin le suffixe Easing signifie que la classe correspond à une bibliothèque simplifiant certaines opérations.

On peut alors facilement répartir ces classes dans des fichiers bien organisés :

sources/core, par exemple, MyAppRequest sera dans le fichier sources/core/class.Request.php,
sources/view,
sources/dblayer,
sources/libs.

On peut alors proposer une implémentation efficace, fine et protégée contre la concurrence assez facilement :

<?php
define('SOURCES_DIR', 'myproject/sources');
 
/**
 * Autoload pour notre application.
 * Attention, les noms de classes et de fichiers sont sensibles
 * à la casse.
 */
myapp_autoload($classname)
{
  $path = SOURCES_DIR.'/';
  $file = '';
  if(substr($classname, 0, 5) == 'MyApp'))
  {
    $path .= 'core/';
    $file = substr($classname, 5);
  }
  elseif(substr($classname, 0, 4) == 'View'))
  {
    $path .= 'view/';
    $file = substr($classname, 4);
  }
  elseif(substr($classname, 0, 2) == 'Db'))
  {
    $path .= 'dblayer/';
    $file = substr($classname, 2);
  }
  elseif(substr($classname, -6) == 'Easing'))
  {
    $path .= 'libs/';
    $file = substr($classname, 0, -6);
  }
}
 
spl_autoload_register('myapp_autoload');
if(function_exists('__autoload'))
  spl_autoload_register('__autoload');
spl_autoload_register('spl_autoload');

PHP 5.3 et les namespaces pour simplifier tout ça

La dernière solution que je vais développer utilise une nouvelle notion introduite dans PHP 5.3. C’est une version simplifiée de la précédente, et que j’envisage d’utiliser dans la plupart des projets en PHP 5.3 sur lesquels je travaillerais.

L’utilisation des namespaces (ou espaces de noms en français) permet d’organiser logiquement les classes en modules, afin d’éviter les collisions entre plusieurs classes portant le même nom. Par analogie, il est souvent intéressant de calquer l’organisation des fichiers avec l’organisation choisie pour les espaces de nom.

Avec les espaces de nom, une classe possède un nom absolu sous la forme namespace\subnamespace\MyClass. on aurait donc les classes et namespaces suivants :

namespace MyApp
- MyApp\Request
- MyApp\Config
- MyApp\Context
namespace View
- View\Template
- View\Cache
namespace Db
- Db\Connection
namespace Easing
- Easing\Email

Notre fonction de chargement automatique sera :

<?php
define('SOURCES_DIR', 'myproject/sources');
myapp_autoload($classname)
{
  // Au passage, pensez à échapper le caractère \ !
  $classname = explode('\\', $classname);
  // Remplacement des namespaces dont le répertoire ne concorde pas :
  if($classname[0] == 'MyApp')
    $classname[0] == 'core';
  elseif($classname[0] == 'Db')
    $classname[0] == 'dblayer';
  if($classname[0] == 'Easing')
    $classname[0] == 'libs';
 
  $path = SOURCES_DIR.'/';
  for($i = 0, $j = sizeof($classname)-1; $i < $j; ++$i) 
    $path .= strtolower($classname).'/';
  $path .= 'class.'.array_pop($classname).'.php';
 
  if(file_exists($path))
    require $path;
}
 
spl_autoload_register('myapp_autoload');
if(function_exists('__autoload'))
  spl_autoload_register('__autoload');
spl_autoload_register('spl_autoload');

Ici, on retiendra l’organisation des fichiers suivante : myproject/sources/core/class.Request.php, myproject/sources/view/class.Templates.php, etc. L’utilisation du test sur l’existance du fichier avec file_exists() pourrait être évitée (et faire économiser du temps) si on s’assure qu’il n’est pas nécessaire de définir d’autre méthode de chargement automatique exécutée si celle-ci échoue, ou en inversant l’ordre d’exécution des différentes fonctions pour obtenir la plus efficace possible.

En plus, il est possible que la fonction myapp_autoload() ne soit plus modifiée, car si on souhaite créer un nouveau namespace et de nouvelles classes, on obtient automatiquement une correspondance, par exemple la classe Cookies dans le namespace Tools\Http, dont le nom absolu sera Tools\Http\Cookies sera, par défaut, recherchée dans myproject/sources/tools/http/class.Cookies.php.

Conclusion

La fonctionnalité d’auto-chargement de classes de PHP permet de simplifier la gestion des dépendances de plusieurs manières. Les opérations d’inclusion implicites sont couteuses en temps et en mémoire, il est donc pertinent d’envisager un moyen d’optimiser ce mécanisme. D’une manière générale, on évitera le plus possible les tests sur l’organisation du système de fichier, qui prennent beaucoup de temps. Dans une moindre mesure, on peut préférer éviter de charger un tableau en mémoire et devoir rechercher une valeur dedans à chaque chargement, bien que l’implémentation des tableaux associatifs en PHP offre des performances très satisfaisantes.

Enfin, l’arrivée de nouvelles fonctionnalités avec PHP 5.3, dont les namespaces, peuvent nettement simplifier tout ceci en adoptant une structure intelligente.

C'est parti pour Martius Web version 2 (béta quand même !)

Martin Richard — Sat, 17 Oct 2009 00:41:00 +0200

C’est le grand moment, nous somme le samedi 17 octobre, et j’ai décidé, là comme ça, de lancer Martius Web version 2 en “béta” publique.

Mais c’est quoi ?

Peut-être, cher visiteur, arrives-tu ici pour la première fois, ou alors, tu t’es déjà égaré sur ces pages, mais n’a jamais très bien compris d’où elles viennent et à qui elles sont destinées ! On va faire un petit récapitulatif !

Martius et Web sont deux mots : Martius, c’est moi à l’heure ou j’écris ces lignes, je suis étudiant en ingénierie informatique à Lyon et auto-entrepreneur. Web parce que j’aime beaucoup le développement web et tout ce qui y touche, de près comme de loin : langages, outils, design, et de la communication.

Martius Web est à l’origine un site perso sur lequel je voulais exposer quelques expérimentations que je fais depuis plusieurs années. Entre temps, j’ai eu envie d’écrire un cours sur le XHTML et les CSS. C’est comme ça qu’est né la version du site qui existait encore hier. Entre temps, c’est devenu une usine à gaz que je ne mettais plus très régulièrement à jour : ça commençait à dater…

Je suis revenu au racines et j’ai commencé à travailler sur cette version, qui est avant-tout un endroit où je peux exposer des infos, des découvertes et des expérimentations que j’ai pu réaliser. J’ai ajouté quelques pages qui décrivent (un peu pompeusement) mon activité d’auto-entrepreneur. Et voilà !

C’est au point ?

A vrai dire, oui et non ! C’est une béta : je ne l’appelle pas comme ça parce que c’est un super terme à la mode depuis que Google à relancé cette tendance pour ses services, mais bien parce que tout n’est pas terminé ! Les tutos sont toujours incomplets, parfois mal relus, donc encore plus mal corrigés… J’attendais juste d’avoir au moins autant de contenu pertinent que sur l’ancienne version pour que ça devienne public.

C’est pour quoi ?

J’écris autant que possible sur le site quand je découvre un truc qui me semble pertinent et à partager.

Pensez juste à ça : c’est gratuit, soumis aux commentaires et sous licence creative commons BY-NC-SA, vous pouvez donc les lire, copier et partager à volonté, tant que vous respectez trois de mes défauts :

je suis mégalo et je veux que vous rappeliez que je suis l’auteur,
je suis aussi assez mauvais quand on essaie de se faire de l’argent sans que j’en prenne part, donc tout usage commercial est interdit !
je suis aussi viral, et tout ce que vous prendrez sur ce site devra être incubé et éventuellement transmis en respectant ces termes de licence !

On peut participer ?

Avec plaisir ! Si vous avez envie d’écrire ici, envoyez-moi un mail pour qu’on en discute, sinon, n’hésitez pas à commenter, corriger et mettre à jour ce qui passe ici !

Le mot de la fin

Pour finir ce nouveau début, je serais bref (enfin !) : bonne visite ! J’espère que vous apprécierez !

Martius Web sur JeSuisUnAutoEntrepreneur.com !

Martin Richard — Fri, 15 May 2009 17:13:00 +0200

Depuis quelques jours, vous trouverez sur le site internet Je suis un auto-entrepreneur une interview au sujet de Martius Web et de mon statut d’auto-entrepreneur !

Le site internet recense aujourd’hui une dizaine de portraits d’auto-entrepreneurs exérçant dans des domaines d’activités variés. Si vous hésitez encore, ou que vous êtes à la recherche de retours d’expériences, passez y faire un tour ! Le site propose également quelques informations sur l’actualité du statut.

Je pense que vous pouvez contacter Julien pour avoir plus d’informations, ou vous faire tirer le portrait également !

Jesuisunautoentrepreneur.com est un site qui s’adresse aux auto-entrepreneurs mais également à tous ceux qui s’intéressent à ce statut et plus largement à la création d’entreprise.

Sur ce site, vous pourrez trouver de l’actualité concernant ce statut mais vous aurez surtout la possibilité de voir des portraits d’auto-entrepreneurs bien réels, qui viendront vous expliquer pourquoi ils ont choisi ce statut et ce que cela leur apporte.

Alors, si vous avez envie de créer votre propre activité mais vous ne souhaitez pas pour autant créer une entreprise, ce site est sans doute pour vous !

Ah, et oui, bien sûr, voici le lien direct vers mon profil !

Luxury Flat In Dijon

Martin Richard — Fri, 15 May 2009 11:31:00 +0200

Luxury Flat In Dijon est une agence de location d’appartements au cœur du centre ville. Nous nous somme chargé de l’intégration du design réalisé avec Adobe Illustrator, et du développement d’une solution d’administration, à la fois plus simple à mettre en place et à utiliser qu’un CMS proposant de nombreuses fonctionnalités inutiles.

Par ailleurs, Martius Web a accompagné et conseillé l’agence sur les méthodes d’édition ou de référencement permettant de maintenir le site efficacement.

Visiter le site internet Luxury Flat In Dijon

PHP Solutions : Concevoir une application pour le Web avec Ajax

Martin Richard — Fri, 01 May 2009 19:26:00 +0200

Article paru dans le magazine PHP Solutions (Mai 2008). Attention cet article n’est pas soumis à la licence Creative Commons : tous les droits de cet article sont réservés.

Ajax répond à une demande : c’est l’un des outils principaux permettant de concevoir une application riche apportant une nouvelle expérience à l’utilisateur. Elle est devenue une technologie très à la mode, mais qui reste malheureusement assez mal utilisée. Nous donc allons voir dans quels cas elle est utile, et quelques règles fondamentales de la conception d’application avec Ajax.

Cet article explique :

en quoi consiste une application web et la place d’Ajax dans son architecture
comment concevoir des interfaces riches avec Ajax et le DOM

Ce qu’il faut savoir :

maîtriser la conception d’applications avec PHP
avoir des bonnes bases de XML, XHTML et Javascript

Ajax permet de concevoir des applications Web

C’est assurément à la mode : tout le monde en parle comme la technologie qui révolutionne le web. Concrètement, Ajax permet de mettre à jour le contenu de la page sans la recharger complètement. De ce simple fait, on peut aujourd’hui concevoir des sites qui deviennent particulièrement puissants, proposant de nombreuses fonctions à l’utilisateur directement dans son navigateur. La navigation sur le site s’approche plutôt de la manipulation d’un logiciel, le look en plus. On aime alors parler de RIA, pour Rich Internet Application.

Une RIA est typiquement composée d’une interface cliente gérée par le navigateur, conçue avec Ajax, et d’un support arrière gérant les données sur le serveur, programmée dans un langage de scripts Web plus traditionnel comme PHP.

Ainsi, l’essentiel de l’application étant sur internet, elle devient totalement portable. D’une part, l’utilisateur n’a plus rien à installer, et peut retrouver son environnement de travail, automatiquement mis à jour, sur chaque poste accueillant un navigateur récent sans même avoir à se soucier du système d’exploitation qu’il utilise. D’autre part, l’application bénéficie d’un contenu renouvelé en permanence, grâce aux administrateurs ou à une communauté d’utilisateurs dont les contributions sont centralisées dans une seule base de données.

Au final, Ajax permet de lier les avantages d’internet aux logiciels classiques, et apporte à l’utilisateur un confort que l’on trouvait sur internet grâce à Flash ou Java, qui étaient moins accessibles.

D’un point de vue technique, Ajax est basé sur Javascript, un langage interprété par le navigateur qui permet de modifier son comportement en fonction des actions de l’utilisateur. Des événements sont surveillés par le navigateur qui déclenche alors une série d’actions. Dans le cas d’Ajax, on envoie une requête au serveur, qui retourne du contenu au format XML, c’est ainsi que l’ont peut faire varier le contenu d’une manière sensiblement plus agréable pour l’utilisateur.

Ajax n’est pas un gadget

Il est impératif d’avoir en tête que les avantages d’Ajax sont directement liés à ses inconvénients. Premièrement, la communication entre le client et le serveur s’effectue toujours avec le protocole HTTP, donc de manière ponctuelle. L’organisation de l’application est très dépendante de cette limite : il faut en particulier prévoir comment gérer les données et les objets persistants entre chaque échange client-serveur. Ce problème de conception, comme d’autres, existe bien sûr depuis qu’il existe des applications dynamiques sur internet, mais Ajax apporte un niveau de complexité supplémentaire non négligeable, notamment en terme de sécurité.

D’autre part, Ajax est une jeune technologie, donc au nombreux pré-requis techniques. Il est nécessaire que le visiteur possède un navigateur récent, configuré de manière à ce que le Javascript et les cookies soient activés. Les navigateurs alternatifs, comme les navigateurs mobiles ou les lecteurs d’écrans (navigateurs vocaux ou en braille) sont souvent limités en fonctionnalités et ne supportent généralement pas le Javascript, donc très rarement Ajax. Les appareils mobiles, tout comme les vieux ordinateurs sont généralement peu puissants et ne possèdent pas toujours suffisamment de mémoire pour supporter des manipulations dynamiques lourdes, les pages risquent donc de ne pas pouvoir s’afficher.

L’utilisateur doit aussi avoir une bonne connexion à internet à disposition : illimitée, car les pages modifiées par Ajax ne sont pas consultables hors-ligne, et avec un bon débit car les fichiers Javascript sont souvent lourds. Il faut garder en tête que tout le monde ne dispose pas d’une connexion ADSL dans toute circonstance : certaines personnes n’ont accès à internet que depuis leur lieu de travail par exemple, ou d’autres utilisent des connexions mobiles de type 3G, qui sont facturée à la durée de connexion et au volume des données transférées.

Ces contraintes limitent le nombre de visiteurs potentiels sur le site, et de fait, brident l’accès à l’information que vous souhaitez distribuer. Comme nous l’avons déjà évoqué, l’utilisation d’Ajax doit donc être justifiée, et pourra être un choix judicieux pour une application interne à une entreprise où le parc informatique est maîtrisé ou si vous ciblez un profil d’utilisateur particulier.

Ajax n’a donc pas systématiquement sa place dans l’architecture d’un site internet. Par exemple, le site promotionnel d’une marque ou d’une entreprise n’a généralement besoin que d’une série de pages HTML élégantes et bien conçues. Le site internet d’un journal, même si il est conçue sur une base dynamique côté serveur (pour la mise à jour des articles en temps réel par exemple) doit être composé de pages claires et accessibles, et doit donc limiter les fonctionnalités secondaires, à moins de proposer une alternative minimaliste qui permet quand même l’accès à l’information.

Il ne faut tout de même pas se méprendre : Ajax est loin d’être parfait. L’un des défauts majeurs trop souvent oublié, c’est que le développeur doit, d’une certaine manière, réinventer la roue en programmant manuellement l’ensemble des opérations de transaction par HTTP : requête, traitement des erreurs, réception et traitement du flux de données entrantes, alors que ce est travail normalement effectué en totalité par le navigateur.

Ce n’est pas non plus une technologie normalisée, les navigateurs ne l’implémentent pas tous de la même manière et le développeur perd beaucoup de temps à rendre son code compatible avec la majorité des configurations. Il est possible de palier à ce problème et de lisser l’implémentation d’Ajax grâce à l’un des nombreux frameworks disponibles, sur lesquels nous reviendront. Mais ceux-ci sont généralement très lourd, que ce soit par rapport au poids du fichier ou la mémoire utilisée par le navigateur lors de l’interprétation de ce framework.

Avec X/HTML5, actuellement en cours d’élaboration, on peut espérer que ces principales lacunes disparaissent et que les navigateurs gèrent de mieux en mieux l’implémentation de technologies et outils pour les applications riches.

L’organisation d’une application Web

Classiquement, l’utilisateur entre une adresse dans son navigateur, le navigateur se charge d’émettre la requête HTTP (1.1) complète au serveur qui renvoie le document (généralement HTML ou XML). Le navigateur, en interprétant la page effectue une série d’appels pour chaque fichier (feuilles de styles, images, Javascript) attaché au premier document. Lorsque l’utilisateur émet (formulaire) ou veut obtenir (lien hypertexte) de nouvelles données, le navigateur renvoie une requête, traitée par l’application sur le serveur et la nouvelle page est transmise. L’ensemble du traitement de l’application s’effectue sur le serveur, et la page retournée et en quelque sorte un reflet des données de l’application. L’interactivité est très faible puisque le serveur prend le relais à chaque action de l’utilisateur. C’est ce que les spécialistes aiment aujourd’hui appeler l’architecture “Web 1.0”. C’est un peu snob, mais c’est comme ça !

La différence avec les applications Web 2.0, c’est qu’il est possible d’utiliser une autre manière pour discuter avec le serveur : un objet introduit dans le langage Javascript au centre d’Ajax : XMLHttpRequest.

Comme son nom l’indique, cet objet contient un certain nombre de propriétés et méthodes permettant d’envoyer et recevoir une requête HTTP manuellement. La page n’est plus rechargée dans sa totalité car la requête est traitée au cours de l’exécution des scripts de la page courante. Dans le cas d’Ajax, le résultat de la requête est un document de données au format XML, qui bénéficie d’une compatibilité native avec le navigateur et bénéficie d’une API très pratique pour le manipuler : le DOM.

Nous allons donc étudier de plus près les différents aspects de l’utilisation de l’objet XMLHTTPRequest. Le code présenté est sommaire, et comme nous le verrons plus loin, le développeur ne traite pas directement avec l’objet mais utilise des frameworks apportant quelques facilités.

La requête HTTP

En utilisant la version 1.1 du protocole HTTP, c’est à dire la plus répandue aujourd’hui, une requête se présente sous cette forme :

GET /page.php?foo=yes&bar=no HTTP/1.1
Host: www.domaine.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1.1) Gecko/20060601 Firefox/2.0.0.1 (Ubuntu-edgy)
Accept: text/html, text/xml
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: Gzip, deflate
Accept-Charset: UTF-8, ISO-8859-1
Referer: http://martiusweb.net/index.php
If-Modified-Since: Wed, 27 Apr 2005 17:11:24 GMT
[...]

Il est intéressant de connaître ce format, même si il est assez rarement utilisé par le développeur. En effet, pour analyser votre application ou la débugguer, vous gagnerez beaucoup de temps en regardant directement le contenu des requêtes. Certains outils de débuggage permettent par ailleurs de l’exploiter pour détecter d’éventuels problèmes.

La première ligne contient toujours trois informations. En premier, la méthode de transfert, généralement GET ou POST, avec lesquels vous devriez être familier. Il existe d’autres méthodes (telles que PUT), mais elle ne sont pas (ou peu) supportées par les navigateurs, et donc inexistantes avec Ajax. En deuxième, on trouve l’adresse du document à consulter sur le serveur avec ses éventuels paramètres. Enfin on précise le protocole utilisé et sa version.

Les lignes suivantes concernent les en-têtes. Nous allons présenter les principales, que l’on retrouve presque systématiquement.

Host correspond au domaine hôte du document. Parfois il est absent des éléments d’en-tête car directement intégré dans l’adresse de la requête.
User-Agent permet au client de se présenter. Il indique le système d’exploitation utilisé avec plus ou moins de précision sur l’architecture du système et le navigateur utilisé.
Accept précise les formats de données acceptés. Cet élément est particulièrement important actuellement, car il est un indicateur des différences de compatibilité entre les navigateurs.
Accept-Language indique ensuite les langues préférées par l’utilisateur (selon sa configuration), dans l’ordre de priorité. Cet élément d’en-tête très utile est généralement oublié par les développeurs de sites en plusieurs langues, qui redirigent systématiquement le visiteur vers une page lui demandant de choisir sa localisation, alors que l’information est déjà disponible. Pour le confort de l’utilisateur, on peut commencer par tester l’en-tête, lui proposer de modifier ce choix en le stockant dans un cookie ou enfin, utiliser la langue par défaut du site si les autres tentatives de définition s’avèrent infructueuses.
Accept-Encoding définit si le navigateur supporte une méthode de compression des données. Généralement, le serveur web se charge lui-même de compresser les pages si le client l’accepte.
Accept-Charset indique le type d’encodage des caractères supportés par défaut. Il est peu utilisé, car généralement un site internet n’en propose qu’un seul. L’internationalisation des applications incite généralement les développeurs à utiliser le système unicode (UTF-8), qui couvre la majorité des alphabets. Cependant, un caractère est alors codé sur plusieurs octet, un paragraphe de données sera donc plus volumineux.
Referer indique la page sur laquelle l’utilisateur se situe au moment de la requête, autrement dit, la page qui a conduit l’utilisateur à votre page. Cet élément n’est pas toujours présent, ou parfois vide, mais il est particulièrement utile pour emmètre des statistiques d’audience ou contrôler l’origine de l’utilisateur pour des raisons de sécurité.
If-Modified-Since indique au serveur qu’il est utile de renvoyer le contenu du document à la condition qu’il ai été modifié depuis la date indiquée. Pensez à utiliser cet élément autant que possible, car il peut être très pratique pour préserver la bande passante de transferts inutiles, sans pour autant implémenter des techniques lourdes pour tester.

De nombreux autres éléments peuvent être ajoutés à l’en-tête, je vous invite à consulter les documentations à ce sujet sur internet.

La réponse est composée des en-têtes et du contenu du document lui même. La séparation est marquée par une ligne vide entre les deux parties. Voici un exemple de réponse :

HTTP/1.1 200 OK
Date: Mon, 25 Feb 2007 14:16:00 GMT
Server: Apache/2.0.0 With mod-php5, mod-python
X-Powered-By: PHP/5.1.2
Content-Type: text/html; charset=UTF-8
Cache-Control: max-age=60
[...]
Contenu du document

La réponse est composée des en-têtes et du contenu du document lui même. La séparation est marquée par une ligne vide entre les deux parties.

La première ligne de l’en-tête contient les informations sur le protocole, et le code de réponse. Ici 200 signifie que la requête à parfaitement abouti. D’autres codes d’erreur courants sont par exemple 403, qui signifie que l’utilisateur n’est pas autorisé à consulter le document, 404, qui signifie que le document recherché n’existe pas ou 500 dans le cas d’une erreur interne du serveur, qui cache généralement un problème de configuration du serveur web.

Les lignes suivantes sont d’autres éléments d’en-tête. Les information de date et de durée de validité , tels que Date ou Cache-Control sont particulièrement utiles, encore une fois, pour minimiser le trafic superflu.

D’autres informations concernant le serveur sont délivrées dans la requête, comme Server ou X-Powered-By On préfixe généralement les éléments dont le sens n’est pas défini par le protocole HTTP par X-. Sachez que vous pouvez ajouter, si vous en avez l’utilité, certains éléments d’en-tête propres à votre application.

Sachez également observer l’environnement d’exécution de votre application. Dans le cas d’un serveur web comme Apache, des traces des échanges sont archivés, notamment dans les fichiers log de l’application. Certains outils proposent par ailleurs de les analyser pour vous, comme analog sous Linux.

Plus d’informations sur HTTP et Apache

N’hésitez pas à vous documenter sur les subtilités du protocole HTTP et Apache, ou n’importe quel autre serveur web que vous souhaitez utiliser.

Le flux de données XML

Les données XML sont la réponse à la requête émise par Ajax. Le flux sera donc réceptionné par l’objet XMLHttpRequest avant que l’on puisse l’utiliser. La construction de votre document XML aura une très forte influence sur le reste de votre interface client, une étape de réflexion sur la façon dont vous souhaitez manipuler ces données est donc incontournable.

Dans un premier temps, identifiez clairement les données à transmettre. Regroupez-les en fonction de leur sens et de leurs liens. Un premier tri sera généralement la séparation entre les données métier de votre application et les éventuelles informations correspondant à la manière dont doit évoluer l’interface avec ces informations.

Il faut ensuite modéliser vos données en XML. En suivant la méthode rigoureusement, ça ne devrait pas poser trop de problèmes. Il faut garder en tête que le code lui même doit jouer le rôle de sa propre documentation, il est donc impératif de suivre la logique imposée par XML. A partir de ce moment, le plus gros du travail est fait. Les propriétés d’un élément se présentent logiquement sous forme d’attribut, et son contenu (si il existe) et placé entre la balise ouvrante et la balise fermante. Un attribut ne doit jamais être précisé dans un élément fils, à même titre que le contenu n’a pas sa place dans un attribut. Le code suivant illustre cette problématique avec un exemple un peu grossier.

<magazine>
  <articles>
    <article page="01" auteur="Martin Richard" auteurid="01">
      <titre>Concevoir une application pour le web avec Ajax</titre>
      <chapitre><!-- ... --></chapitre>
    </article>
  </articles>
</magazine>

Voici le même document XML, mieux formé :

<magazine>
   <article page="01" titre="Concevoir une application pour le web avec Ajax">
      <auteur auteurid="01" nom="Martin Richard" />
         <chapitre><!-- ... --></chapitre>
   </article>
   <article page="02" titre="Le modèle MVC">
      <auteur auteurid="02" nom="Pierre Durand">Pierre Durand est ...</auteur>
         <chapitre><!-- ... --></chapitre>
   </article>
</magazine>

La première grosse erreur est située dès la deuxième ligne, car l’élément <articles> n’est pas utile. On peut penser que regrouper les différentes éléments identiques dans une même balise, pour les retrouver plus facilement par exemple, est une bonne idée, mais en manipulant le document plus tard, ce choix risque de surprendre, et coûtera une opération en plus pour accéder un niveau plus bas dans la hiérarchie. Une autre manière aurait été de regrouper les articles dans un élément <dossier> si le magazine est organisé de cette manière.

La deuxième erreur concerne la ligne suivante, et les deux attributs auteur et auteurid L’auteur n’est pas un attribut de l’article, mais un élément à part entière, il est donc plus logique de le considérer comme un élément fils de l’article, contenant deux attributs. Ici, il est même possible d’utiliser la balise <auteur> comme conteneur d’une description, par exemple. On peut envisager une autre manière d’exploiter la même syntaxe : si le document devait être un tri des articles par auteur, notre élément <auteur> aurait été parent de <article>.

Enfin, considérer le titre de l’article comme étant un élément n’est pas vraiment une erreur, mais puisqu’il ne contient pas le moindre attribut, il sera beaucoup plus simple d’y accéder si l’information est elle-même un attribut de l’élément article.

Si votre application à pour but d’être portable, ou que le format de votre document XML doit être échangeable, il devient nécessaire de fixer la grammaire de ce format, pour que tout le monde se comprenne. Pour fixer un format de document XML, il est possible d’utiliser un langage conçu pour par le W3C : le langage de DTD (pour DocType Definition). Cependant, la syntaxe est assez rigide et la prise en main n’est pas évidente. Une alternative normalisée assez courante, et supportée par PHP s’appelle RelaxNG. Ce langage est lui-même issu de XML, et sa syntaxe est plus accessible. Je vous invite à vous renseigner sur ces deux langages pour vous faire une idée de leur utilisation.

Gérer la transaction avec Javascript

Il y a plusieurs manière de traiter la requête HTTP, car les frameworks Ajax disponibles implémentent tous leur propre méthode et leurs propres règles. Nous allons ici nous contenter de voir le traitement d’une requête Ajax avec le code le plus simple possible :

/* On effectue un test qui permet d'utiliser l'objet
 * XMLHttpRequest (que l'on appellera XHR) en fonction
 * du navigateur.
 */
if(window.XMLHttpRequest)
   Ajax = new XMLHttpRequest(); 
else if(window.ActiveXObject)
{
   try {
      Ajax = new ActiveXObject('Msxml2.XMLHTTP');
   } catch (e) {
      // Retour de l'exception, avec Internet Explorer
   }
}
 
/* On définie quelques règles de traitement de la requête
 */
Ajax.onreadystatechange = function()
{
   if(Ajax.readyState == 4)
      traiterResultat();
   else if(Ajax.readyState == 0)
      masquerMessageAjax();
   else
      afficherMessageAjax();
   /* En toute logique, nos fonctions traiterResultat(),
    * afficherMessageAjax() et masquerMessageAjax() seraient
    * plutôt les méthodes d'un objet.
    */
}
 
function traiterResultat()
{
   if(Ajax.status == 200)
   {
      // La requête est parfaitement passée,
      // on peut l'utiliser.
   }
   else
   {
      if(Ajax.status == 403 || Ajax.status == 404 || Ajax.status == 500)
         // on affiche un message d'erreur
   }
Ajax.open('GET','page.php?param='+valParam, false); 
Ajax.send(null);
}

En premier, il faut créer un objet XMLHttpRequest (que l’on appellera XHR), en vérifiant le navigateur utilisé, car Microsoft le considère comme un objet ActiveX.

Avant de lancer la requête, nous allons définir la politique qui permet de suivre son évolution. L’objet XHR met à disposition la propriété XHR.readyState qui prend pour valeur un code numérique correspondant à un état de la requête. Les codes sont 0 quand la requête n’a pas été initialisée, 1 quand elle est en train de charger, 2 quand elle a été reçue, 3 pendant que le navigateur est en train de la traiter et 4 quand elle est terminée, et donc que nous allons pouvoir utiliser son résultat.

Pour surveiller les changements d’état, il existe un événement XHR.onreadystatechange auquel on attache une fonction qui va par exemple afficher un message d’attente tant que la requête n’est pas terminée et déclencher le traitement quand le code état sera 4. Le message d’attente doit être assez clair et amené sans ambiguïté (il ne doit pas être pris pour un message d’erreur par exemple), évitez par ailleurs d’utiliser des termes techniques qui risquent d’embrouiller. Généralement, un message pour les trois états intermédiaires suffisent. De nombreux générateurs d’images d’attentes animées sont disponibles sur internet, ces images sont très pratiques car certains motifs sont très répandus, et les utilisateurs y sont déjà habitués.

La première étape pour traiter le résultat, c’est de vérifier les éventuelles erreurs. La première vérification est le code de réponse de la requête HTTP, représentée par l’attribut Ajax.status. Le code de réussite, nous l’avons vu plus haut est le code 200.

Il peut être dans votre intérêt d’utiliser les codes d’erreur HTTP si ils peuvent correspondre à l’erreur constatée. Par exemple, renvoyez le code 403 si l’utilisateur à fait appel à une fonction qu’il n’avait pas le droit d’utiliser, vous pouvez par ailleurs transmettre un message personnalisé (en XML ou en texte brut) même si vous renvoyez un code d’erreur. Pensez bien sûr à définir une syntaxe pour vos messages d’erreur, même si elle est simpliste.

Une fois que tout est prêt, la requête peut-être crée et envoyée avec les fonction open() et send(). L’exemple présenté utilise la méthode GET pour l’envoi, c’est pourquoi le paramètre passé à la fonction send() est null Enfin, le dernier paramètre de la fonction open() permet de choisir si l’envoi sera synchrone. Ici fixé à la valeur false, il est donc asynchrone. Cela signifie que le script n’attend pas le résultat de la requête pour continuer son exécution.

Pratiques de conception

Il existe des pratiques et des méthodes qui ont été étudiées par certaines entreprises et certains développeurs spécialisés. Généralement, il s’agit d’adapter les méthodes déjà existantes au nouvel outil Ajax. Cependant, ces pratiques sont essentielles pour concevoir une application viable. En voici quelques unes.

Pratiques de conception

Choisissez vos outils

Pour bien travailler, il faut un bon environnement de travail, et donc des bons outils. Dans le cas des applications pour le web, efficace n’est pas toujours lié à coûteux, et de nombreux logiciels gratuits ou libres sont à disposition des développeurs.

Le choix de l’éditeur est essentiel. Si vous avez l’habitude d’utiliser l’éditeur Eclipse pour concevoir vos applications, je vous invite à vous pencher sur Aptana, ce logiciel est également disponible sous forme de plug-in pour votre Eclipse. Aptana intègre de nombreux outils pour les développeurs web et le support de nombreux frameworks. Préférez un éditeur avec lequel vous vous sentez à l’aise et qui soit à la taille de votre projet. Il est inutile de choisir un éditeur trop lourd pour un projet de petite taille, alors qu’un éditeur avec des outils de débbugage avancés et capable d’interagir avec votre serveur web sera particulièrement pratique lorsque votre projet prendra du volume. Quoi qu’il en soit, évitez de changer de logiciel en cours de route, au risque de perdre beaucoup de temps pour vous réadapter.

Le navigateur firefox sera également un outil précieux pendant le processus de développement, notamment grâce à ses nombreuses extensions. La barre d’outil du développeur web vous facilitera en particulier la conception des feuilles de style CSS, et Firebug vous offrira un outil très complet pour faire des tests de vitesse ou manipuler le DOM. L’inspecteur DOM, fourni par les développeurs de Firefox, permet de naviguer dans l’arbre tel que le navigateur l’a interprété. Ces trois extensions sont presque incontournables, mais il en existe bien d’autres.

Enfin, pour programmer dans de bonnes conditions, il est nécessaire d’avoir à portée de main les principales documentations des langages que vous utilisez. Vous avez déjà la documentation PHP (http://fr.php.net/) à portée de main, mais d’autres ressources vous seront utiles, comme sur http://web.developpez.com. Un très bon site regroupe également la liste des balises XHTML 1.1 et les attributs disponibles (http://giminik.developpez.com/xhtml/). Les documents du W3C (www.w3.org) vous seront, quand à eux, utiles pour vérifier des points précis d’une norme.

HTML, XML et l’API Dom

Pour faire évoluer votre page sans la recharger, il est indispensable d’utiliser une API proposée par le W3C appelée DOM (pour Document Object Model pour modèle objet du document). Grâce à DOM, vous avez à disposition d’un bon nombre d’objets et de méthodes vous permettant de modifier le corps d’un document XML. XHTML reposant sur XML, se conformer à cette norme devient également incontournable.

Le DOM organise le document XML en noeuds (node). Un noeud contient un certain nombre d’éléments, les attributs éventuels, un contenu de type texte ou une série d’autres noeuds. Observez bien la manière dont l’arbre est construit par Firefox depuis l’extension Inspecteur DOM, vous remarquerez au passage que les retours à la ligne et les tabulations utilisées pour mettre en forme le code sont considérées comme des éléments texte d’un noeud.

DOM est décliné dans de nombreux langages, dont Javascript et PHP5.

En Javascript, il se manipule à partir de l’objet racine document. On accède aux noeuds fils du noeud courant avec monNoeud.childNodes, par exemple pour accéder à l’élément HTML, il suffit d’utiliser document.childNodes[1], ou encore document.firstNode. D’autres attributs sont disponibles, à savoir monNoeud.lastNode, monNoeud.nextSibling ou monNoeud.previousSibling.

Des méthodes de recherche sont également disponibles, comme monNoeud.getElementsByTagName('div'), qui retourne un tableau contenant chaque noeud de type div.

D’autres méthodes permettent de créer ou modifier certains noeuds, comme createElement() ou createTextNode(). Vous pouvez ensuite les insérer dans le DOM avec appendChild(), insertBefore(), replaceChild() ou même en supprimer un avec removeChild().

Entraînez vous à naviguer dans le DOM, avec de l’habitude, l’accès à n’importe quel élément de la page sera un jeu d’enfant. L’exemple de code suivant donne un aperçu de la manipulation du DOM en Javascript :

/* Pour manipuler le DOM, la page doit être chargée, donc
 * on attend l'évènement onload.
 */
window.onload = function() {
   // On garde en mémoire le premier paragraphe de la page 
   paragraphe = document.getElementsByTagName("p")[0]; 
   // On construit un nouvel élément titre contenant du texte 
   precision = document.createElement("h1").appendChild(document.createTextNode("Titre de page")); 
   // On injecte cet élément juste avant le premier paragraphe 
   paragraphe.parentNode.insertBefore(precision, paragraphe);
}

DOM sera énormément utilisé avec Javascript. Il servira à manipuler les documents XML obtenus par les requêtes Ajax ou implémenter les éléments de l’interface qui la rendent dynamique (boutons supplémentaires, messages de retour, …). DOM sera certainement utile en PHP également. L’implémentation est très semblable à celle de Javascript, certaines méthodes supplémentaires ont été ajoutées, notamment en ce qui concerne la manipulation des fichiers ou la vérification de la conformité d’un document d’après sa DTD. Le listing suivant présente un aperçu de l’implémentation de DOM avec PHP5. L’implémentation varie en PHP4, car les noms de fonctions ont été adaptés à la nomenclature classique de PHP.

$xml = new DOMDocument(); 
// D'après le listing n° 4
$xml->load('listing4.xml'); 
 
// Obtenir les articles 
$articles = $xml->documentElement->getElementsByTagName('article'); 
 
// Titre du premier article 
$titre = $articles->item(0)->getAttribute('titre');

En PHP on charge un fichier avec la fonction load(). Il est possible de charger un flux dans une variables avec la fonction loadXML(). Pour charger du HTML, il existe deux fonctions spécifiques : loadHTML() ou loadHTMLFile(). Pour enregistrer le résultat save() et saveHTMLFile() s’en chargeront, et pour récupérer le résultat dans une variable, il faudra utiliser saveXML() et saveHTML().

Pour valider un flux XML d’après la DTD, utilisez la fonction validate(), la DTD étant précisée dans la première ligne du fichier (si elle existe), PHP se charge de l’obtenir. Si le format du flux a été définit en utilisant RelaxNG, utilisez relaxNGValidate() ou relaxNGValidateSource() si le schéma est stocké dans une variable.

Les fonctions propres à la navigation ou la modification du DOM sont identiques (à quelques exceptions près) entre PHP5 et Javascript.

La manipulation du DOM avec PHP est moins courante. Pour créer un flux XML, l’API SimpleXML sera généralement plus pratique, bien que moins puissante. DOM peut être utile pour modifier dynamiquement un fichier XML enregistré physiquement, ou téléchargé depuis un serveur distant.

Choisir un framework Javascript

Un choix généralement important à notre niveau est le choix d’un framework Javascript. Il en existe plusieurs sur internet, qui ont tous leurs avantages et inconvénients.

Généralement, ces frameworks sont répartis en plug-ins, il est donc possible de sélectionner les fonctionnalités dont vous avez besoin et éliminer celles dont vous n’avez pas l’utilité. Par ailleurs, certains frameworks seront plus portés sur l’amélioration des possibilités du dom, certains implémenteront aussi un certain nombre d’effets visuels améliorant l’interface alors que d’autres se concentreront sur la communication entre le client et le serveur avec Ajax ou certaines alternatives.

Le choix d’un framework dépend de vos besoins, mais à nouveau, ce choix doit être réalisé assez tôt dans la conception, car vous en serez dépendant.

Voici une petite liste de frameworks courants, c’est à vous de choisir en détail celui qui vous semble le plus approprié à vos besoins. La réactivité de la communauté des utilisateurs et la qualité de la documentation doit également être un critère jouant sur votre choix.

Y!UI (Yahoo! User Interface) : http://developer.yahoo.com/yui/ Développé et utilisé par les services de Yahoo!, ce framework est fonctionnel et bien documenté. Il reste cependant limité aux besoins internes de la société. C’est un très bon choix pour se limiter à l’essentiel (ou presque).
Mootools : http://www.mootools.net Ce framework est l’un des plus récents. Son principal avantage est l’amélioration du DOM grâce à des sélecteurs identiques à ceux utilisés en CSS. Il est également réputé pour être assez léger. Cependant, certains outils particulièrement appréciés dans d’autres frameworks sont prévus mais pas encore disponible à ce jour. Il est par ailleurs assez simple d’utilisation, mais la documentation n’est pas très pratique.
Prototype : http://www.prototypejs.org Prototype est l’un des premiers frameworks de ce type apparus. Particulièrement complet et robuste, il intègre des fonctions Ajax et d’amélioration du DOM puissantes. Un second framework nommé Scriptaculous (http://script.aculo.us) basé sur Prototype dispose de nombreux effets très agréables, mais aussi très lourds.
jQuery : http://www.jquery.com C’est un framework très réputés dans les projets open source français, il est notamment utilisé par des applications comme Spip ou DotClear.
D’autres frameworks comme Dojo ou Microsoft Atlas peuvent également être cités.

Une dernière alternative est le GWT (Google Web Toolkit), qui vous permet de programmer la partie cliente de votre application en Java. Le GWT se chargera de le transcrire en Javascript.

Frameworks PHP/Ajax

Généralement, le développement de plusieurs applications web entraîne la programmation de même fonctions plusieurs fois, avec quelques adaptations propres au projet. Cela devient rapidement désagréable car très redondant, et risque d’embrouiller le développeur qui jongle entre plusieurs standards et règles de conception variant d’un projet à l’autre.

C’est pour ces raisons qu’il existe des frameworks complets vous imposent des méthodes de conceptions standardisées. Ces frameworks sont basés sur une architecture stable et des librairies de fonctions ou classes qui lissent l’implémentation des outils classiques comme les bases de données. Leur organisation facilite également le développement à plusieurs grâce à la séparation de l’application en modules indépendants.

En PHP, quelques frameworks sont jugés réellement matures par la communauté. Parmis eux, on trouve le projet français Symfony (http://www.symfony-project.org). Il repose sur les motifs de conception MVC et propose de nombreux outils pour faciliter la conception d’une application ou d’un site internet, comme la virtualisation de la base de données, la simplification de l’internationalisation ou même l’optimisation du référencement, notamment avec l’URL Rewriting. Enfin, Symfony simplifie également l’utilisation d’Ajax.

La répartition client/serveur

Ce sujet à déjà été évoqué ponctuellement plus tôt. La répartition entre le client et le serveur est cruciale pour une application web, la balance doit être équilibrée pour permettre de décharger le serveur de certains traitements, mais l’interface doit rester fluide, d’autant plus que décharger la logique métier vers le client entraîne des risques de sécurité importants.

En local, on s’attarde essentiellement sur l’interface et l’aspect utilisateur. On peut par exemple simplifier la saisie et effectuer une série de tests sur les données entrées par les utilisateurs avant de les transmettre au serveur. Certains calculs peuvent également être traiter en local, pour ne renvoyer au serveur que l’essentiel, cependant, cet aspect est généralement assez limité.

La logique métier est systématiquement sur le serveur, le traitement, la gestion et la redistribution des données se fait invariablement sur le serveur. Par ailleurs, l’envoi d’une requête avec Ajax doit être effectuée sur le serveur hôte de la page courante, pour la sécurité de l’utilisateur.

Cette répartition, comme tout choix de conception, doit être délimitée de manière cohérente. Elle entraîne également de nombreux risques de sécurité. Par exemple, n’oubliez pas que toute donnée transmise doit être contrôlée, car il est toujours facile de détourner le fonctionnement d’un script et de transmettre des informations frauduleuses. Chacune des vérifications effectuées en local doit être reprise sur le serveur. Les failles de sécurité classiques comme les injections SQL risquent d’être plus nombreuses, mais la manière de les éviter est toujours la même : vérifier la cohérence des données et échapper les caractères comme les guillemets utilisés dans les requêtes. Pour finir, les données sensibles doivent toujours être protégées. Par exemple, si certaines données doivent être inaccessibles pour un utilisateur non identifié, les contrôles appliqués lors du chargement d’une page doivent également être effectués avant de transmettre une réponse à une requête Ajax.

Organisation de l’application

A l’image de la partie serveur, la partie cliente de votre application doit également être modélisée et organisée. Il est impératif de veiller à séparer la couche de traitement des données et de communication avec le serveur de la couche graphique, comme la modification du DOM de la page ou les effets visuels.

Le motif de conception MVC peut également être adapté à une architecture cliente conçue avec Ajax. Le contrôleur sera chargé d’analyser les évènements et de déclencher les actions en conséquence, la vue concerne bien sûr l’aspect visuel (la couche “graphique”) et le modèle est chargé de communiquer avec le serveur et de recevoir les données. Le listing qui suit présente un exemple simplifié d’architecture MVC appliquée à Ajax.

/* Nous travaillons avec un formulaire contenant un seul champ
 * dont l'information est envoyée au serveur avec XMLHttpRequest
 */
var myController = {
   start: function() {
      // Définir les évènements par défaut
      document.getElementsByTagName('form')[0].onsubmit = myController.submitForm;
   },
 
   submitForm: function() {
      input = document.getElementsByTagName('input')[0];
      if(input.value == '')
         myView.displayError();
      else {
         myView.disableForm();
         myModel.sendInformation();
      }
   },
 
   endOfQuery: function() {
      myView.stopLoader();
      myView.enableForm();
 
      if(myModel.result != undefined)
         myView.showResult();
   }
};
 
var myView = {
   dislpayError: function() {
      element = document.createElement('p').appendChild(document.createTextNode('Champ incomplet');
      input = document.getElementsByTagName('input')[0];
      input.parentNode.insertBefore(element, input);
   },
 
   disableForm: function() {
      document.getElementsByTagName('input')[0].disabled = true;
      document.getElementsByTagName('input')[0].disabled = true;
   }
   enableForm: function() {
      document.getElementsByTagName('input')[0].disabled = false;
      document.getElementsByTagName('input')[0].disabled = false;
   },
 
   queryLoader: function() {
      // afficher un message d'attente
   },
 
   stopLoader: function() {
      // masquer le message d'attente
   },
 
   showResult: function() {
      // Traitement du resultat et affichage
   }
},
 
var myModel = {
   result: undefined,
 
   sendInformation: function() {
      Ajax = new XMLHttpRequest();
      Ajax.open('GET', 'page.php?text=' + document.getElementsByTagName('input')[0].value);
      Ajax.send(null);
   },
 
   queryState: function() {
      if(Ajax.readyState = 4) {
         if(Ajax.status == 200) {
            myController.endOfQuery();
            this.result = Ajax.responseXML.documentElement;
         else {
            myController.endOfQuery();
            myController.queryError();
         }
      } else
         myView.queryLoader();
   }
};
 
window.onload = myController.start;

L’organisation de vos fichiers prend également beaucoup d’importance car une organisation souple permet de tirer partie des avantages du cache du navigateur. Généralement, choisir un fichier par classe est une bonne solution.

Optimisations

Comme pour toute application, l’optimisation est ici un point important à ne pas négliger. Une application optimisée signifie un meilleur confort pour l’utilisateur et surtout une économie de ressources sur le(s) serveur(s).

Les appels au serveur sont particulièrement coûteux, dans la mesure du possible, c’est toujours avantageux de les économiser et de les regrouper si possible. Les échanges sur le réseau peuvent aussi être optimisés en réduisant le volume des données échangées. Privilégier des index numériques aux chaînes de caractères dès que possible est déjà un bon point. Dans des cas plus extrêmes, il est parfois intéressant de définir un second format pour les flux XML en réduisant au maximum le nom des attributs et en réduisant les espaces blancs dans le codes. Il existe aussi des outils permettant d’optimiser le code Javascript au maximum. Ces solutions ne doivent être mises en place que lors de l’utilisation de l’application en production, car le code devient généralement illisible et impossible à comprendre.

L’optimisation passe aussi évidemment par la gestion des calculs. Il est donc primordial de limiter les manipulations lourdes du DOM très coûteuses pour le navigateur. Une politique de mise en cache doit aussi être définie sur le serveur et avec le navigateur, grâce aux en-têtes HTTP notamment.

Gardez en mémoire qu’à chaque appel au serveur des opérations qui risquent d’être superflues sont effectuées, comme le rechargement de certains objets voire même de requêtes coûteuses à la base de données.

Enfin, les navigateurs actuels ont généralement des soucis de fuites de mémoire, en particulier lors de l’utilisation de l’API DOM. Une fuite de mémoire est la conséquence d’un maintien en mémoire inutile de certaines variables qui ne sont plus référencées. Une extension pour Firefox appelée Leak Monitor (http://addons.mozilla.org/firefox/2490) très pratique permet de les détecter. Généralement ces problèmes sont dus à des écouteurs d’évènements persistants, il suffit alors la plupart du temps de leur affecter une valeur nulle, par exemple en effectuant monElement.onclick = null; au déchargement de la page. Paradoxalement il faudra donc surcharger l’évènement onunload puis éventuellement lui réaffecter une valeur nulle à la fin de son exécution.

Aspect utilisateur : bonnes pratiques

Il est très important pour bien concevoir une interface de passer par une phase sur papier. N’hésitez pas à prendre du temps pour faire des schémas clairs et annotés car généralement la réalisation des interfaces arrive beaucoup plus tardivement lors du développement. Guider l’utilisateur en organisant intelligemment les différents éléments de l’interface est essentiel afin de la rendre claire et facile à manipuler, c’est pour cela que les effets visuels seront choisis avec parcimonie doivent avoir un sens précis pour le visiteur (comme les couleurs d’ailleurs).

Dans le but de faciliter la communication et la compréhension de votre application, il est conseillé de standardiser les messages et les explications : utiliser les mots login et nom d’utilisateur pour désigner la même information est une mauvaise pratique très répandue ! Veillez par ailleurs à être le plus clair et concis que possible.

Le comportement du navigateur

Tout internaute est habitué à utiliser les fonctions de navigation (“précédent”, “suivant” et “actualiser”) ou les marque-pages, or en transformant la page avec Ajax elles perdent leur comportement normal (la page revient à son état d’origine). Il faut donc pallier à ce problème grâce à certains artifices que nous allons détailler.

Prévoyez des paramètres optionnels dans l’URL de la page qui permettront de retrouver l’état intermédiaire de la page. Imaginez une page où le texte varie en fonction d’une liste déroulante, il faudra ajouter un paramètre text contenant l’identifiant du paragraphe que l’utilisateur souhaite retrouver. On affichera alors un lien intitulé “Lien direct vers cette page”, par exemple, qui évoluera à chaque changement de liste déroulante (par exemple page.php?text=2). Dans le code, on testera la présence où non de ce paramètre : si il existe, on modifiera la valeur par défaut de la liste déroulante et le texte affiché, sinon, on laissera la page se charger normalement. Cette solution ne permet cependant pas de tout résoudre, et un choix judicieux entre le rechargement complet de la page ou une requête avec Ajax permet de limiter les dégâts.

Accessibilité

Ajax est les applications riches sont généralement sources de problèmes d’accessibilité. Plusieurs règles sont à adopter pour permettre à un maximum de visiteurs de pouvoir consulter le site conçu.

N’hésitez pas à préciser du contenu invisible destiné aux lecteurs d’écran, par exemple, placez une balise <span class="accessible">Début/Fin de listing de code PHP</span><br /> aux deux extrémités d’un listing de code, ou d’autres éléments habituellement repérables par une modification de la présentation. Il vous suffira de préciser que les éléments "accessible" ne doivent pas être affichés sur une sortie classique depuis les feuilles CSS. Pensez aussi à mettre quelques raccourcis en haut de page, menant directement au menu, à la recherche et au contenu du site : les utilisateurs de navigateurs mobiles apprécieront. Pour finir, lorsque vous utilisez des formulaires dans vos applications, utilisez les balises d’organisation telles que <fieldset>, <legend> ou encore <label>, et les attributs comme accesskey pour proposer des raccourcis claviers à l’utilisateur. Le listing suivant montre un exemple d’utilisation de ces balises.

<form id="login_form" action="page" method="post">
<fieldset>
   <legend>Identification</legend>
   <label for="login">Identifiant</label>
 
   <input type="text" name="login" id="login" maxlength="15" />
</fieldset>
<fieldset>
   <legend>Valider</legend>
   <button type="submit" name="login_go" id="login_go" accesskey="I" />S'identifier <kbd>I</kbd></button>
</fieldset>
</form>

Une pratique essentielle pour permettre l’accessibilité d’une application Ajax est appelée dégradation élégante (ou graceful degradation). Elle consiste à toujours mettre en place une alternative cohérente et facile d’utilisation utilisant le minimum (voire aucune) technologie qui risque de ne pas être exploitable par certains utilisateurs.

Un exemple simple et courant de dégradation élégante est le code utilisé pour afficher une page dans une nouvelle fenêtre (depuis que l’attribut “target” est devenu obsolète en HTML) : <a href="http://www.martiusweb.net/post/mapage.php" onclick="window.open(this.href); return false;">Lien</a>. Ici, Javascript détourne le rôle du navigateur pour traiter lui même l’évènement en ouvrant le lien voulu dans une nouvelle fenêtre, il annule l’action normale de chargement de page grâce à return false;. Si l’utilisateur n’active pas Javascript, la page se charge tout de même normalement.

Cette pratique est au coeur d’une méthode de conception des applications riches proposée par Jeremy Keith (http://domscripting.com/blog/display/41) il y a deux ans : Hijax. Il s’agit de réfléchir à la manière d’appréhender l’implémentation d’Ajax et dans son application. On peut la résumer grossièrement en disant qu’il faut savoir dès les premières réflexions sur l’architecture de l’application qu’Ajax sera utilisé, mais la concevoir et la faire fonctionner sans l’implémenter dans un premier temps. On ajoute alors les fonctions de l’interface dynamique en surcouche. On parle alors plutôt d’amélioration progressive (progressive enhencement).

Conclusion

Vous avez maintenant en main un bon nombre de pistes à approfondir pour concevoir des applications riches puissantes et efficaces. Gardez en tête que l’utilisation d’Ajax doit toujours être justifiée car c’est un niveau de complexité supplémentaire et peut poser des problème à certains utilisateurs. A présent, soyez créatifs et inventifs, une nouvelle approche du web est à votre portée !

Pour en savoir plus :

Je vous conseille également l’excellent livre Développer pour le Web 2.0 (Eric Van der Vlist, Danny Ayers, Erik Bruchez, Joe Fawcett, Alessandro Vernet) aux édition First Interactive - qui traite de nombreuses technologies et méthodes pour concevoir des applications Web 2.0 très puissantes.

Le magazine PHP Solutions

Martin Richard — Thu, 30 Apr 2009 23:14:00 +0200

Retrouvez Martin Richard, créateur de Martius Web tous les deux mois dans le magazine PHP Solutions. Au programme, découvrez des articles sur le langage PHP et ses usages : Ajax, la POO, le référencement, le développement d’applications pour Facebook, ou encore la sécurité sont quelques uns des sujets traités ou à paraître !

Pour découvrir le magazine, vous abonner ou trouver un point de vente, consultez le site internet de PHP Solutions.

PhotoMagnet : aimants personnalisés à commander en ligne

Martin Richard — Thu, 30 Apr 2009 22:20:00 +0200

PhotoMagnet vous propose de créer vos aimants grâce à l’éditeur en ligne et de les commander pour les coller partout !

Entièrement réalisé en PHP, le site internet utilise des technologies telles qu’Ajax. Nous avons réalisé la totalité du site internet, sa charte graphique et son hébergement sur un serveur dédié.

Visiter le site internet de PhotoMagnet

Bienvenue sur la béta de Martius Web version 2 !

Martin Richard — Thu, 30 Apr 2009 21:10:00 +0200

Chère amie, cher ami,

J’ai le grand plaisir de vous accueillir sur cette page, ce qui témoigne de l’intérêt que vous portez à Martius Web, merci beaucoup !

Cette version est actuellement en travaux, vous trouverez des liens morts, des bugs, des fautes d’orthographe est des coquilles. N’hésitez pas à utiliser les commentaires de cette page pour me les signaler !

Je serais ravi d’accueillir toutes vos remarques, sur la forme, le contenu du site, son organisation, alors n’hésitez pas !

Vous pouvez transmettre l’accès à vos contacts, j’espère qu’un maximum de monde se prendra au jeu et participera à la naissance de ce site.

Bonne visite !
Martin

L'URL Rewrinting avec Apache, pour de belles adresses

Martin Richard — Thu, 30 Apr 2009 17:50:00 +0200

Le serveur web Apache propose un module d’URL Rewriting, qui permet de créer des adresses virtuelles afin de masquer les URL complexes des pages web dynamiques.

Le module URL Rewriting n’est pas activé par défaut avec Apache. Dans le cas d’un hébergement mutualisé, c’est le prestataire qui décide de sa disponibilité. Si au contraire, vous êtes maître de votre installation, vous pouvez vous en charger vous même.

Installation du module

La procédure d’installation et d’activation du module est assez semblable selon votre installation (système d’exploitation, paquets de la distribution ou compilation manuelle, …).

Ces modifications s’appliquent dans le fichier de configuration d’apache, généralement httpd.conf, ou apache*.conf (où * peut correspondre à la version installée).

La plupart du temps, il suffit de rendre actives les lignes suivantes, en supprimant le caractère # en début de ligne :

LoadModule rewrite_module modules/mod_rewrite.so
AddModule mod_rewrite.c

Si vous ne les trouvez pas, il est possible que les modules soient localisés dans un autre répertoire que module/ sur votre installation : vérifiez ce point, sinon ajoutez-les, tout simplement !

Si vous avez compilé Apache par vous même, vous aurez peut-être à reprendre cette installation en ajoutant le paramètre --enable-rewrite (ou --enable-rewrite=shared) lors de l’étape de configuration.

Enfin, vous devrez recharger apache, généralement avec l’une de ces commandes : apache2 -k restart, apachectl -k restart, ou encore /etc/init.d/apache restart. Sous windows, il vous suffira d’utiliser les raccourcis graphiques.

Un premier test

Généralement, les règles de modification des URLs sont placées dans un fichier .htaccess (pour une installation standard), qui permet d’ajouter des directives qu’Apache appliquera au répertoire dans lequel se trouve le fichier.

Créez un fichier .htaccess à la racine de votre site internet et placez-y ces quelques lignes :

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule ceci_est_un_test /index.html
</IfModule>

Ces lignes auront normalement pour effet d’afficher la page d’accueil (index.html) si vous essayer d’afficher ceci_est_un_test. Essayons maintenant de comprendre ces quelques lignes…

La condition <IfModule mod_rewrite.c> indique à Apache qu’il doit vérifier que le module est disponible avant de tenter d’appliquer les règles placées entre les deux balises. La directive RewriteEngine On permet d’indiquer que le module Url Rewriting doit être activé pour ce répertoire. Enfin, la directive RewriteRule sert à enregistrer une règle de conversion d’URL. La chaine de caractères avant l’espace indique le format de l’url recherchée, l’autre indique l’adresse réellement sur le serveur.

Ces règles sont définies à l’aide de la syntaxe des expressions régulières.

Les règles

Les expressions régulières permettent de rechercher des chaines de caractères variables.

Caractères spéciaux

Certains caractères des expressions régulières portent un sens particulier :

^ : indique que nous sommes en début de ligne, ou au début de la chaîne de caractères. Cependant, entre crochets, la signification est différente,
$ : indique lui que nous sommes en fin de ligne, ou de chaîne,
. : remplace tout caractère inconnu,
\ : échape un caractère utilisé dans la syntaxe regex. Par exemple, pour utiliser un point, la syntaxe est \..

Ainsi, pour rechercher la chaine index.html, l’expression régulière à utiliser est ^index\.html$, Apache n’appliquera alors pas la règle si l’adresse demandée est quelquechose-index.html ou encore index.html-autrechose.

Les classes de caractères

Les classes de caractères servent à rechercher un des caractères parmi un ensemble, une classe s’écrit entre crochets. Voici quelques exemples de classes :

[éèê] : signifie que l’on cherche le caractère é, ou è ou encore ê,
[a-z] : signifie que l’on cherche n’importe quelle lettre en minuscules,
[a-zA-Z] : signifie que l’on cherche n’importe quelle lettre, il est possible de faire des combinaisons plus plus personnelles, par exemple [a-gA-Gn-zN-Z] signifie que l’on cherche une lettre comprise entre a et g et entre n et z,
[0-9] : signifie donc que l’on cherche un chiffre,
enfin, il est possible de rechercher n’importe quel caractère sauf certains en ajoutant le caractère ^ en début de classe : [^a-zA-Z] signifie que l’on recherche tout caractère n’étant pas une lettre.

Les captures

Vous pouvez avoir besoin de réutiliser certaines informations de l’adresse recherchée pour indiquer l’adresse réelle de votre page, par exemple, pour remplacer glossaire-a.html en glossaire.php?lettre=a. on utilise alors les parenthèses de capture (). Ainsi, chaque extrait de la chaine trouvée entre () pourra être utilisée dans l’adresse de remplacement avec une variable numérotée $n (où n correspond au numéro de la capture).

Par exemple :

RewriteRule ^glossaire-([a-z])\.html$ glossaire.php?lettre=$1

Les quantificateurs

Les quantificateurs permettent d’indiquer la répétition d’un caractère, c’est à dire le nombre de fois où on souhaite les retrouver.

Voici les principaux quantificateurs :

? : 0 ou 1 caractère (c’est à dire que le caractère n’est pas obligatoire),
* : 0 ou plusieurs caractères (le caractère peut ne pas être trouvé ou trouvé un nombre infini de fois à la suite),
+ : 1 ou plusieurs caractères (le caractère doit être trouvé, mais le nombre de fois à la suite n’a pas d’importance),
{n} : le caractère doit être trouvé exactement n fois,
{n,m} : le caractère doit être trouvé entre n et m fois,
{n,} : le caractère doit être trouvé n fois ou plus.

Voici quelques exemples d’utilisation :

index\.html? : on recherche index.htm ou index.html,
.+\.html$ : on recherche n’importe quelle adresse dont l’extension est .html,
glossaire-[a-z]+\.html : cette fois, notre adresse peut être utilisées pour plusieurs lettres (par exemple, glossaire-aa.html).

L’alternative

Le dernier caractère dont nous allons parler est |, il signifie “ou” quand il est utiliser à l’intérieur d’une capture, par exemple (index|home|accueil)\.html permet de rechercher index.html, home.html ou accueil.html.

Les réécritures conditionnelles

La réécriture conditionnelle permet de limiter le cas dans lesquels s’appliquent certaines règles. Vous pouvez utiliser une réécriture conditionnelle pour interdire l’utilisation d’images enregistrées sur votre serveur depuis d’autres pages, ou vérifier d’abord si la page existe rééllement avant d’essayer de transformer l’adresse.

La directive d’Apache à utiliser est RewriteCond, vous devrez généralement effectuer des tests sur les variables d’environnement d’apache, par exemple %{REQUEST_FILENAME} pour tester l’adresse demandée.

Voici comment tester l’existance du fichier avant de rediriger :

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule (.+)\.html$ index.php?page=$1

Voici quelques autres exemples d’utilisation :

Ici, l’adresse IP 127.0.0.1 sera, quelque soit l’adresse tapée (.*) redirigé vers inderdit.html.

RewriteCond %(REMOTE_ADDR) ^127.0.0.1$
RewriteRule .* /interdit.html

On peut rediriger les utilisateurs d’internet explorer vers le site de Mozilla :

RewriteCond %(HTTP_USER_AGENT) MSIE
RewriteRule .* http://www.mozilla.org

Ou encore interdire le hot linking, c’est à dire, l’utilisation d’images hébergées sur votre site depuis un autre :

RewriteCond %(HTTP_HOST) [^(http://www.martiusweb.net)]
RewriteRule (.+)\.(jpg|gif|png)^ /interdit.$1

Les drapeaux

Les drapeaux permettent de modifier partiellement le comportement d’une directive d’Apache. Un drapeau est placé entre crochets à la fin d’une directive. Vous pouvez cumuler les drapeaux en les séparant par des virgules.

Voici la liste des principaux drapeaux :

NC : permet de rendre la règle insensible à la casse (c’est à dire qu’aucune différence ne sera faite entre les minuscules et les majuscules),

L : permet d’indiquer à Apache que la règle appliquée est la dernière. En effet, tant que Apache ne rencontrera pas ce drapeau, il tentera de réécrire à nouveau l’adresse obtenue. Par exemple :

RewriteRule accueil\.html$ accueil.php
RewriteRule accueil\.php$ index.php?page=accueil

En demandant l’adresse accueil.html, celle-ci sera réécrite deux fois. Elle sera en premier transformée en accueil.php, puis en index.php?page=accueil. Pour interdire la deuxième réécriture, vous ajouterez le drapeau [L] à la fin de la première règle :

RewriteRule accueil\.html$ accueil.php [L]
RewriteRule accueil\.php$ index.php?page=accueil

G : Permet d’indiquer que la page n’est définitivement plus disponible (gone), ceci correspond au statut HTTP 410,

F : envoie le statut HTTP 403 indiquant que l’accès à la page est interdit,

R ou R=n : envoie le code statut HTTP n, par exemple, pour indiquer qu’une page à changé d’adresse, vous pouvez écrire une règle comme celle-ci :

RewriteRule article_urlrewriting.html$ /post/Url-Rewriting [R=301,L]

N : Apache reprendra l’analyse de l’adresse depuis le début, en utilisant la dernière adresse transformée obtenue. Attention, l’utilisation de ce drapeau peut causer une boucle infinie (une règle dirigeant Apache vers une autre et vice-versa, pensez alors à utiliser le drapeau L),

C : lorsqu’une règle comportant ce drapeau est vérifiée, apache analysera l’adresse transformée avec la requête suivante, si celle-ci possède également ce drapeau, si la règle n’est pas vérifiée, Apache passera à la première règle suivante ne comportant pas se drapeau.

Adresse de base

Dans certains cas, il peut être nécessaire de préciser à Apache le répertoire de base dans lequel nous travaillons à l’aide de la directive RewriteBase.

Conclusion

L’utilisation des règles de réécriture d’URL permettent d’améliorer le référencement de vos pages par les moteurs de recherche ou encore la mémorisation par le visiteur, qui pourra comprendre plus facilement l’adresse.

Pour en savoir plus sur les expressions régulières, je vous invite à consulter le manuel de PHP qui offre une introduction à la syntaxe des expressions régulière très complète.

Pour en savoir plus sur le module URL Rewriting d’Apache, consultez la page de manuel à ce sujet.

19# Jouer avec les fonds

Martin Richard — Tue, 28 Apr 2009 23:30:00 +0200

Il est possible d’utiliser les propriétés de positionnement et de répétition des fonds pour réaliser des effets graphiques sympathiques et optimisés.

Sur cette page :

19.1# Les propriétés de répétition

Nous l’avons vu dans le chapitre précédent, il existe une propriété appelée background-repeat, qui permet de gérer la manière dont le fond d’un boc sera géré en fonction de sa taille. Rappelons rapidement son fonctionnement :

background-repeat: no-repeat; permet d’interdire l’utilisation du fond comme une mosaïque, si la taille de l’image est inférieure à celle du bloc, elle ne sera donc affichée qu’une fois,
il existe naturellement le comportement inverse, choisi par défaut : background-repeat: repeat;,
background-repeat: repeat-x; indique que le fond sera répété sur un axe horizontal (les abscisses) uniquement,
background-repeat: repeat-y; signifie, à l’inverse, que le fond ne sera répété que sur un axe vertical (les ordonnées).

Cette propriété peut être très intéressante pour réaliser certains effets sur des fonds, quand ceux-ci représentent des motifs ou des dégradés : il est en effet possible de couvrir la totalité d’un bloc grâce à une image de quelques pixels seulement. D’ailleurs, plusieurs sites internet vous proposent de générer automatiquement ces motifs prêts à être utilisés comme mosaïques.

Le site Background patterns est l’un d’eux (il est en anglais, mais très facile à utiliser !). Nous allons utiliser un motif généré depuis ce site internet pour l’exemple :

l’appliquer comme fond est un jeu d’enfant :

<div class="patternized">
  <p>Ceci est un bloc avec un joli motif !</p>
</div>

.patternized
{
  background: url('images/pattern.png');
  color: white; /* on affiche le texte en blanc... pour le rendre lisible ! */
}

Le résultat obtenu sera donc :

Ceci est un bloc avec un joli motif !

L’exemple ici est assez sommaire, mais je vous invite à consulter l’article à ce sujet sur le blog de Smashing Magazine, qui présente de nombreux exemples d’utilisation de motifs vraiment sympathiques.

Il est possible, dans certains cas, d’optimiser Prenons un autre exemple plus local, au hasard… le fond de l’en-tête du site, mais si, celui là :

Pour réaliser le fond bleu-ciel avec un petit dégradé, j’ai simplement découpé l’image en gardant sa hauteur d’origine et en réduisant sa largeur au minimum : ici, une largeur d’un pixel suffit ! L’image utilisée est donc :

L’image est ici élargie à 10 pixels pour rester visible !

Vous connaissez déjà le résultat obtenu, nous allons donc nous intéresser au code :

<div id="head">Martius Web<div>

#head
{
  background-image: url('images/head/bg.png');
  background-repeat: repeat-x;
  width: 100%;
  height: 112px;
}

Rien de très difficile à comprendre, on choisit simplement de forcer la hauteur du bloc à 112 pixels pour que l’image soit intégralement affichée, mais dans un bloc donc le contenu dépasse cette hauteur, il devient inutile de préciser cette propriété. On peut, éventuellement, la remplacer par min-height, bien que celle-ci ne soit pas supportée par Internet Explorer avant la version 7.

L’opération est assez similaire pour répéter un motif sur la hauteur, je vous invite à tester cet effet par vous même pour bien assimiler son fonctionnement !

19.2# Changer de fond sans recharger l’image lors d’un survol

On peut également optimiser l’utilisation des images sur notre site en utilisant les propriétés de positionnement des fonds.

Pour réaliser un bouton dont le fond change lors du passage de la souris on pourrait utiliser les deux images suivantes :

(button_normal.png) et (button_active.png) lors du survol de la souris.

On pourra utiliser les styles css suivants pour réalisé l’effet voulu :

#menu a
{
  background: url('images/button_normal.png');
  display: block;
  width: 100px;
  height: 25px;
  padding-top: 5px;
  text-align: center;
}
#menu a:hover
{
  background: url('images/button_active.png');
  color: #FEFEFE;
}

Vous imaginez le résultat :

test

Vous pouvez me croire sur parole ou regarder la capture d’écran ci-dessous ; lors de l’affichage d’une page web, l’opération la plus longue est souvent le traitement de la requête HTTP par le serveur, c’est à dire l’attente et la réception du contenu de la page. Pour chaque image sur votre page, il faudra compter une requête. Minimiser leur nombre est probablement le meilleur moyen d’optimiser la vitesse d’affichage de votre site internet.

Il devient alors très intéressant d’utiliser une seule image pour le fond du bouton, et c’est d’autant plus vrai qu’il est possible de conserver l’effet interactif souhaité !

Dans notre exemple, les dimensions d’un bouton sont 100px par 30px. nous pouvons utiliser une image de 100px par 60px qui contient les deux fonds :

Nous pourrons reproduire l’effet grâce à cette feuille de styles :

#menu a
{
  background: url('images/button.png');
  display: block;
  width: 100px;
  height: 25px;
  padding-top: 5px;
  text-align: center;
}
#menu a:hover
{
  background: url('images/button.png') -30px 0;
  color: #FEFEFE;
}

Nous utilisons les propriétés de positionnement du fond en CSS, en plaçant l’image 30 pixels au dessus de la zone visible (-30px), occasionnant l’affichage des 30 derniers pixels de l’image comme fond du bouton. Il est également possible de décaler l’image sur un axe horizontal, avec une image représentant une mosaïque d’icônes.

Complément# Modèle des blocs W3C et Quirks mode

Martin Richard — Tue, 28 Apr 2009 23:29:00 +0200

Internet explorer a introduit sa propre méthode pour gérer les dimensions d’un bloc, qui diffère du modèle officiellement soutenu par la norme. Ainsi, dans certaines configurations, il est nécessaire d’adapter votre feuille de style pour la rendre conforme sous Internet Explorer.

Quirks mode, kézako ?

Le quirks mode appelé aujourd’hui en français mode de compatibilité (avec Internet Explorer). Selon différents critères, une page sera affichée en respectant de manière stricte les conventions établies par le W3C, ou selon des méthodes de rendu propres au navigateur. Le Quirks mode correspond à ce dernier mode de rendu.

Le principal point de désaccord entre le mode strict et le Quirks mode concerne le rendu des blocs. Ces divergences datent de l’époque d’Internet Explorer 4 et Netscape 4, autant dire que c’est le Moyen-Âge du web ! Au fil des nouvelles versions, Internet Explorer s’est lentement rapproché des standards. Disons en fait que les développeurs ont essayé d’implémenter plus correctement certains éléments, et en ont oubliés d’autres. Le tir semble être enfin réajusté avec la version 8. Quand à Netscape, le navigateur a disparu au profit de Firefox, généralement bien respectueux des normes. Cependant un dilemme s’est posé aux développeurs : en améliorant le moteur de rendu pour se rendre conforme aux recommandations du W3C, les vieux sites internet risquaient de ne plus s’afficher correctement.

Un compromis fut trouvé : si le concepteur de la page connait bien les standards, alors il fera l’effort d’indiquer qu’il souhaite utiliser le mode strict, sinon, la page est affichée en Quirks mode : à l’ancienne. Ceci s’applique sur tous les navigateurs récents.

Comment choisir le mode d’affichage ?

En fait, il fallait utiliser un élément du langage propre aux recommandations récentes, c’est pourquoi si l’intégrateur utilise un DocType standard, la page est affichée en mode strict. On parle de DocType Switching. Si un nouveau DocType inconnu du navigateur est utilisé, cela signifie probablement que celui-ci est trop récent pour être interprété : le mode strict est alors utilisé.

Par ailleurs, sous internet explorer, l’utilisation d’un prologue XML comme celui-ci :

<?xml version="1.0" encoding="iso-8859-1"?>

Internet Explorer 6 passera directement en mode Quirks, peut importe la DTD utilisée. Ce comportement disparait avec Internet Explorer 7.

Enfin, l’utilisation d’un type mime xml, obligera le navigateur à afficher la page en mode strict, cependant, Internet Explorer 6 ne supporte que le type text/html, et dans les autres cas, la page sera affichée comme un fichier texte (donc le code sera visible).

Almost Strict Mode, Strict… mais pas tout à fait

Les standards considèrent que les images sont des éléments en ligne. Ce comportement entraine une marge inférieure indésirable qui correspond à l’espace occupé en dessous de la ligne par des lettres comme le “p” ou le “g”. Pour supprimer cette marge, la seule solution consiste à considérer l’élément comme un bloc à l’aide de la propriété display: block;.

La situation étant un peu confuse, le Almost Strict Mode correspond au mode strict avec une exception : les image sont des blocs. Ce cas ce présente en utilisant un autre DocType que le X/HTML Strict (ou XHTML 1.1).

Les différences de rendu des blocs

La principale différence entre ces deux modes de rendu concerne donc le rendu des blocs. En effet, en Quirks mode, le navigateur considère que la valeur de les prorpriétés width et height correspondent à la largeur et hauteur du bloc, et donc que l’on inclue la taille des marges dedans, alors que le W3C considère qu’il faut ajouter à la largeur (ou la hauteur), les marges et la bordure.

Pour la feuille de style suivante, l’interprétation sera différente :

.bloc
{
  width: 250px;
  margin: 12px;
  padding: 12px;
  border: 2px #000000 solid;
}

Chez microsoft, la taille de la zone de texte sera 250 - 12*2 - 12*2 - 2*2 = 200px. (il y a une bordure de chaque côté).
Pour le W3C, on trouve que la taille du bloc sera 250+12*2 + 12*2 + 2*2.

D’autres différences existent, vous pouvez en prendre connaissance sur l’un des sites de référence sur le support des standards Quirksmode (en anglais).

Finalement ?

Finalement, avec la disparition programmée d’Internet Explorer 6 et l’arrivée de la version 8, le Quirks Mode n’a pas beaucoup d’importance pour un intégrateur respectueux des standard. Cependant, il est encore un peu trop tôt pour passer ces subtilités sous silence, surtout si vous héritez du code d’un vieux site.

Martius Web

Nouveaux brouillons pour HTML 5 publiés par le W3C

PHP et les sessions : durée de vie, utilisation avancée et quelques subtilités

Gestion des accès concurrents

Sécurité

Durée de vie

Ramasse-miettes

Assurer la durée de vie de la session

Liaison d’autres données à la session

Ouverture de la session

Fermeture de la session

Lecture des données

Écriture des données

Destruction de la session et garbage collector

Attention à l’identifiant de session !

Conclusions

Facebook distribue sous licence open-source un traducteur PHP vers C++

Des compilateurs PHP existent déjà, quelle est donc la valeur ajoutée de HipHop ?

Quelles sont les limites ?

En savoir plus

BeGood Basketball Services

Étudiant et Auto-entrepreneur : interview par La Manu

PHP Solutions : Robots d'indexation et référencement

Développer notre robot

Apprivoiser les robots et les moteurs de recherche sur son site

Identifier et gérer le passage d’un robot

Limites et dangers des techniques de Black Hat

Concevoir son terrain d’accueil

Conclusion

Aidez-nous à faire mieux ! Répondez à notre sondage !

Chargement automatique de classes avancé avec PHP 5

Autoloading simple

Un chargement dynamique natif avec spl_autoload()

Concurrence d’autoloads

Synchroniser le système de fichier et le nom des classes

PHP 5.3 et les namespaces pour simplifier tout ça

Conclusion

C'est parti pour Martius Web version 2 (béta quand même !)

Mais c’est quoi ?

C’est au point ?

C’est pour quoi ?

On peut participer ?

Le mot de la fin

Martius Web sur JeSuisUnAutoEntrepreneur.com !

Luxury Flat In Dijon

PHP Solutions : Concevoir une application pour le Web avec Ajax

Ajax permet de concevoir des applications Web

Ajax n’est pas un gadget

L’organisation d’une application Web

La requête HTTP

Plus d’informations sur HTTP et Apache

Le flux de données XML

Gérer la transaction avec Javascript

Pratiques de conception

Pratiques de conception

Choisissez vos outils

HTML, XML et l’API Dom

Choisir un framework Javascript

Frameworks PHP/Ajax

La répartition client/serveur

Organisation de l’application

Optimisations

Aspect utilisateur : bonnes pratiques

Le comportement du navigateur

Accessibilité

Conclusion

Le magazine PHP Solutions

PhotoMagnet : aimants personnalisés à commander en ligne

Bienvenue sur la béta de Martius Web version 2 !

L'URL Rewrinting avec Apache, pour de belles adresses

Installation du module

Un premier test

Les règles

Caractères spéciaux

Les classes de caractères

Les captures

Les quantificateurs

L’alternative

Les réécritures conditionnelles

Les drapeaux

Un chargement dynamique natif avec `spl_autoload()`