25 juin 2007

Quelques idées sur l'architecture d'un site web dynamique

PHP est un langage de script qui, pour une raison inconnue, m'interesse - bien que je ne sois pas ce qu'on pourrait appeler un expert PHP. Alors dans le cadre d'une étude sur la réalisation d'un site web (je ne vous cache pas qu'il s'agit de tranformer le site que vous visitez actuellement), je me suis laissé aller à faire quelques petites reflexions sur un ensemble de petites choses concernant l'architecture des sites web dynamiques.

De l'URL à la page servie

Faut-il construire le site web en s'articulant sur un fichier PHP par page affichée, ou faut-il au contraire regrouper l'ensemble des fonctionnalités dans un fichier PHP unique ? La première solution est probablement plus simple, et peut être tout aussi puissante que la seconde solution, mais elle n'est guère élégante selon moi et pose des problèmes de duplication de code. La seconde solution est plus complexe à implémenter (tous les points d'entrées sont réunis dans une seule page PHP), mais limite la duplication du code. En fait, les deux solutions se valent. DotClear, que j'utilise encore pour ce blog, utilise la seconde solution (mis à part pour la génération des flux RSS et ATOM). GameDev.Net est basé sur la première solution - il y a une page ASP par fonction.

Quelle que soit la solution utilisée, il est nécessaire de garder une apparence cohérente entre les pages. Pour ce faire, on peut soit dupliquer le code HTML de mise en forme (sachant qu'il est préférable de laisser la mise en page à une feuille de style; il s'agit donc véritable de mise en forme: titre, sous-titres, etc), soit déléguer ceci à un template.

Et la encore deux solutions très différentes s'offrent à nous.

La première solution (utilisée par Spip consiste à utiliser un fichier texte contenant des marqueurs qui seront remplacés par le code dynamique pour générer la page. Une exemple valant mieux qu'un long discours:

<html>
  <body>
    <h1>{{TITRE_POST}}</h1>
    <p>{{CONTENU_POST}}</p>
  </body>
</html>

Dans ce cas, les identifiants entre {{ et }} sont remplacés au moment de la génération par le titre et le contenu de la page. Il faut donc parser le fichier template pour y découvrir les marqueurs, remplacer ces marqueurs par leur contenu, et envoyer le tout au serveur HTTP. Le problème se corse lorsqu'on veut ajouter des boucles dans les templates - par exemple, pour afficher les 15 dernières news concernant votre site web. Dans ce cas, le méta-langage de marquage devient plus complexe, de même que le parseur. For heureusement, il existe des librairies disponibles sur le web pour vous faciliter la tâche.

La seconde solution (utilisée par DotClear) consiste à inclure le code HTML dans le fichier PHP qui va générer la page. Le problème principal de cette technique est qu'il faut connaître le contexte exacte dans lequel on travaille - si on utilise un fichier PHP par page, c'est extrêmement aisé. Si on utiliser un seul fichier PHP pour tout le site, il faut avoir une notion de mode de fonctionnement stocké quelque part. Une fois ce problème de contexte réglé, le code mélange PHP et HTML pour générer la page qui sera envoyée au serveur.

Voici par exemple une page template.php similaire à la page précédente, si ce n'est qu'elle gère deux mode différents: un mode ou on affiche 15 posts, et un autre ou on affiche seulement le dernier post (et dans ce cas, on est dans le cas identique au cas précédent).

<html>
  <body>
<?php
  $mode = find_current_mode();
if ($mode == "list_post") { $posts = get_last_post_list(15); foreach($posts as $id=>$post) { echo("<h1>".$post->print_title()."</h1>\n"); echo("<p>".$post->print_content()."</p>\n"); echo("<hr />\n"); } } else { $post = get_last_post(); echo("<h1>".$post->print_title()."</h1>\n"); echo("<p>".$post->print_content()."</p>\n"); } ?> </body> </html>

L'un de ces deux méthodes offre-t-elle un meilleur contrôle que l'autre ? Je n'en ai pas la moindre idée. La notion de template texte semble plus simple à mettre en oeuvre et plus facile à maintenir, une fois qu'une librairie de gestion a été déterminée - mais d'un autre coté elle est moins flexible que la méthode PHP pure, et une modification mineure dans les besoins peut provoquer un changement important dans la librairie.

De la génération d'autres types de fichiers

L'un des intérêt de PHP (ou d'autres technologie de génération de pages server side, tels que ASP ou ColdFusion) est qu'il se moque royalement des données qui seront retournées par le serveur HTTP - son seul et unique but étant de générer des données, point final. De fait, ces technologies sont particulièrement adaptées à la génération de flux XML. Prenons le cas par exemple de ce fichier:

<?php
  // file: xml-addition.php
  $result = "invalid result";
  if (array_key_exists('operand1', $_GET) && 
     array_key_exists('operand2', $_GET)) 
  {
    $op1 = (int)($_GET['operand1']);
    $op2 = (int)($_GET['operand2']);
    $result = $op1 + $op2;
  }
  header("content-type: text/xml");
  echo "<?xml version=\"1.0\"?>";
?>
<add>
<?php echo '  '.$result."\n"; ?>
</add>

Et voilà, nous avons un fichier PHP générant un contenu au format XML qui, lorsqu'il est interprété par le serveur va effectuer l'addition des opérandes 1 et 2 (notez qu'il m'a fallut modifier le header pour envoyez le type MIME correspondant au XML (text/xml) et que j'ai du écrire la déclaration XML en utilisant PHP - à cause du format de celle-ci). L'utilisation du fichier est aussi simple que l'utilisation de n'importe quel autre fichier PHP - une requête HTTP vers monsite.com/xml-addition.php?operand1=10&operand2=20 suffit pour recevoir le résultat.

Il est aussi tout à fait possible de générer des images - qu'elles soit du type BITMAP ou vectorielles, comme les images au format SVG[1] - ou tout autre type de fichiers.

Les fichiers XML ont toutefois un avantage certain - ils sont, avec JavaScript et les requêtes XML asynchrones, la base de la technologie Ajax sur laquelle s'est formée ce qu'on appelle communément le Web 2.0 (qui n'est autre que le web que voulait réaliser son inventeur - donc je vais continuer à l'appeler Web si ça ne gène personne).

Notes

[1] Scalable Vector Graphics

Commentaires

1. Le jeudi, mai 22 2008, 19:13 par Florian Lavoux

hello ! "ou d'autres technologie de generation de pages server side , tels que asp ou coldfusion" : certaines parenthèses een disent + que tout le reste ) merci pour ton billet !toujours un plaisir de te lire.

2. Le vendredi, mai 23 2008, 12:09 par Emmanuel Deloget

"Florian" (si tel est véritablement ton nom). J'apprécie bien évidemment l'intérêt que tu portes à mon site (après tout , un PR4, c'est intéressant). Ca ne justifie probablement pas le spam - soyons sérieux: ce que tu as écrit veut tout dire et rien dire. L'intérêt de ton commentaire, c'est le lien associé à ton nom (lien que j'ai supprimé, histoire de voir si tu vas apprécier). Je présume même que le texte est automatiquement généré.Bien. A l'avenir, si tu recommences, je prendrais les sanctions qui s'imposent.

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet