Le Journal de Nikrou - PHP

Envoyer des mails avec php

Nicolas — Sun, 16 Sep 2007 21:35:53 +0000

Quoi de plus simple que d'envoyer des mails avec php avec la fonction mail ! Les choses se compliquent légèrement si on n'a pas de serveur de mail ! Et c'est peu de le dire. Evidemment on peut se lancer dans l'installation d'un serveur de mail (sendmail ou postfix par exemple) mais ce n'est pas à la portée de monsieur tout le monde si on ne veut pas servir de relais de spam! Une solution simple: nullmailer

Hier en voulant tester le module d'envoi de mail de mon application utilisant symfony, je me suis apperçu que je ne pouvais pas envoyer de mail pour tester ! Ne voulant pas installer un serveur de mail j'ai installé nullmailer:

Après un apt-get install nullmailer, les trois-quarts du boulot étaient faits. L'installeur pose deux questions:

Nom de courrier de votre système ?
Machines relais ?

A la première question, j'ai répondu free.fr et à la deuxième j'ai répondu smtp.free.fr smtp.

Le serveur de mail (qui n'en est en fait pas un ^[1]!) se lance et après ça marche!!!

Il ne reste plus qu'à modifier la configuration de php pour qu'il utilise nullmailer au lieu de chercher en vain sendmail ! J'ai juste modifier le sendmail_path: sendmail_path = /usr/bin/nullmailer-inject -fmoi@free.fr

La modification de la configuration de php ne me plait qu'à moitié et je pense que je vais écrire un wrapper pour ne pas avoir à la modifier.

Notes

[1] Et oui contrairement à ce qu'on pourrait croire nullmailer n'est pas un serveur de mail. Ce n'est qu'un MTA. Il ne fait que transférer les messages à un autre MTA ou à un MDA qui se charge de l'envoyer à destination.

Mettre fin à une authentification http

Nicolas — Mon, 02 Oct 2006 10:06:43 +0000

Le but du jeu est de mettre fin à une authentificaiton http faite avec le mécanisme des fichiers .htaccess

Tout le monde connait l'authentification http fournie par apache que l'on met en place aisément avec un fichier .htaccess. Vous trouverz tous les détails sur la doc d'apache. Ce type de protection a l'avantage d'être standard mais aussi de protéger tout le contenu d'un répertoire, contrairement aux sessions php.

Mais la question que l'on se pose est comment mettre fin à cette "session" ? Une solution pour le moins bancale est de proposer au visiteur de fermer son navigateur. On oublie tout de suite. Les visiteurs utilisant firefox et l'extension web developer peuvent le faire aussi aisément sans fermer leur navigateur en cliquant sur:

Miscellaneous > Clear Private Data > Clear HTTP Authentification.

Cette solution n'est pas non plus une solution satisfaisante. Tout le monde n'utilise malheureusement pas encore firefox!

Il n'y a alors pas de solution comme nombreux le prétendent (ils se reconnaitront et ne resteront peut-être pas dans leur ignorance!), allant jusqu'à me modérer parce que j'avais l'affront de prétendre que c'était possible. C'est dur de reconnaitre que l'on a tort et c'est plus facile de ramener la cavalerie pour essayer d'enfoncer la personne qui met un coup de pied dans la fourmillière.

Revenons à nos moutons. Imaginons que nous voulions protéger un répertoire de données confidentielles. En supposant que la configuration d'apache nous y autorise - c'est-à-dire qu'il n'y ait aucun AllowOverride None, il suffit de placer dans le répertoire un fichier .htaccess contenant:

AuthType Basic
AuthName "Private Access By Invitation Only"
AuthUserFile /absolute/path/to/pass.db
Require valid-user

Ce type de protection n'est pas conseillé. On ne met pas le fichier de mot de passe dans le répertoire à protéger; c'ets juste pour la démonstration!

Il faut ensuite créer un fichier de mot de passe avec l'utilitaire htpasswd. J'y ai placé l'identifiant nico avec comme mot de passe nico. On va placer dans ce répertoire un fichier test.php nous donnant le couple identifiant/mot de passe que l'on a entré. Ce couple est accessible à travers le tableau $_SERVER au moyen des clés PHP_AUTH_USER et PHP_AUTH_PW. Je vais aussi créer un script logout.php qui va permettre de mettre fin à cette authentification http. Cette déconnexion se fait en envoyant au navigateur un code http 401 (authentificaiton requise), le même code qu'apache envoie au navigateur à la première tentative d'accès au répertoire. Le code ressemble à ceci:


<?php 
header('WWW-Authenticate: Basic realm="Private Access By Invitation Only"');
header('HTTP/1.0 401 Unauthorized'); 
echo 'Texte affiche en cas d\'annulation'; 
exit();
?>

Vous pouvez maintenant aller voir mes données confidentielles (login: nico mot de passe: nico). Déconnectez-vous, désormais vous ne pouvez plus voir les données confidentielles. Vous pouvez cliquer sur annuler si ça vous chante mais vous serez tout de même déconnecter! N'essayer pas directement d'accéder au répertoire car vous auriez un accès non autorisé car par défaut ma configuration n'autorise pas de lister les répertoires (Options -Indexes)

Notez bien que le realm doit être le même que celui déclaré dans le .htaccess!

Qu'est-ce qu'un singleton ?

Nicolas — Sun, 28 May 2006 14:28:39 +0000

Le singleton est un modèle de conception (design pattern pour les grands bretons). En clair c'est une façon éprouvée de résoudre un problème. Avec le sinleton on cherche à n'avoir qu'une seule instance d'un même objet.

L'implémentation de l'objet singleton consiste à créer une instance de l'objet uniquement si elle n'existe pas encore. On stocke l'instance unique dans une propriété statique de l'objet. Cela peut donner quelque chose comme cela:


<?php
class Singleton {
  private static $instance = null;
  
  private function __construct() {
  }

  public static function getInstance() {
    if (self::$instance==null) {
      self::$instance = new Singleton();
    }
    return self::$instance;
  }
}
?>

La théorie c'est bien joli mais j'entends déjà les questions fuser: à quoi ça sert et comment on s'en sert ? Pour répondre à la première question, je dirais qu'à chaque fois que l'on a besoin d'un objet qui doit rester unique, on utilise un singleton. Je pense par exemple à une classe de log ou une classe de debbugage.

Pour la deuxième question, voici la façon de récupérer l'instance unique:


<?php
$instance1 = Singleton::getInstance();
echo '<pre>Instance n°1:', var_dump($instance1), '</pre>';

$instance2 = Singleton::getInstance();
echo '<pre>Instance n°2:', var_dump($instance2), '</pre>';
?>

En exécutant ce code, on obtient:

Instance n°1:object(Singleton)#1 (0) {
}

