TP n°1 - Prise en main de PHP et de la boîte à outils Symfony
Application PHP en ligne de commande « gestionnaire de tâches Todo »

On considère que vous avez acquis les notions de base sur la syntaxe du langage PHP, dans la séquence de Travail en Autonomie qui précède cette séance.

Du point de vue théorique, cette séance revisite principalement les acquis des cours d’informatique de l’année passée, sur le modèle objet et les bases de données relationnelles.

Dans cette séance, on utilisera les outils suivants :

• la ligne de commande dans un terminal, avec le shell bash
• l’outil Symfony en ligne de commande
• l’environnement d’exécution PHP 8
• Composer

• l’IDE Eclipse (ou un équivalent) pour PHP
• le navigateur Web

Le présent support de séance de TP est consultable via une mise en forme avec l’habillage org-html-themes, qui permet de masquer/révéler les différentes sections du support¹.

Dans le présent support de TP, les copies d’écrans et autres spécificités reflètent autant que possible l’état des versions installées sur les machines DISI des salles de TP en environnement GNU/Linux Ubuntu.

Il est probable que sur les machines individuelles, le support de PHP et de Symfony sera parfois différent.

Même si les technologies utilisées pour les séquences d’apprentissage actif (programmation PHP avec le framework Symfony) sont théoriquement portables et utilisables sur différents systèmes d’exploitation, des différences existent qui rendent parfois difficile le support au vu des différentes variantes possibles, et pour un module enseigné en promo entière.

Pour cette séance, on supposera que vous travaillez sur la machine que vous allez utiliser pour le reste des séances de TP et de travail hors-présentiel (y compris le projet).

Vous aurez besoin d’un terminal en ligne de commande, mais aussi de l’environnement graphique pour utiliser l’IDE.

Nous vous suggérons de travailler, pour chaque séance, dans un répertoire spécifique.

• $HOME/CSC4101/
  • tp-01/
  • tp-02/
  • …

1. Configurez un répertoire de travail $HOME/CSC4101/ dans votre compte.

   mkdir $HOME/CSC4101/
   cd $HOME/CSC4101/
   

2. Pour l’instant, on crée un nouveau répertoire spécifique à cette séance :

   mkdir -p tp-01/
   cd tp-01/
   

Exécutez les commandes suivantes :

cd $HOME/CSC4101/tp-01/
symfony composer create-project oberger/tspcsc4101-todo-skeleton todo-app "v2.*" -n

Comme vous le voyez, Composer télécharge une version spécifique (2.x) de l’application ToDo à partir du projet « oberger/tspcsc4101-todo-skeleton », qui a été préparé pour les besoins du cours.

Le code de ce projet Symfony est extrait dans le répertoire ~/CSC4101/tp-01/todo-app/.

Explications de la signification des différents éléments de cette invocation :

composer

invocation de Composer, l’outil de gestion de paquetages PHP

create-project

commande create-project de composer qui crée un projet à partir d’un squelette existant (cf. documentation composer)

oberger/tspcsc4101-todo-skeleton

référence du squelette d’application qui a été préparé pour le cours

todo-app

répertoire du projet à créer

v2.*

version particuilère à télécharger : 2.x (la dernière version de la branche 2 ayant été publiée via packagist.org)

-n

option --no-interaction de composer create-project permettant de répondre avec les valeurs par défaut en cas de confirmations demandées pour l’exécution de recettes flex (configuration et génération de fichiers utiles)

Vérifiez le contenu du répertoire todo du projet Symfony qui vient d’être créé.

ls todo-app/

Pour l’instant, repérez les éléments principaux qui vont nous intéresser :

bin  composer.json  composer.lock  config  public  src  symfony.lock  todo.sqlite  var  vendor

composer.json

descriptif du projet Composer de l’application. Il référence notamment les bibliothèques PHP utilisées dans ce projet basé sur Symfony;

Vous pouvez consulter son contenu (format JSON) dans un éditeur de texte.

