Et si je le veux dynamique mon site ?

Comme tu as pu le remarquer dans l’article incriminé, une des limitations du web statique, c’est que, par définition les pages qui vont s’afficher sur ton site (si tu as bien suivi tous les conseils qui vont bien) doivent être préparées à l’avance, et qu’en plus, elles ne changent pas en fonction du contexte (par exemple, il n’y a pas d’images de Ferrari si c’est un monsieur qui se connecte ou de pub pour Narta si c’est une femme).

C’est bien ennuyeux pour diverses raisons assez facile à comprendre. Prenez Uzine par exemple, vous avez remarqué que quand vous choisissez un article parmi une liste, et bien miracle :
  le texte de l’article s’affiche (avec les images éventuelles)
  le reste de la page ne change pas.

Evidemment, il serait toujours possible de générer une page HTML pour chaque nouvel article, mais vous vous doutez bien que ce n’est pas ce qui se fait de mieux, ne fusse qu’en matière de stockage sur le disque de la machine-serveur. En fait il est plus pratique d’avoir une seule page pour l’affichage de l’article (le fond de page pourrait-on dire), et de mettre dynamiquement le texte de l’article qui va bien. C’est pourquoi dans SPIP, vous avez par exemple un système de squelettes (article, brève, sommaire, plan).

Parlons peu, parlons bien. Le web dynamique consiste simplement à générer tout ou partie de la page HTML qui va s’afficher, selon la demande.

L’idée est la suivante : le client demande quelque chose (un article par exemple) ; le serveur web plutôt que de servir une page déjà faite (une page statique), va créer cette page dans l’instant et la renvoyer au client.

Oui mais ... A partir de quoi va-t-il la créer cette page ? Bonne remarque, petit scarabée ! Il faut donc que sur la machine-serveur, il y ait quelque part des données (si on poursuit l’exemple, il faut que quelque part soit stocké le texte de l’article). Lesquelles données vont servir de base pour créer la page HTML qui va être envoyée.

En général, les dites données sont stockées dans une base de données (ce qui tombe bien, comme l’on en conviendra aisément). Qu’est-ce qu’une base de données ? On ne va pas ici entrer dans les détails (vous pouvez voir CCM). Disons simplement qu’une base de données est un système de classement où sont rangées des données de façon à ce qu’on puisse les retrouver sans trop de difficultés. Par exemple dans le cas de l’article, ce dernier est stocké dans la base de données et est accessible via son numéro d’article.

L’intérêt bien sûr est d’associer un ensemble de données que l’on peut recouper ou regrouper à la demande, suivant les différents champs. Comme pour un agenda, où l’on note le nom, l’adresse, le numéro de téléphone, les mensurations, etc. du correspondant. Grâce au traitement numérique, on peut alors décider d’extraire de la base, par exemple tous ceux dont le nom de famille commence par un W, dans telle ville, etc.

L’image la plus simple pour illustrer la base de données est par exemple l’ensemble des données de l’annuaire téléphonique et sa consultation via l’annuaire en ligne.

Mettons les choses à plat, afin de décrire le processus :

  1. Le client envoie une requete au serveur web
  2. le serveur web, de son côté, plutôt que de simplement renvoyer une page toute faite, va executer un programme.
  3. Ce programme, en fonction des paramêtres que lui passe la requête (le numero de l’article disons), va chercher les données qui vont bien dans la base de données.
  4. Avec ces données, le programme va construire à la volée une page HTML. De la même façon que vous pourriez écrire vous même le code HTML de votre page (avec notepad, disons) et le sauvegarder sur disque, le programme va automatiquement écrire le code HTML et la sauvegarder quelque part sur le disque du serveur.
  5. A la fin, le serveur web renvoie cette page vers le client

Un exemple bien neuneu

Soyons encore plus didactiques, car je sais que vous aimez ça :

Imaginons que vous ayez accès à une copie de la base de données de la Sécurité Sociale. Dans ces conditions, vous pouvez créez sur votre site deux pages :

  La première dans laquelle vous entrez un numero de Secu. Appelons la page1.html.

Nous ne préciserons pas ici comment, mais dans le code HTML de page1.html est indiqué qu’il faut exécuter un programme sur le serveur web. De la même façon, il est indiqué que le numéro contenu de le champ de saisie doit être transmis au programme en question. Disons que ce programme s’appelle prog1.

  La seconde, appelée par la première, qui affiche les différentes données associées à ce numéro (le nom, le prénom du gus, sa pointure, etc ...). Appelons la page2.html.

Le processus est donc le suivant :

  1. La requête provenant du client est transmise au web serveur.
  2. Celui-ci exécute prog1.
  3. prog1 se connecte à la base de données et se sert du numéro de sécu pour retrouver les données associées.
  4. A partir de ces données, prog1 construit page2.html. On verra plus tard comment.
  5. Cette dernière est renvoyée vers le client.

Voilà la base du web dynamique. On voit bien que désormais tout le problème est d’écrire les programmes dont on a besoin, et non plus de savoir simplement coder du HTML.

Mais encore ?

A priori on peut écrire ces fameux programmes avec n’importe quel langage : du C, du Java, du PERL, du PHP, et d’autres.

En fait ce n’est pas la capacité de ces langages à plus ou moins bien faire ce qu’on leur demande qui importe, mais en pratique, quels sont ceux que proposent les hébergeurs. Ces derniers, pour des raisons de coût se rabattent sur des produits libres, et offrent généralement le paquet cadeau suivant :

  Comme langage PHP (et parfois PERL)
  Comme base de données MySQL

Ce qui est bien suffisant pour des applications non-professionnelles (et même pour certaines applications professionnelles d’ailleurs).