Instance n°2:object(Singleton)#1 (0) {
}

#1 est une référence vers l'instance. Dans les deux cas on a la même, ce qui est le but recherché. Au prochain épisode je vous donne un exemple concret!

Faut-il utiliser $_REQUEST ?

Nicolas — Fri, 26 May 2006 11:14:49 +0000

Depuis que je suis tout petit, j'utilise $_GET pour les données provenant de l'url et $_POST pour celles provenant de mes formulaires (utilisant la méthode "post"!).

En lisant divers articles, je me demande si je ne prends pas un peu la tête et si je ne devrais pas utiliser $_REQUEST quelle que soit la provenance des données. Peu importe la provenance, de toute façon il faut filtrer, vérifier, contrôler la cohérence de ces données.

Pour commencer par le commencement, $_REQUEST est un tableau associatif constitué du contenu des variables $_GET, $_POST, $_COOKIE.

Nombreux sont ceux qui se disent au premier abord que cela est vraiment important de pouvoir distinguer la provenance des informations. Si l'utlisateur envoie les données par l'url (méthode "get") ou via un formulaire utilisant la méthode "post" qu'est-ce qui est le plus important ? La façon de recevoir les données ou les données elles-même ? Pour ma part je pense que la façon de recevoir les données n'a aucune importance. L'important est de bien contrôler ce que l'on reçoit et de ne faire confiance à aucune donnée même celles qui pourraient sembler anodines et non modifiables telle que $_SERVER['PHP_SELF'] ^[1]. Du coup l'utilisation de $_REQUEST serait plutôt déconseillée aux débutants qui ont déjà du mal à bien faire la différence entre $_GET et $_POST. Ceux-ci se contentent généralement de peu de vérifications sur les données transmises via la méthode "post"; ces données leur semblent sûres. Je ne parle même pas des cookies!