Au fur et à mesure de la vie d’un projet Symfony on pourra utiliser Composer à nouveau, pour y ajouter des dépendances, les bibliothèques de développement dont on aura besoin au cours de l’ajout des fonctionnalités.

bin/console

script exécutable PHP présent dans le sous-répertoire bin/, utilisé en ligne de commande pour le développement Symfony, chaque fois qu’on va invoquer symfony console en ligne de commande;

src/

cœur du squelette d’application Symfony. Il contient le code source PHP de l’application, sur lequel vous travaillerez principalement par la suite;

templates/

sources des gabarits Twig de l’application, sur lesquels vous serez amenés à travailler également, quand vous concevrez les pages Web;

vendor/

contient le code de toutes les bibliothèques PHP du framework Symfony qui seront utilisées. Elles ont été téléchargées par Composer, et y seront mises à jour en cas d’évolutions (correction de bugs, etc.).

Interdiction de modifier manuellement le contenu de ce répertoire, sous peine de malédiction. On ne touche qu’au code qui est dans src/.

Le script bin/console fourni dans le projet permet d’accéder en ligne de commande (dans un terminal) à différentes fonctionnalités du cadriciel Symfony, notamment des utilitaires intéressants pour les phases de développement et de tests.

On lancera les commandes via l’invocation symfony console de l’outil Symfony en ligne de commande préalablement installé.

Essayez les commandes suivantes dans un terminal, depuis l’intérieur du répertoire du projet Symfony :

1. Vérifiez la version de Symfony utilisée dans le projet

   cd $HOME/CSC4101/tp-01/todo-app/
   symfony console -V
   

   Symfony 6.4.24 (env: dev, debug: true) [...]
   

   Vous êtes bien en environnement de développement dev (pas encore prêts pour la production !)

   Si vous voyez l’affichage « CLI version 5.12.0 (c) 2021-2025 Fabien Potencier (2025-06-16T09:40:30Z - stable) », c’est que vous n’êtes pas dans le bon répertoire; votre shell n’est pas positionné à l’intérieur du projet.

2. Affichez la liste des sous-commandes disponibles (avec la sous-commande list, ou directement sans argument passé à symfony console) :

   symfony console list
   

3. Consultez l’aide en ligne avec la sous-commande help. Par exemple :

   symfony console help about
   

4. Et consultez donc également la sortie fournie par cette sous-commande about :

   symfony console about
   

   Cette commande donne différentes informations sur l’environnement de développement et de mise au point.

On va re-créer la base de données de l’application, qui nous sert à effectuer des tests en local pendant le développement et la mise au point du code.

Effectuez les opérations suivantes dans un terminal en ligne de commande :

1. Supprimez le fichier de base de données SQLite existant :

   symfony console doctrine:database:drop --force
   

2. Créez un fichier de base de données SQLite (vide), en exécutant la commande suivante :

   symfony console doctrine:database:create
   ls -l *.sqlite
   

   En fait, il se trouve que cette commande se contente de créer un fichier vide, ce qui correspond au comportement nécessaire pour une base de données légère comme SQLite. Mais dans le cas où on utiliserait un autre SGBD, ceci peut s’avérer nécessaire.

3. Créez le schéma de la base SQLite (tables, index, etc.), en utilisant la sous-commande doctrine:schema:create :

   1. Commencez-donc par vérifier ce qui serait fait :

      symfony console doctrine:schema:create --dump-sql
      

      CREATE TABLE todo (
             id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
             title VARCHAR(255) DEFAULT NULL,
             completed BOOLEAN NOT NULL,
             created DATETIME DEFAULT NULL,
             updated DATETIME DEFAULT NULL
      );
      

      Le code SQL affiché devrait vous sembler assez clair, pour l’instant.

      Si ce n’est pas le cas, nous vous suggérons d’acquérir les connaissances minimales sur SQL vues en CSC3601 (vous pouvez vous appuyez sur cette ressource de remédiation)

   2. Puis créez le schéma pour de bon, avec :

      symfony console doctrine:schema:create
      