Cet article vous explique le PHP, en long, en large et en travers. Je me contenterais donc de rappeler que ce dernier langage consiste en des balises spécifiques intégrés dans du HTML. En résumé, le code du langage est intégré dans le code HTML. Gros intérêt : ceci permet de faire ce que j’expliquais au début :

  On a un fond de page qui ne bouge pas (c’est le HTML)
  S’affichent en plus les parties dynamiques qui sont générées par le PHP lui-même.

Exemple : la page générique correspondant à un article (avec sa mise en page immuable) et le texte lui-même de l’article qui est inséré par le PHP.

Accroche toi !

Bien. Il s’avère au vu de ce que je viens de dire qu’on peut séparer les langages de programmation pour web en deux groupes :

  Les langages classiques (C, Java, PERL,...) qui construisent tout le code HTML.
  Les langages script (PHP, JSP  [1], ASP,...) qui sont en fait un mélange de HTML statique et d’instructions dynamiques.

Prenons un exemple pour mettre les choses au clair. Imaginons que vous vouliez écrire un programme qui affiche simplement :

Vous allez me dire que cet exemple n’a rien de dynamique, puisqu’on ne se connecte pas à une base de données. C’est vrai, mais si je commence à expliquer comment on accède à la base, on n’y arrivera pas petit castor. De plus, cela ne change rien à la valeur de la démonstration.

HTML

Le code HTML associé à cet affichage est :

C’est un code minimal pour une page HTML, qu’on peut enregister dans le fichier lapin.html pour vérification.

  La balise <HTML> indique que la page est de type HTML.
  La balise <HEAD> indique qu’on va écrire là les données propres à l’entête (HEADer en anglais) ; typiquement le titre.
  La balise <TITLE> indique le titre qui va s’afficher tout en haut de votre navigateur
  La balise <BODY> indique qu’on va écrire là les données qui vont s’afficher dans le navigateur (BODY signifie en anglais corps du texte). C’est là qu’on met justement « je suis un lapin », puisque c’est ça qui doit s’afficher.

C

Ecrivons le programme dans le langage C :

On utilise la fonction printf qui écrit la chaine de caractère qu’on lui donne (entre guillements) dans un fichier [2]. On crée donc dynamiquement la page contenant le code HTML nécessaire à l’affichage.

PHP

Ecrivons le en PHP :

Comme on le voit, le code n’est presque que du HTML, avec juste une instruction PHP, le echo qui écrit la chaine de caractère qui doit s’afficher dans un fichier.

En fait, avec un langage de script, le schéma qu’on a vu plus haut pour le fonctionnement du web dynamique est légèrement modifié.

En fait le programme qui est lancé par le serveur web est un programme fourni avec le serveur web qui s’appelle l’interpréteur. Son boulot et de lire et d’exécuter les pages PHP que vous avez écrites. En pratique il fait les choses suivantes :

  Il lit le fichier PHP
  Il écrit les instructions HTML dans le fichier résultats sans y toucher.
  S’il rencontre une instruction PHP, il l’execute. Par exemple s’il rencontre l’instruction echo, il va écrire dans le fichier résultat la chaine de caractère qui est derrière. S’il rencontre une instruction qui lui dit d’aller chercher quelque chose dans la base de données, il va le faire.

Au final, ça ne change pas grand chose : un fichier résultat est généré qui contient ce que le programme que vous avez écrit lui a demandé d’écrire.

Toujours plus

Oui mais comment que on sait quel programme à appeler et comment qu’on lui passe les parametres ?

Pfff ... Tu es fatigant, petit scarabée ...

Bon alors voilà. Imaginons qu’on en revienne à l’exemple de la sécu. Supposons que le programme soit écrit en PHP. On a donc :

  La page1.htm qui contient un champ de saisie (là où vous allez rentrer le numéro de sécu).
  La page2.php3 qui est le programme qui va s’executer pour afficher les résultats (l’extension .php3 indique que la page est écrite en PHP).

page1.htm se trouve donc dans le navigateur du client. Dans le code HTML de cette page, le champ de saise et le bouton sont encadrés par la balise <FORM>,</FORM>. Ce qui signifie que nous avons là affaire à un formulaire. Un formulaire est une zone de la page HTML qui va appeler un programme (page2.php3 dans ce cas).

La syntaxe exacte de cette balise est :

<FORM action="page2.php3" method="GET">

ce qui signifie que le programme à appeler est page2.php3, et que la requête à employer est GET.

De surcroit dans le code HTML, le champ de saisie doit porter un nom (disons secu), et le bouton aussi (disons go) [3].

Ne confondons pas ce que l’utilisateur va entrer dans le champ d’édition (disons 1621364145236) et le nom du champ. Ce que va entrer l’utilisateur s’appelle la valeur.

Vous me suivez ?

Bon ...

Du fait qu’il y a une balise <FORM>, le navigateur ne va pas simplement envoyer la requete suivante en HTTP :

GET page2.php3 HTTP/1.0

mais plutôt :

GET page2.php3?secu=1621364145236&go=Executer HTTP/1.0

On voit qu’après le  ? se trouvent les paramêtres du formulaire qui vont être transmis à page2.php3 pour qu’il puisse faire son boulot.

Ces paramètres sont de la forme
nom du champ = valeur du champ
le tout séparé par des & (pour un bouton, la valeur est identique à son libellé).

Dans ces conditions, il est facile pour page2.php3, à partir des paramêtres, de récupérer les données qui vont bien dans la base de données, et de générer le code HTML qui va être envoyé au final vers le client

Le mot de la fin

Tu me lâches un peu, petit scarabée ?