On pourrait se dire que l'utilisation de $_REQUEST pourrait être intéressante pour les cas où on laisse le choix aux utilisateurs de transmettre les données en utilisant la méthode "get" ou la méthode "post". La gestion de la provenance des données serait ainsi transparente.

Je vois un réel intéret d'utiliser $_REQUEST pour le cas où je veux continuer une session valide sans dépendre de la configuration du serveur, c'est-à-dire sans se demander de quelle manière transite l'identifiant de session (soit par cookie, soit par l'url soit par un champ caché d'un formulaire) alors au lieu d'utiliser une cascade de if pour savoir d'où vient l'identifiant je peux utiliser un code tel que:


<?php
if (isset($_REQUEST[session_name()])) {
  session_start();
}
?>

Pour conclure je ne suis pas complétement convaincu d'utiliser ce tableau magique qu'est $_REQUEST surtout si on se réfère à l'utilisation des méthodes "get" et "post" et sur une architecture REST d'une application web. Les méthodes "get" et "post" sont bien distinctes et donc récupérer les données sans en connaitre la provenance leurs fait perdre un peu de leur sens.

[1] Je m'égare; ce sera l'objet d'un prochain billet. Oui j'ai honte de faire du teasing!

Ne pas réinventer la roue.

Nicolas — Sat, 06 May 2006 22:48:00 +0000

On répète souvent que lorsqu'on fait un script il ne faut pas réinventer la roue et utiliser au maximum les fonctions natives du langage. Cela a de multiples avantages: c'est optimisé, sans bug,... Mais on n'imagine pas toujours lorsqu'on est débutant à quel point cet adage doit être pris au sérieux!

Prenons un exemple concret pour éclairer le débat. Imaginons deux tables sql liées entre elles par un identifiant numérique:

table1: id, champ1, champ2
table2: cid, champ3

Si on n'utilise mysql comme base de données on va utiliser en général un entier auto-incrémenté comme clé primaire de la première table et on va se servir de cet indentifiant comme clé étrangère dans l'autre table. On fait l'insertion d'un enregistrement dans la première table:

insert into table1 (champ1, champ2) values('valeur1', 'valeur2');

Jusque là tout va bien. Comment récupérer cet identifiant nouvellement créé ? La première solution qui vient à l'esprit est de récupérer le plus grand identifiant de la table1:

select max(id)as max_id from table1;

Le résultat obtenu risque de ne pas être le résultat escompté: il se peut qu'une nouvelle insertion intervienne avant que l'on récupère l'identifiant. Si le site n'a que 3 visiteurs par mois le risque que cela arrive est faible mais non négligeable pour un site à fort traffic. Ce n'est pas la bonne méthode: il faut utiliser la fonction mysql_insert_id(). Cette fonction récupère l'identifiant auto-incrémenté lié à la dernière insertion, pour la connexion courante.

Essayons de prouver cela avec les deux scripts suivants en simulant une insertion parasite:


<?php

// script n°1 basé sur mysql_insert_id():
$mysql_link=mysql_connect($host, $user, $password);
mysql_select_db('db', $mysql_link);

$query_max = "select max(id) as max_id from table1";
printf('Plus grand id de la table: %d<br>', 
       current(mysql_fetch_assoc(mysql_query($query_max, $mysql_link)))
       );