Dans le squelette fourni, les développeurs de ToDo on codé une interface en ligne de commande.

1. Appelez la première commande ’list-todos’ :

   symfony console app:list-todos
   

2. Sans surprise, cette commande affiche la liste des tâches connues dans la base de données de l’application : [ERROR] no todos found!.

   Ça fonctionne nominalement… mais la base de données est vide, vu qu’on vient de la recréer dans l’étape précédente.

Heureusement pour nous, les développeurs ont aussi préparé un jeu de données de test, qu’on peut utiliser.

Chargez les données de tests qui ont été préparées dans le squelette fourni :

1. Utilisez la commande Symfony du module Doctrine pour charger des données de tests (fixtures) :

   symfony console doctrine:fixtures:load -n
   
      > purging database
      > loading App\DataFixtures\AppFixtures
   
   

   la base de données doit maintenant contenir ces données de tests.

2. Vérifiez en relançant la commande app:list-todos

1. Vous avez déjà découvert la première fonction de l’application, disponible en ligne de commande pour les développeurs :

   cd $HOME/CSC4101/tp-01/todo-app/
   symfony console app:list-todos
   

   Sans surprise, cette commande affiche la liste des tâches connues dans la base de données de l’application.

2. Vérifiez les autres sous-commande app:* présentes :

   symfony console list app
   

3. Utilisez maintenant la commande app:show-todo pour afficher les détails de la tâche n°2.

Comme vous pouvez le constater, notre application se présente, pour l’instant, de façon très rudimentaire, en ligne de commande.

Pour naviguer dans le code objet et nous faciliter la vide pendant le codage, on va utiliser un IDE (Integrated Development Environment) compatible avec PHP, composer et Symfony.

Eclipse dans une version récente (2025.06, par exemple) convient tout à fait, via sa distribution Eclipse for PHP Developers, qui inclut tous les plugins nécessaires.

Symfony gère la notion d’environnements ayant différentes configurations au sein d’un même projet : développement, tests, production.

Nous sommes actuellement en phase de développement, en local sur notre machine, avec déjà pas mal d’outils pour tester notre code, fournis par le cadriciel Symfony.

Notez l’existence du fichier « .env » à la racine du projet Symfony :

ls -a
cat .env

Ce fichier .env définit les valeurs de certaines variables de configuration du projet Symfony, dans le répertoire courant. Ces valeurs définissent les spécificités de l’« environnement Symfony » dev (utilisé en phase de développement).

Ces valeurs diffèrent des valeurs cibles pour le déploiement futur de l’application une fois qu’elle sera mise en production (cf. les valeurs par défaut du fichier « .env.dist »).

Les données affichées par l’application proviennent d’une base de données relationnelle

SQLite stocke la base de données relationnelle dans un fichier présent dans le répertoire du projet Symfony.

Vérifiez le contenu du fichier (caché) .env présent à la racine du projet, qui définit des variables d’environnement, comme les paramètres d’accès à la base de données :

1. Chargez le le fichier .env dans l’IDE

   Attention, c’est un fichier caché… il faut éventuellement le faire apparaître dans l’IDE.

   Pour cela, dans Eclipse :

   • cliquez sur le bouton avec trois petits points verticaux, en haut à droite de la colonne du « Project Explorer »;
   • puis sur « Filters and Customizations »;
   • dans la liste des « Pre-Set filters », dé-cochez « .* ressources », puis « OK ».

   Les fichiers cachés apparaissent dans le projet, dont le fichier .env.

2. Ouvrez .env, et vérifiez la valeur de la variable DATABASE_URL, présente dans la section doctrine/doctrine-bundle.

   Elle doit typiquement prendre la valeur sqlite:///%kernel.project_dir%/todo.sqlite, afin d’utiliser SQLite pour les besoins du développeur qui teste en local :

   DATABASE_URL=sqlite:///%kernel.project_dir%/todo.sqlite
   

   Ainsi, la base de données SQLite utilisée pour les tests sera créée dans $HOME/CSC4101/tp-01/todo-app/todo.sqlite.

