Apprendre pas à pas à créer des pages web dynamique avec PHP
...
Les tests
- consulter le fichier de configuration srm.conf ou httpd.conf d'Apache dans \confs
- pour information, vérifier les lignes de configuration de php
- lancer le serveur Apache
- mettre essai4.php dans
- lancer le serveur PWS
- pour information, vérifier la configuration de PWS à propos de php
- mettre essai4.php dans \php
Un script JSP (Java Server Pages)
Le script heure.jsp
<% //programme Java affichant l'heure %>
<%@ page import="java.util. " %>
<%
// code JAVA pour calculer l'heure
Calendar calendrier=Calendar.getInstance();
int heures=calendrier.get(Calendar.HOUR_OF_DAY); int minutes=calendrier.get(Calendar.MINUTE);
int secondes=calendrier.get(Calendar.SECOND);
// heures, minutes, secondes sont des variables globales
// qui pourront être utilisées dans le code HTML
%>
<% // code HTML %>
Page JSP affichant l'heure
Une page JSP générée dynamiquement
Il est <%=heures%>:<%=minutes%>:<%=secondes%>
A chaque fois que vous rechargez la page, l'heure change
Une fois exécuté par le serveur web, ce script produit la page suivante :
Les tests
mettre le script heure.jsp dans \jakarta-tomcat\webapps\examples\jsp (Tomcat 3.x) ou dans \webapps\examples\jsp§
(Tomcat 4.x)
lancer le serveur Tomcat§
Conclusion
Les exemples précédents ont montré que :
o les tandems Apache/PHP (Windows, Linux) et IIS/PHP (Windows)
o la technologie ASP.NET sur les plate-formes Windows qui associent le serveur IIS à un langage .NET (C#, VB.NET, ...)
o la technologie des servlets Java et pages JSP fonctionnant avec différents serveurs (Tomcat, Apache, IIS) et sur différentes plate-formes (Windows, Linux). C'est cette denière technologie qui sera plus particulièrement développée dans ce document.
Scripts côté navigateur
Une page HTML peut contenir des scripts qui seront exécutés par le navigateur. Les langages de script côté navigateur sont nombreux. En voici quelques-uns :
Vbscript IE
Javascript IE, Netscape
PerlScript IE
Java IE, Netscape Prenons quelques exemples.
Une page Web avec un script Vbscript, côté navigateur
La page vbs1.html
essai : une page web avec un script vb
Une page Web avec un script VB
La page HTML ci-dessus ne contient pas simplement du code HTML mais également un programme destiné à être exécuté par le navigateur qui aura chargé cette page. Le code est le suivant :
Les balises servent à délimiter les scripts dans la page HTML. Ces scripts peuvent être écrits dans différents langages et c'est l'option language de la balise
Une page Web avec un script Javascript
Cliquez sur le bouton
On a là quelque chose d'identique à la page précédente si ce n'est qu'on a remplacé le langage VBScript par le langage Javascript. Celui-ci présente l'avantage d'être accepté par les deux navigateurs IE et Netscape. Son exécution donne les mêmes résultats :
Les tests
- serveur Apache
- script js1 dans
- demander l’url …l avec le navigateur IE ou Netscape
- serveur PWS
- script js1.html dans
- demander … avec le navigateur IE ou Netscape
Les échanges client-serveur
Revenons à notre schéma de départ qui illustrait les acteurs d'une application web :
Machine Serveur
Machine Cliente
Nous nous intéressons ici aux échanges entre la machine cliente et la machine serveur. Ceux-ci se font au travers d'un réseau et il est bon de rappeler la structure générale des échanges entre deux machines distantes.
Le modèle OSI
Le modèle de réseau ouvert appelé OSI (Open Systems Interconnection Reference Model) défini par l'ISO (International Standards Organisation) décrit un réseau idéal où la communication entre machines peut être représentée par un modèle à sept couches :
|-------------------------------------|
7 | Application |
|-------------------------------------|
6 | Présentation |
|-------------------------------------|
5 | Session |
|-------------------------------------|
4 | Transport |
|-------------------------------------|
3 | Réseau |
|-------------------------------------|
2 | Liaison |
|-------------------------------------|
1 | Physique |
|-------------------------------------|
Chaque couche reçoit des services de la couche inférieure et offre les siens à la couche supérieure. Supposons que deux applications situées sur des machines A et B différentes veulent communiquer : elles le font au niveau de la couche Application. Elles n'ont pas besoin de connaître tous les détails du fonctionnement du réseau : chaque application remet l'information qu'elle souhaite transmettre à la couche du dessous : la couche Présentation. L'application n'a donc à connaître que les règles d'interfaçage avec la couche Présentation. Une fois l'information dans la couche Présentation, elle est passée selon d'autres règles à la couche Session et ainsi de suite, jusqu'à ce que l'information arrive sur le support physique et soit transmise physiquement à la machine destination. Là, elle subira le traitement inverse de celui qu'elle a subi sur la machine expéditeur.
A chaque couche, le processus expéditeur chargé d'envoyer l'information, l'envoie à un processus récepteur sur l'autre machine apartenant à la même couche que lui. Il le fait selon certaines règles que l'on appelle le protocole de la couche. On a donc le schéma de communication final suivant :
Machine A Machine B
+-------------------------------------+ +----------------------------+
7 ¦ Application v ¦ ¦ ^ Application ¦
+------------------------Î------------¦ +-----Î----------------------¦
6 ¦ Présentation v ¦ ¦ ^ Présentation ¦
+------------------------Î------------¦ +-----Î----------------------¦
5 ¦ Session v ¦ ¦ ^ Session ¦
+------------------------Î------------¦ +-----Î----------------------¦
4 ¦ Transport v ¦ ¦ ^ Transport ¦
+------------------------Î------------¦ +-----Î----------------------¦
3 ¦ Réseau v ¦ ¦ ^ Réseau ¦
+------------------------Î------------¦ +-----Î----------------------¦
2 ¦ Liaison v ¦ ¦ ^ Liaison ¦
+------------------------Î------------¦ +-----Î----------------------¦
1 ¦ Physique v ¦ ¦ ^ Physique ¦
+------------------------Î------------+ +-----Î----------------------+
¦ ^
+-->------->------>-----+
Le rôle des différentes couches est le suivant :
Physique Assure la transmission de bits sur un support physique. On trouve dans cette couche des équipements terminaux de traitement des données (E.T.T.D.) tels que terminal ou ordinateur, ainsi que des équipements de terminaison de circuits de données (E.T.C.D.) tels que modulateur/démodulateur, multiplexeur, concentrateur. Les points d'intérêt à ce niveau sont :
. le choix du codage de l'information (analogique ou numérique)
. le choix du mode de transmission (synchrone ou asynchrone).
Masque les particularités physiques de la couche Physique. Détecte et corrige les erreurs de transmission.
Réseau Gère le chemin que doivent suivre les informations envoyées sur le réseau. On appelle cela le routage : déterminer la route à suivre par une information pour qu'elle arrive à son destinataire.
Transport Permet la communication entre deux applications alors que les couches précédentes ne permettaient que la communication entre machines. Un service fourni par cette couche peut être le multiplexage : la couche transport pourra utiliser une même connexion réseau (de machine à machine) pour transmettre des informations appartenant à plusieurs applications.
Session On va trouver dans cette couche des services permettant à une application d'ouvrir et de maintenir une session de travail sur une machine distante.
Présentation Elle vise à uniformiser la représentation des données sur les différentes machines. Ainsi des données provenant d'une machine A, vont être "habillées" par la couche Présentation de la machine A, selon un format standard avant d'être envoyées sur le réseau. Parvenues à la couche Présentation de la machine destinatrice B qui les reconnaîtra grâce à leur format standard, elles seront habillées d'une autre façon afin que l'application de la machine B les reconnaisse.
Application A ce niveau, on trouve les applications généralement proches de l'utilisateur telles que la messagerie électronique ou le transfert de fichiers.
Le modèle TCP/IP
Le modèle OSI est un modèle idéal. La suite de protocoles TCP/IP s'en approche sous la forme suivante :
Application ¦ ¦ Application ¦
+----------------+ +---------------------------+
¦ ¦
+----------------+ +---------------------------+
¦ Transport ¦ ¦ Transport ¦
¦ (Udp/Tcp) ¦ ¦ (Udp/tcp) ¦
+----------------+ +---------------------------+
¦ ¦
+----------------+ ou +---------------------------+
¦ Réseau (IP) ¦ segments (TCP) ¦ Réseau (IP) ¦
+----------------+ +---------------------------+
¦ ¦
+----------------+ +----------------------------+
¦Interface réseau¦ ¦ Interface réseau ¦
+-------Ê--------+ +----------------------------+
¦ ¦
+----------------------------------------------+
réseau physique
Les applications web se trouvent dans la couche Application et s'appuient donc sur les protocoles TCP-IP. Les couches Application des machines clientes et serveur s'échangent des messages qui sont confiées aux couches 1 à 4 du modèle pour être acheminées à destination. Pour se comprendre, les couches application des deux machines doivent "parler" un même langage ou protocole. Celui des applications Web s'appelle HTTP (HyperText Transfer Protocol). C'est un protocole de type texte, c.a.d. que les machines échangent des lignes de texte sur le réseau pour se comprendre. Ces échanges sont normalisés, c.a.d. que le client dispose d'un certain nombre de messages pour indiquer exactement ce qu'il veut au serveur et ce dernier dispose également d'un certain nombre de messages pour donner au client sa réponse. Cet échange de messages a la forme suivante :
Entêtes HTTP
ligne vide
Document
Client --> Serveur
Lorsque le client fait sa demande au serveur web, il envoie
Lorsque le serveur fait sa réponse au client, il envoie
Les échanges ont donc la même forme dans les deux sens. Dans les deux cas, il peut y avoir envoi d'un document même s'il est rare qu'un client envoie un document au serveur. Mais le protocole HTTP le prévoit. C'est ce qui permet par exemple aux abonnés d'un fournisseur d'accès de télécharger des documents divers sur leur site personnel hébergé chez ce fournisseur d'accès. Les documents échangés peuvent être quelconques. Prenons un navigateur demandant une page web contenant des images :
...
PrProgrammation PHP
Rappelons ici que PHP est un langage à part entière et que s'il est surtout utilisé dans le cadre du développelent d'applications pour le web, il peut être utilisé dans d'autres contextes. Le document "PHP par l'exemple" disponible à l'URL … angers.fr/~tahe/pub/php/php.pdf donne les bases du langage. On suppose ici que celles-ci sont acquises. Montrons avec un exemple simple la procédure d'exécution d'un programme PHP sous windows. Le code suivant a été sauvegardé sous le nom coucou.php.
L'exécution de ce programme se fait dans une fenêtre Dos de Windows :
dos>"e:\program files\easyphp\php\php.exe" coucou.php X-Powered-By: PHP/4.3.0-dev
Content-type: text/html
coucou
On remarquera que l'interpréteur PHP envoie par défaut :
l'interpréteur PHP est php.exe et se trouve normalement dans le répertoire d'installation du logiciel.§
des entêtes HTTP X-Powered-By et Content-type :§
la ligne vide séparant les entêtes HTTP du reste du document§
le document formé ici du texte écrit par la fonction echo§
Le fichier de configuration de l'interpréteur PHP
Le comportement de l'interpréteur PHP est paramétré par un fichier de configuration appelé php.ini et rangé, sous windows, dans le répertoire de windows lui-même. C'est un fichier de taille conséquente puisque sous windows et pour la version 4.2 de PHP, il fait près de 1000 lignes dont heureusement les trois-quarts sont des commentaires. Examinons quelques-uns des attributs de configuration de PHP :
short_open_tag = On permet d'inclure des instructions entre des balises
A l'exécution, on a les résultats suivants :
E:\data\serge\web\php\poly\intro>"E:\Program Files\EasyPHP\php\php.exe" conf1.php Content-type: text/html
track_errors=1 track_errors=off
La valeur de la variable de configuration track_errors était initialement 1 (~on). On la fait passer à off. On retiendra que si notre application doit s'appuyer sur certaines valeurs des variables de configuration, il est prudent d'initialiser celles-ci dans le programme lui-même.
Contexte d'exécution des exemples
Les exemples de ce polycopié seront exécutés avec la configuration suivante :
PC sous Windows 2000§
serveur Apache 1.3§
PHP 4.3§
La configuration du serveur Apache est faite dans le fichier httpd.conf. Les lignes suivantes indiquent à Apache de charger PHP comme module intégré à Apache et de passer à l'interpréteur PHP tout requête visant un document ayant certains suffixes dont
.php. C'est le suffixe par défaut que nous utiliserons pour nos programmes php.
LoadModule php4_module "E:/Program Files/EasyPHP/php/php4apache.dll" AddModule mod_php4.c
AddType application/x-httpd-php .phtml .pwml .php3 .php4 .php .php2 .inc
Par ailleurs, nous avons défini pour Apache, un alias poly :
Alias "/poly/" "e:/data/serge/web/php/poly/"
<Directory "e:/data/serge/web/php/poly"> Options Indexes FollowSymLinks Includes AllowOverride All
#Order allow,deny Allow from all
Appelons le chemin e:/data/serge/web/php/poly. Si nous voulons demander avec un navigateur le document doc.php au serveur Apache, nous utiliserons l'URL. Le serveur Apache reconnaîtra dans l'URL l'alias poly et associera alors l'URL /poly/doc.php au document \doc.php.
Un premier exemple
Écrivons une première application web/php. Le texte suivant est enregistré dans le fichier heure.php :
Une page php dynamique
Une page PHP générée dynamiquement
A chaque fois que vous rafraîchissez la page, l'heure change.
La partie dynamique de la page a été générée par du code PHP :
Que s'est-il passé exactement ? Le navigateur a demandé l'URL. Le serveur web (dans l'exemple Apache) a reçu cette demande et a détecté, à cause du suffixe .php du document demandé, qu'il devait faire suivre cette demande à l'interpréteur PHP. Celui-ci analyse alors le document heure.php et exécute toutes les portions de code situées entre les balises
Une page php dynamique
Une page PHP générée dynamiquement
A chaque fois que vous rafraîchissez la page, l'heure change.
Le résultat obtenu dans le navigateur est identique :
La seconde version est meilleure que la première car il y a moins de code PHP dans le code HTML. La structure de la page est ainsi plus visible. On peut aller plus loin en mettant le code PHP et le code HTML dans deux fichiers différents. Le code PHP est stocké dans le fichier heure3.php :
Le code HTML est lui stocké dans le fichier heure3-page1.php :
Une page php dynamique
...
La solution de mettre les codes PHP et HTML dans des fichiers différents sera adoptée par la suite. Elle présente divers avantages :
la structure des pages envoyées au client n'est pas noyée dans du code PHP. Ainsi elles peuvent être maintenues par un "web designer" ayant des compétences graphiques mais peu de compétences en PHP.§
le code PHP sert de "frontal" aux requêtes des clients. Il a pour but de calculer les données nécessaires à la page qui sera renvoyée en réponse au client.§
La solution présente cependant un inconvénient : au lieu de nécessiter le chargement d'un seul document, elle nécessite le chargement de plusieurs documents d'où une possible perte de performances.
Récupérer les paramètres envoyés par un client web 2.6.1par un POST
Considérons le formulaire suivant où l'utilisateur doit donner deux informations : un nom et un age.
Lorsque l'utilisateur a rempli les champs Nom et Age, il appuie ensuite sur le bouton Envoyer qui est de type submit. Les valeurs du formulaire sont alors envoyées au serveur. Celui-ci renvoie le formulaire avec de plus un tableau listant les valeurs qu'il a reçues :
...
9.5.2Le traitement type d'une demande d'un client
Le client interagit avec l'application grâce aux liens de la zone 2 de la page type. Ces liens seront du type suivant :
apparticles.php?action=xx&phase=y&PHPSESSID=zzzzzzzzzzzz
action désigne l'action en cours parmi les suivantes :
authentifier authentification du client
selectArticles sélection d'articles (consultation)
updateArticle modification d'un article
deleteArticle suppression d'un article
sql émission d'une requête SQL quelconque (administrateur) phase une action peut se faire en plusieurs étapes - désigne l'étape en cours PHPSESSID jeton de session lorsque celle-ci a démarré - permet au serveur de récupérer des informations stockées dans la session lors des précédents échanges
De même l'attribut action dans les formulaires aura la même forme. Par exemple, dans la page d'accueil il y a un formulaire de login dans la zone 4. La balise HTML de ce formulaire est définie comme suit :
<form name="frmLogin" method="post" action="apparticles.php?action=authentifier&phase=1">
Le traitement de la demande du client est accomplie par le script principal de l'application appelé apparticles.php. Son travail est de construire la réponse au client. Il procèdera toujours de la même façon :
grâce au nom de l'action et à la phase en cours, il déléguera la demande à une fonction spécialisée. Celle-ci traitera la demande et génèrera la page réponse adéquate. Pour chaque demande du client, il peut y avoir plusieurs pages réponse possibles : page1, page2, ..., pagen. Ces pages contiennent des informations qui doivent être calculées par la fonction. Ce sont donc des pages paramétrées. Elles seront générées par des scripts page1.php, page2.php, ..., pagen.php.
par souci d'homogénéité, les parties variables des pages à afficher dans la zone 4 de la page type seront elles-aussi placées dans le dictionnaire $main.
Supposons qu'en réponse à une demande, le serveur doive envoyer la page pagex.php au client. Il procèdera de la façon suivante :
il placera dans le dictionnaire $main les valeurs nécessaires à la page pagex.php
il mettra dans $main['contenu'] qui désigne l'URL de la page à afficher en zone 4 de la page type, l'URL de pagex.php
il demandera l'affichage de le page type avec l'instruction include "main.php";
La page type sera alors affichée avec dans la zone 4 le code du script pagex.php qui sera évalué pour générer le contenu de la zone 4. On se rappellera que celle-ci est une simple cellule d'un tableau. Il ne faut donc pas que le code HTML généré par pagex.php commence par les balises <HTML>, <HEAD>, <BODY>, .... Celles-ci ont déja été émises au début de la page type. Voici par exemple à quoi pourrait ressembler le script login.php qui génère la zone 4 de la page d'accueil :
…
On voit que la page :
est réduite à un formulaire
est paramétrée à la fois par le dictionnaire $main et la feuille de style.
9.5.3Le fichier de configuration
On a toujours intérêt à paramétrer le plus possible les applications afin d'éviter d'aller dans le code simplement parce qu'on a décidé par exemple de changer le chemin d'un script ou d'une image.
L'application principale apparticles.php chargera donc un fichier de configuration config à son démarrage : // chargement du fichier de configuration include "config.";
...
9.5.4La feuille de style associée à la page type
Nous avons vu que la réponse du serveur avait un format unique celui de main.php. On aura pu remarquer que ce script produit une page brute dépourvue d'effets de présentation. C'est une bonne chose pour plusieurs raisons :
le développeur n'a pas à se soucier de la présentation graphique de la page qu'il crée. Il n'a en effet pas nécessairement les compétences pour créer des pages graphiques attractives. Il peut ici se concentrer entièrement sur le code.
la maintenance des scripts est facilitée. Si ceux-ci comportaient des attributs de présentation, ni la structure du code, ni celle de la présentation n'apparaîtraient clairement. L'aspect graphique des feuilles est souvent délégué à un graphiste.
Celui-ci n'aimerait probablement pas à devoir chercher dans un script qu'il ne comprend pas, où sont les attributs de présentation qu'il doit modifier.