$query = "insert into table1 (champ1, champ2) values('value1', 'value2')";
$result = mysql_query($query, $mysql_link);
printf('id inséré: %d<br>', mysql_insert_id($mysql_link));
?>


<?php

// script n°2 basé sur le max:
$mysql_link=mysql_connect($host, $user, $password);
mysql_select_db('db', $mysql_link);

$query_max = "select max(id) as max_id from table1";
printf('Plus grand id de la table: %d<br>', 
       current(mysql_fetch_assoc(mysql_query($query_max, $mysql_link)))
       );

$query = "insert into table1 (champ1, champ2) values('value1', 'value2')";
$result = mysql_query($query1, $mysql_link);
sleep(10);

printf('id inséré: %d<br>', 
       current(mysql_fetch_assoc(mysql_query($query_max, $mysql_link)))
       );
?>

Imaginons que le plus grand identifiant de la table1 soit 10. On exécute d'abord le script n°2 puis tout de suite après le script n°1. Le scritp n°2 fait une pause de 10 secondes après l'insertion pour simuler une requête qui s'exécuterait avant la récupération du maximum. L'identifiant inséré par le script n°2 sera donc 11 et celui inséré par le script n°1 sera 12. Mais le résultat obtenu n'est pas bon: le scritp n°2 renvoie 12 et le script n°1 renvoie 12.

On pourrait faire l'opération inverse pour mettre en défaut la fonction mysql_insert_id() en faisant une pause de 10 seconde avant l'appel de la fonction. On verrait que la fonction renvoie bien le résultat voulu.

Quel est mon mot de passe ?

Nicolas — Tue, 14 Mar 2006 15:27:10 +0000

Dans une interface d'administration qui se respecte, on doit pouvoir à un moment créer des comptes. Il est souvent agréable de se voir proposer un mot de passe aléatoire. En général, je n'utilise pas un mot de passe complétement alétaoire: je supprime les caractères ambigus tels que 0, 1, i, j, l, m, n, o, u, v,I,O. Le code peut ressembler à ça. La fonction attend en paramètre la longueur du mot de passe à générer. Cette fonction n'a rien d'extraordinaire mais elle ne fait que ce qu'on lui demande mais elle le fait bien!


<?php
function generate_password($size) {
  $listeChar = '23456789abcdefghkpqrstwxyzABCDEFGHKJLMNPQRSTUVWXYZ'; 
  $max = strlen($listeChar)-1;

  $key = '';
  for ($i=0;$i<$size;$i++) {
    $key .= $listeChar[mt_rand(0,$max)];
  }
  return $key;
}
?>

Petite mise à jour. J'avais oublié de préciser une chose: pourquoi je supprime certains caractères ? Je supprime les caractères 0, 1, i, j, l, m, n, o, u, v,I,O car ils sont potentiellement ambigus. Le "i" peut être confondu avec le "l", le "0" avec le "O". Même dans la phrase précédente on ne sait pas au premier coup d'oeil si j'ai écris "le zéro et la lettre O" ou "la lettre O et le zéro. L'intérêt est de générer des mots de manière automatique en enlevant les ambiguïtés visuelles.

Développement piloté par les tests.

Nicolas — Tue, 21 Feb 2006 17:16:58 +0000

Il ne semble pas évident au premier abord de faire des tests du code que l'on écrit. En général, on se borne à vérifier qu'il n'y a pas d'erreurs de syntaxe. On vérifie que les 3 ou 4 pages que l'on vient de modifier fonctionnent toujours de la même façon. Cette manière de fonctionner atteint rapidement ses limites au fur et à mesure que l'application grossie. Comment se rappeler que le code écrit aujourd'hui n'aura pas d'impact sur le code écrit il y a 6 mois ? Sans tests exhaustifs, c'est tout simplement impossible.