La base de données avait été peuplée pour la première exécution de l’application qu’on a faite plus haut.

Examinez son contenu via les opérations suivantes :

1. Vérifiez que la base de données est présente

   ls -l todo.sqlite
   sqlite3 todo.sqlite ".tables"
   

   Elle doit contenir la table : todo

   Vous pouvez aussi utiliser l’outil GUI sqlitebrowser pour consulter le contenu de la base de données, s’il est installé : sqlitebrowser todo.sqlite.

2. Consultez les détails du contenu de la table todo :

   symfony console dbal:run-sql "select * from todo"
   

   ou bien directement :

   sqlite3 todo.sqlite "select * from todo"
   

3. Affichez le schéma de cette table :

   sqlite3 todo.sqlite ".schema todo"
   

Cette base de données semble bien correspondre au modèle de données de notre application, au vu de ce qu’on en a compris jusqu’ici.

C’est logique, puisqu’elle a été créée via l’outil Doctrine inclus dans l’environnement de développement de Symfony lors de l’appel à symfony console doctrine:schema:create.

Vérifions maintenant où est spécifié ce modèle de données, dans le code des classes PHP de notre application.

On souhaite gérer des tâches (« to dos ») dans notre application.

Dans notre application Symfony, on va gérer ces éléments aussi bien :

• en mémoire durant l’exécution du programme PHP;
• dans la base de données relationnelle, qui stockera les données entre deux exécutions de notre programme,

On va gérer les structures de données correspondantes avec deux approches conjointes :

• le modèle objet, pour la représentation en mémoire et les traitements à l’exécution;
• le modèle relationnel, pour le stockage (persistence) dans la base de données.

En base de données, on aura donc la relation todo, stockée sous forme de table dans SQLite, qu’on a vue plus haut.

Du côté objets, on utilisera la bibliothèque PHP Doctrine, qui est un ORM (Object Relational Mapper). Son rôle est de permettre la gestion de collections d’objets, d’associations entre entités, et de fournir le chargement/sauvegarde des objets depuis la base de données.

Pour faire court, le principe de l’ORM est de convertir chaque instance d’une relation (chaque ligne d’une table de la base de données) en instance d’une classe PHP en mémoire, et inversement. Doctrine appelle Entités ces classes d’objets. L’ORM utilise SQL pour charger ou sauvegarder les données.

La programmeuse peut ainsi écrire des classes PHP utilisant les fonctionnalités de Doctrine, et ainsi gérer en objet des instances des entités, ou des collections d’entités.

Quand deux entités sont liées (association 1-n, par exemple), des fonctions de Doctrine permettent de gérer cette association « OneToMany » et d’accéder à la collection des entités liées facilement dans les programmes.

Le code PHP qui exécute le traitement de la commande app:list-todos se trouve dans le fichier src/Command/ListTodosCommand.php du projet.

1. Consultez le fichier src/Command/ListTodosCommand.php dans l’IDE

