Traiter l’entrée du web

name1=value1&name2=value2&…&nameN=valueN.

PHP traduit cela en une matrice associative dont le contenu est celui que vous auriez si vous aviez tapé :

array(‘name1’=>’value1’, ‘name2’=>’value2’, … , ‘nameN’=>’valueN’);

La matrice obtenue dépend de la méthode d’entrée que vous utilisez pour le formulaire. Ici, j’ai utilisé la méthode GET ci-après (A2, figure 4) :

<form get action= »WebInput1.php »>

La méthode form GET signifie que les données seront passées dans l’URL. Bien que cela ne soit pas considéré comme une bonne pratique pour traiter des formulaires dans des applications concrètes (la méthode POST est beaucoup plus sûre), il est utile de voir les données quand on apprend la programmation web. À noter aussi que le script d’action désigné pour traiter l’entrée du formulaire est WebInput1.php. C’est précisément le nom du script lui-même ! Autrement dit, quand le bouton submit sera actionné, les données seront passées à ce même script pour traitement. Cela vous semble peut-être étrange, mais ce sera plus clair dans un instant.

Du fait que la méthode GET est utilisée, toute l’entrée (éventuelle) du formulaire est placée dans la matrice associative « superglobale » $_GET[ ]. Je reviendrai sur le sujet du superglobal dans un prochain article, mais pour l’instant, sachez simplement que la matrice $_GET[ ] est l’endroit où vous trouverez toutes les données. Comme le script (figure 4) est nécessaire à la fois pour sortir le formulaire et pour traiter l’entrée éventuelle qui en proviendra, je dois savoir comment le script a été invoqué : simplement en entrant son nom dans l’URL du navigateur, ou en appuyant sur le bouton submit du formulaire. Pour cela, il me suffit de donner un nom au bouton submit (name= »submit »), grâce auquel sa valeur (« Submit Answers ») est passée comme entrée en même temps que toutes les autres données (code HTML en A3, figure 4):

<input type= »submit » name= »submit » value= »Submit Answers »>

Quel est l’intérêt de cela ? Tout simplement que je peux vérifier s’il y a une valeur associée à l’entrée de matrice $_GET[« submit »], et si oui, je sais que le bouton submit a été actionné et que j’ai des données à traiter. Si la variable n’est pas définie, cela doit être simplement une requête pour sortir le formulaire lui-même. Cette pratique est tellement courante dans les scripts PHP, que j’ai cru pendant un certain temps que la variable « submit » avait une signification spéciale en PHP. En réalité, c’est simplement une convention très répandue.

La technique dont j’ai parlé précédemment pour contrôler la sortie du HTML statique est mise en pratique ici. Le test qui conditionne la sortie HTML se trouve en A de la figure 4 :