Il est hors de question de dérouler les tests "à la main". On va écrire des tests automatiques ou plus particulièrement des tests de non-régression, c'est-à-dire des tests qui permettent de vérifier que les modifications apportées à l'application n'ont pas apportées de bugs ou de modifications fonctionnelles. En fait ils permettent de s'assurer que l'application fonctionnera de la même façon.

En PHP, il y a de nombreuses bibliothèques pour se faciliter la tâche, notament PHPUnit ou Simple Test. En ayant un peu regardé les deux je me suis décidé à utiliser Simple Test.

Après avoir lu un livre sur l'Extrême Programming, il me parait plus judicieux d'écrire les tests avant de commencer à coder quoi que ce soit. Ca peut sembler étrange au premier abord mais en utilisant cette pratique de plus en plus souvent cela semble bien plus naturel et surtout plus facile que d'écrire le code et de s'assurer que les tests que l'on va mettre en place couvrent bien tout l'aspect fonctionnel du code.

Un p'tit exemple valant mieux qu'un long discours, imaginons que l'on veuille écrire une "interface" de connexion à une zone membre. On veut que l'utilisateur ayant un couple identifiant/mot de passe correct soit connecté à la zone et que les autres utilisateurs soient rejettés.

Code préliminaire: // login_test.php


<?php
require_once('../simpletest/web_tester.php');
require_once('../simpletest/reporter.php');
class TestOfLogging extends WebTestCase {
  function testAuth() {
    $this->WebTestCase();
  }
}
$test =  new TestOfLogging();
$test->run(new HtmlReporter());
?>

Et on obtient le joli panneau suivant:

TestOfLogging

1/1 test cases complete: 0 passes, 0 fails and 0 exceptions.

C'est un peu normal puisque l'on a rien testé! Premier test:


<?php
require_once('../simpletest/web_tester.php');
require_once('../simpletest/reporter.php');

class TestOfLogging extends WebTestCase {
  function testAuth() {
    $this->WebTestCase();
  }

  function testUnknownUser() {
    $this->get ('http://localhost/xp/login1.php');
    $this->setField('login', "inconnu");
    $this->setField('password', 'mot-de-passe');
    $this->clickSubmit('Ok');
    $this->assertWantedPattern('/utilisateur inconnu/i');
  }
}

$test =  new TestOfLogging();
$test->run(new HtmlReporter());
?>

On obtient ceci:

TestOfLogging

Fail: testUnknownUser -> Pattern [/utilisateur inconnu/i] not detected in [String: <br /> <b>Warning</b>: require_once(./classes/Auth.php) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or directory in <b>/home/nicolas/webspace/simp...] at [/home/nicolas/webspace/simpletests/tests/login_test.php line 15]

1/1 test cases complete: 0 passes, 1 fails and 0 exceptions.

C'est normal puisque l'on n'a pas encore écrit de code! Une fois le formulaire soumis on affiche le message "utilisateur inconnu". C'est ce message que l'on cherche dans le test

L'idée principal du développement piloté par les tests (écrire les tests puis coder) est d'écrire les tests fonctionnels dans un premier temps puis d'écrire le code minimal qui permette de valider le test. On ne cherche pas à faire le code le plus beau et le plus performant à cette étape. Au test d'après on peut factoriser des bouts de code pour améliorer la qualité générale. On n'aura l'assurance que l'on a rien cassé grâce aux tests. Donc pour passer le test, il suffit d'ajouter dans le script login1.php (qui devient login2.php), une ligne avec "Utilisateur inconnu". C'est loin d'être optimal et c'est même un peu moche comme code. On est confronté à un nouveau problème. La première fois que l'on arrive sur la page, on a le message "Utilisateur inconnu".

Lorsqu'on se trouve avec un "bug" ou un comportement non voulu, on commence par écrire le test correspondant et qui échoue nécessairement. Le voici (en tête de la fonction testUnknownUser):


<?php
$this->assertNoUnWantedPattern('/utilisateur inconnu/i');
?>

Il nous faut maintenant écrire le code minimal qui permette de passer ce test. Il suffit d'ajouter le code suivant: (login3.php)