2. Consultez la déclaration de la classe avec ses attributs :

   #[AsCommand(
       name: 'app:list-todos',
       description: 'List the todos',
       )]
   class ListTodosCommand extends Command
   {
   

   Les attributs PHP 8 définissent des méta-données utiles au framework Symfony. Ici, AsCommand permet de décrire la commande, en définissant son nom, et la description qui sera affichée dans la liste des commandes (symfony console list app).

   On a donc une nouvelle commande appelable depuis la console via symfony console app:list-todos.

1. Consultez maintenant le cœur du sujet, dans le code de la méthode execute(). Comprenez-vous le rôle de cette méthode ?

   $io = new SymfonyStyle($input, $output);
   
   // fetches all instances of class Todo from the DB
   $todos = $this->todoRepository->findAll();
   //dump($todos);
   
   if(!empty($todos)) {
       $io->title('list of todos:');
       $io->listing($todos);
   } else {
       $io->error('no todos found!');
       return Command::FAILURE;
   }
   
   return Command::SUCCESS;
   

   Quelques commentaires :

   • l’utilitaire SymfonyStyle fourni par Symfony permet de mettre en forme des affichages sur la sortie standard dans la console :

     title()

     affiche un message de titre (colorisé)

     listing()

     affiche une liste d’éléments sous forme de liste à puces

     error()

     affiche un message d’erreur (colorisé)

   • $todoRepository est une propriété de notre classe ListTodosCommand, qui est un Repository d’objets (TodoRepository) pour accéder à la base de données qui stocke les instances de tâches.

     On peut charger une collection de toutes les instances de tâches de la base de données, avec l’appel à findAll() sur ce Repository. Elle renvoie une « liste/tableau » d’instances de la classe Todo, une pour chaque ligne de la table todo de la base de données.

     Remarque : il faudrait aller voir le code de TodoRepository (présent dans src/Repository/TodoRepository.php) pour voir comment cette classe est liée à la classe Todo, qui n’apparaît pas ici par magie.

     Mais ce serait aller explorer des éléments un peu trop complexes pour le moment. On y reviendra dans les séquences du cours ultérieures.

     Pour l’instant, on peut se contenter de voir l’aide fournie par l’IDE qui montre le prototype de la méthode findAll() si on laisse le pointeur fixe sur son appel dans l’instruction $todos = $this->todoRepository->findAll(); :

     App\Repository\TodoRepository::findAll() : Todo[] 
     
     Returns:
      Todo[]
     

     Même si on ne connaît pas tous les détails du rôle d’un repository on sait désormais que cette méthode renvoie un tableau d’instances de Todo. De l’utilité d’avoir un IDE comprenant les projets Composer, le PHP objet, etc.

   Ce code suffit donc à afficher toutes les tâches présentes dans la base de données, mises en forme de façon agréable sur la sortie standard en ligne de commande.

   Regardons à présent à quoi ressemblent ces « tâches » dans le code, avec cette fameuse classe Todo.

Les objets manipulés par notre application constituent le modèle de données. Ici, un ensemble de tâches codées grâce à la classe PHP Todo.

Dans un projet Symfony utilisant Doctrine, les classes des entités du modèle de données sont définies dans les fichiers source présents dans src/Entity/ (complétés par les classes de src/Repository/).

Voyons ce que les développeurs de Todo y ont codé en PHP objet :

1. Consultez src/Entity/Todo.php dans l’IDE, pour consulter le code de la classe Todo.

   Notez la convention de structuration du projet utilisée, pour faciliter la correspondance entre les noms des classes, avec les espaces de noms (namespaces) PHP, et leur emplacement dans la structure de répertoires du code source :

   • Namespace : App\Entity
   • Classe : Todo (convention : toute classe commence par une capitale)
   • Répertoire : src/Entity

   • Fichier source : Todo.php (une seule classe par fichier source PHP)

     L’auto-loader PHP utilisé dans les projets Symfony basés sur Composer, parcourt automatiquement les répertoires de sources du projet (principalement src/ et de ses bibliothèques, en dessous de vendor/) pour charger les fichiers sources, et détecter les déclarations de namespace permettant de résoudre ultérieurement les imports via l’instruction use.

     Exemple :

     Programme 1 : déclaration de classe dans son namespace (dans src/Entity/Todo.php)

     namespace App\Entity;
     
     ...
     
     class Todo {
     
         ...
     

     Programme 2 : utilisation dans src/Command/ListTodosCommand.php

     use App\Entity\Todo;
     
     ...
     
         $this->todoRepository = $doctrineManager->getRepository(Todo::class);
     
     ...
     
     

2. Pouvez-vous identifier les propriétés (variables d’instances) définies dans la classe Todo ?

   Vous remarquez que chacune de ces propriétés est décorée avec un attribut ORM\Column qui permet à Doctrine de savoir comment en gérer la persistence.

   On retrouve la correspondance avec les éléments renvoyés par sqlite3 todo.sqlite ".schema todo" ou symfony console doctrine:schema:create --dump-sql :

   propriété de classe	type PHP	attribut Doctrine	colonne en base
   Todo::id	int	ORM\Id, ORM\GeneratedValue	INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL
   Todo::title	string	ORM\Column(length: 255, nullable: true)	VARCHAR(255) DEFAULT NULL
   Todo::completed	bool	ORM\Column	BOOLEAN NOT NULL
   Todo::created	Datetime	ORM\Column(type: Types::DATETIME_MUTABLE, nullable: true)	DATETIME DEFAULT NULL
   Todo::updated	Datetime	ORM\Column(type: Types::DATETIME_MUTABLE, nullable: true)	DATETIME DEFAULT NULL

   Vous savez donc maintenant où et comment on peut programmer ces attributs ORM destinés à Doctrine pour la persistence en base de données, qui définissent les conversions de type, les contraintes de stockage, de valeurs non-nulles, etc. On y reviendra en détails ultérieurement.

3. Observez la méthode __toString() qui réalise la conversion en chaîne de caractères (pour l’affichage sur la console, entre autres).

Examinons maintenant un exemple de code de mise à jour du contenu de la base de données, celui qui s’exécute lors de l’invocation de symfony console doctrine:fixtures:load pour charger les données de tests dans la base locale.

Examinez le code dans src/DataFixtures/AppFixtures.php

Le code de la méthode AppFixtures::loadTodos() va appeler autant que nécessaire sa méthode génératrice getTodosData(), pour récupérer des couples (titre, complété), et les sauvegarder comme autant de tâches, dans la base de données.

Ce code fonctionne en deux temps :

1. création d’une instance de tâche en mémoire, pour chaque couple [$title, $completed], en utilisant des instructions standard en PHP objets (appel au constructeur, puis aux setters):

   $todo = new Todo();
   $todo->setTitle($title);
   $todo->setCompleted($completed);
   

2. sauvegarde des données via les appels à persist() et flush() de Doctrine, qui vont générer une requête (INSERT) en base de données pour chaque instance nouvelle présente en mémoire.

   Inutile d’en savoir beaucoup plus pour l’instant.

Au fur et à mesure de l’exécution d’une application Symfony, des traces (logs) sont sauvegardées dans un fichier.

C’est le cas en particulier en environnement de développement, pour mieux identifier les problèmes à l’exécution.

cat var/log/dev.log

tail -f var/log/dev.log

Vous pouvez vérifier s’il y a des messages importants, par exemple avec :

grep -a --color=auto "ERROR\|CRITICAL" var/log/dev.log

Il se peut qu’il n’y ait rien d’affiché, ce qui serait bon signe. Essayez alors de taper :

symfony console app:null
grep -a --color=auto "ERROR\|CRITICAL" var/log/dev.log

Vous devriez maintenant voir votre erreur, tracée dans ce journal.

Essayez de lancer à nouveau l’exécution des différentes commandes vues dans cette séquence, aussi bien en lecture qu’en modifications (cf. étape précédente).

Immédiatement après l’exécution de chaque commande, vérifiez le contenu du fichier de traces (logs) var/log/dev.log.

Vous pouvez par exemple exécuter :

symfony console app:list-todos
grep "doctrine.DEBUG" var/log/dev.log

La commande grep va filtrer le contenu du fichier de traces pour n’afficher que ce qui est relatif à Doctrine.

Vous devriez voir passer toutes les requêtes SQL effectuées par les commandes. Pratique pour la mise au point en cas de problèmes, si le code ne fait pas ce qu’on veut.

Depuis la ligne de commande, vous allez lancer le serveur HTTP intégré à l’outil Symfony en ligne de commande.

Le serveur rend accessible via HTTP des ressources disponibles dans le répertoire du projet Symfony d’où il a été lancé. Quand ces ressources correspondent à des programmes PHP, il les exécute pour faire interpréter les requêtes HTTP par ces programmes.

Lancez la commande suivante :

cd $HOME/CSC4101/tp-01/todo-app/
symfony server:start

Le serveur se lance et affiche quelque chose du genre :

 [OK] Web server listening
      The Web server is using PHP CLI 8.3.6
      http://127.0.0.1:8000
[Web Server ] Jul 10 13:15:56 |DEBUG  | PHP    Reloading PHP versions
[Web Server ] Jul 10 13:15:56 |DEBUG  | PHP    Using PHP version 8.3.6 (from default version in $PATH)
[Web Server ] Jul 10 13:15:56 |INFO   | PHP    listening path="/usr/bin/php8.2" php="8.2.7" port=38555
[PHP        ] [Mon Jul 10 13:15:56 2023] PHP 8.3.6 Development Server (http://127.0.0.1:38555) started

1. Chargez l’URL http://localhost:8000/ (ou http://127.0.0.1:8000) dans un navigateur Web (lancé sur la même machine)

   Vous constatez le comportement suivant :

   • Une page Web affiche « Welcome to Symfony 6.4.x »

   • dans le terminal, le serveur Web affiche une trace du style :

     [PHP        ] [Fri Aug 26 15:55:05 2024] ::1:33926 [404]: GET /
     

   Le serveur fonctionne, et affiche les traces (logs) de fonctionnement au fur et à mesure des connexions du navigateur.

2. Remarquez la structure des traces : cette ligne affiche différentes informations :

   [PHP        ] [Fri Aug 26 15:55:05 2024] ::1:33926 [404]: GET /
   

   Fri Aug 26 15:55:05 2024

   date de réception de la requête HTTP lors du chargement de l’URL à partir du navigateur

   ::1:33926

   source de la requête : ici, client HTTP (le navigateur Web) connecté depuis localhost (::1 en IPv6), émettant sa requête depuis le port source 33926 (ou un équivalent IPv4 du genre : 127.0.0.1:44530)

   404

   code de réponse HTTP (404 Not Found), renvoyé par le serveur

   GET

   méthode HTTP demandée dans la requête du client

   /

   chemin d’accès à la ressource demandée : le client a accédé à http://localhost:8000/, donc à la ressource racine du serveur Web : « / » .

   Pour l’instant, on n’a pas étudié le protocole HTTP, mais vous devriez probablement avoir ententu parler de cette infame erreur 404.

   On constate donc que le serveur Web répond avec un code d’erreur HTTP (404), ce qui signifie qu’il n’a pas trouvé ce qui est demandé…

3. Comment expliquer que ce code de réponse 404 est renvoyé, alors que le navigateur affiche bien une page ?

   Le serveur Web a bien effectué un traitement, en réponse à la requête du navigateur de chargement de la ressource /.

   Il a en fait démarré l’exécution de notre application PHP Symfony, en contexte Web, cette fois-ci.

   Le serveur nous dit : « 404 : il n’y a rien à la racine du site ! »

   En effet, du fait de ce qui est présent dans le code de l’application, Symfony ne trouve pas de resource à afficher, mais nous renvoie néanmoins une page HTML, pour habiller le message d’erreur : un code de réponse 404 (Not found).

   Par exception, comme nous sommes en environnement de développement, Symfony nous accueille avec un tel message informatif en cas d’erreurs. Notez qu’on voit ce code « 404 » apparaître en rouge en bas à gauche de la page Web.

4. Essayez sur http://localhost:8000/todo/list : est-ce mieux, maintenant ?

   OK, dans cette version très basique de l’application Todo, les développeurs ont mieux géré la présentation en ligne de commande que le look des pages Web… normal, ça viendra en temps utile dans la suite du cours.