If (!isset($_GET[« submit »])) {

Si le script n’a pas été invoqué via le bouton submit, ce test sera true (vrai), et le formulaire HTML (qui commence en A1, figure 4) sera sorti. Le point d’exclamation qui se trouve devant la fonction isset() est équivalent au mot-clé NOT de RPG ; cela équivaudrait à coder quelque chose de ce genre en RPG :

IF NOT submitPressed;
// Output HTML

Bien entendu, RPG n’a aucun indicateur tel que submitPressed, mais il n’est pas interdit de rêver et l’essentiel est de faire passer le message.

Si le script est invoqué par enfoncement du bouton submit, il y aura un certain nombre d’entrées dans la matrice $_GET[ ] : le nom de la personne, sa profession et les langages informatiques qu’elle connaît. En conséquence, la section HTML statique sera sautée et le script principal, qui commence avec la clause else  (C, figure 4), sera exécuté.

La première action du script PHP principal est d’utiliser la fonction count() (B, figure 4) pour déterminer combien de langages l’utilisateur a sélectionnés. Count est une fonction de matrice ; donc, pour qu’elle fonctionne, j’ai dû m’assurer que les langages sélectionnés formaient une matrice. J’obtiens cela par une simple convention de nommage dans le formulaire d’entrée. Regardez le code HTML en B1, figure 4. Le nom de l’entrée a été spécifié comme languages[ ]. Notez la présence des crochets dans le nom.  Cela indique à PHP que toutes les valeurs d’entrée de ce nom doivent être traitées comme une matrice. Donc, si l’utilisateur sélectionne trois langages, il y aura trois éléments de matrice.

Dès lors que je connais le nombre de langages, je peux émettre le message initial (D, figure 4). Notez en particulier que comme je n’avais pas à traiter plus avant le nom ou la profession, je peux les référencer directement pour la sortie à partir de la matrice $_GET en tant que $_GET[« name »] et $_GET[« jobTitle »].

Pour simplifier le codage ultérieur, en E de la figure 4, je copie la matrice des langages de la matrice $_GET dans la variable de matrice $languageList. J’applique ensuite notre vieille connaissance foreach( ) pour traiter tous les éléments de la matrice un par un (F en figure 4). Mais je n’ai pas pu m’empêcher d’agrémenter un peu le processus foreach( ). En avançant dans la boucle, le script regarde si l’élément courant est « Other, » et si oui, plutôt que de sortir le nom du langage, il sort le texte « – And other language(s) ».

Ce n’est pas plus compliqué que cela.

Traiter l’entrée du web, Quelques réflexions de plus

Comme vous le voyez, PHP permet d’obtenir facilement des données d’entrée web et aussi d’avoir des éléments répétitifs, comme des sélections de langages, traités « automagiquement » comme une matrice. Vous pouvez d’ailleurs pousser cette notion de matrice beaucoup plus loin que je le fais ici. Par exemple, supposons un formulaire comportant des champs d’entrée pour l’adresse d’une personne. Il pourrait être pratique de traiter tous les champs comme faisant partie d’une matrice d’adresse. Pour qu’il en soit ainsi en PHP, il me suffit d’utiliser des noms appropriés dans le formulaire. Par exemple, je pourrais choisir le nom Address[Street] pour le champ Street name, et Address[City] pour le City name. La soumission d’un tel formulaire aurait le résultat suivant : le contenu des champs Address[xxx] serait placé dans des éléments de matrice associatifs où la clé serait le nom utilisé dans les délimiteurs du subscript de matrice [ ]. Autrement dit, en supposant que la méthode GET soit utilisée, $_GET[Address] contiendrait une matrice associative avec deux éléments : l’un avec la clé « Street » et un autre avec la clé « City. » De la même manière, de telles conventions de nommage pourraient servir à grouper des cases à cocher comme des matrices, ou des boutons radio, ou …

J’ai dit plus haut que $_GET n’était que l’un des « superglobaux » en PHP. Ce sont des variables qui sont toujours disponibles en un point quelconque d’un script PHP. Il y a trois autres superglobaux associés à l’entrée basique sur navigateur :

• $_POST, qui contient toutes les données soumises dans une requête de formulaire qui utilisait la méthode POST ;
• $_COOKIE, qui contient toutes les variables passées au script via des cookies. Je couvrirai le sujet des cookies dans un prochain article de cette série ;
• et $_REQUEST, qui contient toutes les données d’entrée provenant de toutes les sources (autrement dit, c’est la combinaison des données $_GET et $_POST et $_COOKIE).

Vous pourriez être tenté d’utiliser $_REQUEST parce qu’ainsi peu importerait la manière dont les données vous sont parvenues. Mais c’est dangereux dans un code de production, précisément pour cette raison. Vous n’avez aucun moyen de savoir si les données proviennent d’un formulaire dans le cadre d’une requête POST, ou si quelqu’un qui connaît (ou devine) les noms de certains champs de l’application a essayé de leurrer les scripts en passant des données pour ces champs dans l’URL (c’est-à-dire dans les données GET). Avec $_REQUEST, vous ne pouvez pas le savoir. C’est pourquoi $_REQUEST ne doit être utilisé que pour des tests ou pour des exercices d’entraînement.