<?php
if (isset($_POST['sub'])) {
  echo '<p>Utilisateur inconnu</p>';
}
?>

Et on arrive au résultat attendu:

TestOfLogging

1/1 test cases complete: 2 passes, 0 fails and 0 exceptions.

Attaquons-nous à la partie "utilisateur reconnu"! On va créer un objet User qui regroupera toutes les propriétés d'un utilisateur et en particulier le fait que son identification est correcte. Les tests dans login.php se résumeront à appeler une méthode vérifiant la validité du couple login/mot de passe pour pouvoir accéder à la zone membre. On va supposer dans un premier temps que l'objet existe et que l'on peut l'utiliser de la manière suivante:


<?php
require_once('./classes/User.php');
$is_valid= false;

if (isset($_POST['sub'])) {
  $user = new User();
  $is_valid = $user->isValid($_POST['login'], $_POST['password']);
}
if ($is_valid) {
  echo 'Vous êtes connecté<br>';
} else {
  // affichage du formulaire
}
?>

Ecrivons maintenant les tests vérifiant qu'un utilisateur reconnu (login: Lebon et mot de passe: Secret) peut se connecter:


<?php
require_once('../simpletest/web_tester.php');
require_once('../simpletest/reporter.php');
require_once('../classes/User.php');

class TestOfLogging extends WebTestCase {
  function testAuth() {
    $this->WebTestCase();
  }

  function testUnknownUser() {
    $this->get ('http://localhost/xp/login.php');
    $this->assertNoUnWantedPattern('/utilisateur inconnu/i');
    $this->setField('login', "inconnu");
    $this->setField('password', 'mot-de-passe');
    $this->clickSubmit('Ok');
    $this->assertWantedPattern('/utilisateur inconnu/i');
  }

  function testKnownUserCanLogIn() {
    $this->get ('http://localhost/xp/login.php');
    $this->setField('login', 'Lebon');
    $this->setField('password', 'Secret');
    $this->clickSubmit('Ok');
    $this->assertWantedPattern('/connecté/i');
  }
}

$test =  new TestOfLogging();
$test->run(new HtmlReporter());
?>

En testant, on obtient ça:


Warning: require_once(../classes/User.php) [function.require-once]: failed to open stream: No such file or directory in /var/www/xp/test/login_test.php on line 4

Fatal error: require_once() [function.require]: Failed opening required '../classes/User.php' (include_path='.:/usr/share/php') in /var/www/xp/test/login_test.php on line 4

Après avoir créer la classe User, on obtient:

TestOfLogging

Fail: testUnknownUser -> Pattern [/utilisateur inconnu/i] not detected in [String: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="fr"> <head> <title>Zone membre</title> </head> <body> <h1>Zone membre</h1> <br /> <b>Fatal...] at [/var/www/xp/test/login_test.php line 17]
Fail: testKnownUserCanLogIn -> Pattern [/connecté/i] not detected in [String: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="fr"> <head> <title>Zone membre</title> </head> <body> <h1>Zone membre</h1> <br /> <b>Fatal...] at [/var/www/xp/test/login_test.php line 25]

1/1 test cases complete: 1 passes, 2 fails and 0 exceptions.

On va donc écrire une classe User minimale permettant de passer le nouveau test. Elle pourrait ressembler à ça:


<?php
class User 
{
  public function __construct() {
  }

  public function isValid($login, $password) {
    if ((trim($login)=='Lebon') && (trim($password)=='Secret')) {
      return true;
    } else {
      return false;
    }
  }
}
?>

Et on obtient alors le beau panneau vert suivant:

TestOfLogging

1/1 test cases complete: 3 passes, 0 fails and 0 exceptions.

Tout le code écrit n'est pas forcément optimal mais on l'idée générale du développement dirigé par les tests. On va pouvoir modifier le code sans risquer d'avoir des régressions fonctionnelles ce qui est un des buts principaux de la méthode.

Version finale de la page d'accès à la zone membre: login.php
Version finale du script de tests: login_test.php
Version finale de la classe User: User.php

A la découverte de php5

Nicolas — Sun, 15 Jan 2006 20:22:24 +0000

La version 5 de PHP est sortie depuis plus d'un an, le 13 juillet 2004 exactement. Je ne parlerais pas des nombreux changements tellement c'est énorme. Mais de quoi je vais parler, alors ? De ma déouverte de php5.

Je me suis mis à php5 voici quelques mois. L'installation sur HP-UX n'a pas été une mince affaire mais ça fonctionne!

J'avais pris comme habitude avec php4 de développer sur le serveur de test avec le niveau d'erreur E_ALL (2047). Avec php5, je suis passé à E_ALL & E_STRICT, soit 4095. La plupart des scripts qui se disent compatibles php5 ne passent pas avec ce niveau d'erreurs. Un exemple flagrant: on ne peut plus déclarer un attribut de classe (une variable) de la manière suivante:

Il faut utiliser un des mots-clés de portée, à savoir public, protected ou private.

Précédence des opérateurs

Nicolas — Wed, 21 Dec 2005 11:01:01 +0000

Il existe en PHP deux types de "ET" (and et &&) et de "OU" (or et ||). La raison est qu'ils ont des priorités différentes. Le and et le or ont une priorité plus faible que l'opérateur = alors que le && et le || ont une priorité plus élevée que le =.

Par exemple si on a le code suivant:

<?php
$choix1 = "un";
$choix2 = "deux";
$choix3 = "trois";

$val1 = $choix1 || $choix2 || $choix3; 
$val2 = $choix1 or $choix2 or $choix3; 
?>

$val1 sera égal à true et $val2 sera égal à "un".

Pour régler le problème, soit on met tout le temps des parenthèses, soit on n'utilise les opérateurs && et ||.

Afficher une arborescence avec menu et sous-menu.

Nicolas — Fri, 22 Jul 2005 22:25:36 +0000

On est souvent confronté à ce type de problème: afficher sous forme d'arbre (liste ul/li par exemple) un menu ou un forum. On récupère les informations d'une base de données où chaque enregistrement comprend les champs suivants (au minimum): id, label, parent. La requête de sélection est toute simple: select id, nom, parent from table.

Imaginons que l'on est récupéré ces enregistrements là:


    <?php

	$tab[1] = array('label'=>'menu1','parent'=>0);

    $tab[2] = array('label'=>'menu1.1','parent'=>1);

    $tab[3] = array('label'=>'menu1.1.1','parent'=>2);

    $tab[4] = array('label'=>'menu1.1.2','parent'=>2);

    $tab[5] = array('label'=>'menu1.2','parent'=>1);

    $tab[6] = array('label'=>'menu2','parent'=>0);

    $tab[7] = array('label'=>'menu3','parent'=>0);

    $tab[8] = array('label'=>'menu3.1','parent'=>7);

    $tab[9] = array('label'=>'menu3.2','parent'=>7);

    $tab[10] = array('label'=>'menu3.3','parent'=>7);

?>

On veut obtenir ça:

menu1
- menu1.1
  - menu1.1.1
  - menu1.1.2
- menu1.2
menu2
menu3
- menu3.1
- menu3.2
- menu3.3

Et le code PHP correspondant peut ressembler à çà:


<?php

function addTree(&$Tree,$feuille,$id) {

	   global $tab;

	

   $Tree[$feuille['label']]['__LABEL'] = $feuille['label'];   

	   foreach ($tab as $cle => $element) {

	      if ($element['parent']==$id) {

	         addTree($Tree[$feuille['label']],$element,$cle);

	      }

	     }

	    }

	      

    
    $Tree = array();

	foreach ($tab as $cle => $feuille) {

	  if ($feuille['parent']==0) {

	    addTree($Tree,$feuille,$cle);

	  }

	  }

	  
	      ?>

Cette petite fonction récurssive peut sembler anodine mais elle fait tout le boulot et elle le fait bien.