Discussion :

[laurentSc]

Bonjour,

pour rendre mon code plus clair, je comptais faire des require donc mettre des bouts de code dans des fichiers PHP et le fichier principal serait constitué essentiellement d'une succession de require. Le souci est que le code est de la POO. Au préalable, tout le code étant dans un seul fichier, quand j'instanciais une classe, comme au début du fichier, j'avais mis un use, et que ce fichier contient en fait une autre classe, instanciée dans index.php qui contient l'autoloader, la classe était incluse, donc pas de souci. Mais maintenant, comme j'ai déporté l'instanciation de la classe, du coup, il ne la trouve pas. J'ai tenté de rajouter le use dans le fichier PHP déporté mais il ne la trouve pas plus.

Comment faire, SVP ?

[cavo789]

Bonjour Laurent

Prends le temps de faire le tour de Composer (https://getcomposer.org/); cet outil excelle dans ce domaine. Tu n'aurais plus qu'à faire un unique require_once() et hop, tout est bon.

Composer se base sur un fichier composer.json qu'il te faudra créer et tu y diras que p.ex. \MonNameSpace se trouve dans le dossier /src/classes et hop, dès la première utilisation d'une classe de ce namespace, composer sait où aller aller chercher le code de la classe.

Composer ne sert pas qu'à ça mais aussi à intégrer des dépendances externes (avec un composer require xxx) et tu verras alors que c'est vraiment l'outil parfait pour ce type de besoin.

[laurentSc]

Bonjour cavo789,

je me souviens que tu recommandes régulièrement cet outil et que j'avais déjà regardé mais que j'avais abandonné. Je regarderai de nouveau tout à l'heure et si besoin, je poserai des questions.

[cavo789]

Voici un composer.json de l'un de mes projets : https://github.com/cavo789/pandoc/bl.../composer.json

La partie qui va t'intéresser est https://github.com/cavo789/pandoc/bl...poser.json#L27

Tu définis un autoload comme tu le verras en ligne 27. Je dis donc "ok, mon ami Composer, mes sources sont dans le dossier /src de mon projet",

Du coup, lorsque je vais tenter d'accéder à l'une de mes classes (imaginons https://github.com/cavo789/pandoc/bl...andoc.php#L375), composer va lire le nom complet de la classe (https://github.com/cavo789/pandoc/bl...pandoc.php#L38) et va "savoir" que "ok, donc, puisque je dois aller dans le dossier /src du projet pour trouver le code d'une classe, allons donc dans le dossier /src/Exceptions (qui correspond au namespace) et voir si j'ai un fichier PandocSettingsNoPandocRootElement (le nom de la classe donc)." Et bingo, il va trouver la classe (https://github.com/cavo789/pandoc/bl...lement.php#L10).

Du coup, je n'ai plus à me soucier des différents require; composer le fait pour moi.

Le reste des infos sur le site de composer : https://getcomposer.org/doc/01-basic...md#autoloading

A++

[laurentSc]

J'avance très lentement, mais j'avance.

Déjà, installer composer, ça n'a pas été de la tarte : étant sur un PC professionnel, l'installateur Windows (mon OS est Windows 10) ne marchait pas (ça ouvrait une fenêtre me demandant un mot de passe, que je ne connais pas). Donc chu passer à l'installation en ligne de commande. Ca a fini par marcher.
2e étape : ajouter une variable d'environnement pour pouvoir taper composer au lieu de php composer.phar. Même ça, ça a pris du temps. J'ai fini par taper environnement dans la barre de recherche et ça m'a ouvert une fenêtre permettant de rentrer une nouvelle variable.

Bon, j'en suis là. Pas encore essayé de créer un fichier json. Mais une fois que ce sera fait, comment activer composer pour que quand je lance l'exécution de mon projet, il bosse ?

[cavo789]

Il ne bosse pas pendant l'exécution ;-)

Tu fait un "composer update" p.ex. en ligne de commandes; il va traiter ton fichier composer.json (que tu crées donc) et il va générer tout ce qu'il faut dans le dossier /vendor (qu'il va créer lui).

Ensuite, comme je le disais, tu dois faire un require unique (https://getcomposer.org/doc/01-basic...md#autoloading) et hop, ton code PHP va donc, lui, charger ce qu'il faut pour l'autoloading. Composer ne tourne donc pas en tâche de fond; il aide à la génération des fichiers (/vendor/autoload.php).

Composer prend un peu de temps à apprendre mais c'est du temps sacrément bien investi.

Comme apprendre xdebug; c'est plus long qu'un "var_dump($ma_variable);" mais terriblement plus efficace.

Perso, je développe depuis un an sous Windows mais dans un environnement WSL2 (Linux/Ubuntu); j'utilise donc composer.phar que j'ai mis dans un dossier global. Mais fonctionne parfaitement sous Windows itou.

[laurentSc]

Merci Christophe,
j'ai pas encore créé de composer.json ; néanmoins, pour tester, j'ai copié le fichier que tu m'as indiqué (https://github.com/cavo789/pandoc/bl.../composer.json). Dans le répertoire de mon projet (ticket_rawsrc), j'ai créé un sous-répertoire composer et j'ai mis dedans composer.json puis j'ai fait composer update ...et :

composer update
Composer could not find the config file: C:\projets\ticket_rawsrc\composer
To initialize a project, please create a composer.json file. See https://getcomposer.org/basic-usage

Comment ça se fait ?

Pour la variable d'environnement, j'ai :

nom de la variable : composer
valeur de la variable : C:\projets\ticket_rawsrc\composer

[cavo789]

Bonjour Laurent

La norme (je pense n'avoir jamais vu le contraire même si techniquement cela doit être jouable) est de mettre composer.json à la racine du site; pas dans un sous-dossier.

Dans une console DOS, rends-toi à la racine de ton site et exécute composer update (ou composer dump-autoload). Composer va alors créer le dossier /vendor, toujours à la racine.

Ceci fait et pour autant que tu as bien rédigé le fichier composer.json, édite ton propre fichier .php pour y ajouter le require("./vendor/autoload.php") comme tu l'auras lu dans la documentation.

Note : si tu regardes le fichier composer.json que je t'ai indiqué comme exemple (https://github.com/cavo789/pandoc/bl...poser.json#L29), je lui dis donc que mes classes sont dans le dossier ./src de mon site. Il faut donc, fort logiquement, que j'y ai en effet mis mes classes. Je dis cela parce que tu vas devoir faire de même : regroupe tes propres classes dans un dossier (/src ou autre) et c'est ce nom de dossier qu'il te faudra mentionner.

Ensuite, c'est le namespace de la classe qui va entrer en ligne de compte pour savoir où, dans ce dossier-là, retrouver les fichiers. Je l'expliquais précédemment avec mon exemple sur la classe d'exception.

Bon codage

[laurentSc]

Merci Christophe,
j'ai déplacé, comme tu me l'indiques, composer.json à la racine du projet et là, il l'a trouvé. Le dossier vendor existe déjà ; il a créé dedans un nouveau sous-répertoire composer. Après composer update,

[RuntimeException]
Could not scan for classes inside "src/" which does not appear to be a file nor a folder

Normal, vu qu'il n'existe pas.
Tu m'indiques de regrouper mes classes dans un répertoire (src ou autre). J'ai une architecture MVC, donc mes classes sont réparties dans différents répertoires qui comportent eux-mêmes des sous-répertoires. Je suppose donc pouvoir conserver mon arborescence, en la déplaçant dans un répertoire src. OK ?

[laurentSc]

Supposant que la réponse est oui, j'ai commencé à y travailler.

Avant, il y avait déjà un autoloader dans le fichier index.php :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
$autoloader = function ($full_class_name) {
    // on prépare le terrain : on coupe le nom pleinement qualifié de la classe en morceaux
    $parts = explode('\\', $full_class_name);
 
    // si le 1er segment de l'espace de nom === le nom de ton application (APP_NAME_NS)
    // alors il sera remplacé par le chemin jusqu'au dossier courant
    if ($parts[0] === APP_NAME_NS) {
        array_shift($parts); //dépile du tableau $parts le 1er élément (donc APP_NAME_NS)
    } else {
        // si le premier segment de l'espace de nom est différent de ton espace de nom racine
        // alors on lui dit d'aller voir dans le dossier vendor
        array_unshift($parts, 'vendor'); // empile "vendor" au début du tableau $parts
    }
    // on construit le chemin complet du fichier à inclure
    // il faut que l'autoloader soit toujours à la racine du site
    // l'espace de nom AppName correspond à la racine du site : point de départ de
    // tous les espaces de noms
    // Point de départ remplacé par le chemin courant : DIR_ROOT pour le système d'exploitation
    $path = DIR_ROOT.implode(DIRECTORY_SEPARATOR, $parts).'.php';
    // on vérfie que le fichier existe et on l'inclut
    // sinon on passe la main à une autre autoloader (return false)
    if (is_file($path)) {
        include $path;
        return true;
    } else {
        return false;
    }
};
 
spl_autoload_register($autoloader);

Je suppose que si j'utilise composer, je le commente. OK ?

A noter que l'arborescence du projet (avant) est (je simplifie) :

ticket_rawsrc
   controller
       license
       ticket
       Home.php
       ...
   model
      license
      ticket
       ...
   view
      license
      ticket
      view.php
       ...
   vendor
       rawsrc
          PDOPlusPlus
             PDOPlusPlus.php
          PhpEcho
             PhpEcho.php
             ...    

et que les espaces de nom sont du type ticket_rawsrc\controller\license ou bien rawsrc\PDOPlusPlus ou rawsrc\PhpEcho

[cavo789]

Tu m'indiques de regrouper mes classes dans un répertoire (src ou autre). J'ai une architecture MVC, donc mes classes sont réparties dans différents répertoires qui comportent eux-mêmes des sous-répertoires. Je suppose donc pouvoir conserver mon arborescence, en la déplaçant dans un répertoire src. OK ?

Exactement. Tu déplaces tout ce petit monde sous le dossier /src. Là-bas, tu respectes tes namespaces (tu crées donc autant de répertoires que tu le souhaites) : /src/classes, /src/controllers, /src/models, ... Comme tu le sens. Tu pourrais faire autrement aussi mais restons pour l'instant simple : un dossier /src avec ses sous-dossiers; cela fait très bien le job.

Avant, il y avait déjà un autoloader dans le fichier index.php .... Je suppose que si j'utilise composer, je le commente. OK ?

Yep (à supprimer même puisque tout ça, ce sera le job de composer). En fait, donc, tu remplaces tout ce petit monde par un simple require_once(./vendor/autoloader.php); et c'est tout bon.

et que les espaces de nom sont du type ticket_rawsrc\controller\license ou bien rawsrc\PDOPlusPlus ou rawsrc\PhpEcho

Je ne comprends pas tout à fait. Tu aurais donc deux namespace de premier niveau différents (ticket_rawsrc et rawsrc)? Ce n'est pas un souci mais puisque tu as deux niveaux, tu aurais deux sous-dossiers dans /src.

Sur base de tes dossiers, je verrais donc /src/controller, /src/model et /src/view. Et donc, oui, quand tu feras un use ticket_rawsrc\controller\license, le fichier autoload.php que tu auras chargé, ira chercher le fichier dans /src/controller/license.php.

Note : sache que, le dossier /vendor est un dossier totalement automatique. Ce dossier tu peux le supprimer de ton projet et c'est ce qu'on fait toujours lorsqu'on utiliser un système de versioning tel que github. On met ./vendor dans le fichier .gitignore. Le dossier /vendor est donc 100% automatique : quand tu fais un composer update (ou composer install pour la première fois), le dossier est créé et s'il y a des "dépendances" (càd des librairies tierces mentionnées dans le fichier composer.json, celles-ci sont téléchargées et copiées dans le dossier vendor). Je dis cela parce que tu as listé dans ton précédent message ce que le dossier contient : en général, on s'en fout un peu et je voulais attirer ton attention sur le fait de laisser composer faire le job; ne crée / place jamais rien dans le dossier; tu peux presque l'oublier. Composer gère le dossier pour toi; automatiquement.

Pourquoi est-il important pour un développeur PHP d'apprendre à utiliser composer ? Pour ne pas réinventer la roue. Imagine le besoin suivant : tu aimerais gérer des logs et écrire des infos / warning / error / debug dans un fichier journal. Forcément, une telle librairie existe n'est-ce pas ? La plus connue est monolog (https://github.com/Seldaek/monolog). Et là, bingo ! composer require monolog/monolog pour l'installer pour ton projet et tu es prêt à l'utiliser. Yep ! Aussi facile que ça. Composer l'installe et crée le fichier ./vendor/autoload.php "qui va bien"; tout seul. Du coup, dans ton propre code php; tu n'as qu'à appeler la librairie (voir exemple https://github.com/Seldaek/monolog#basic-usage). Et c'en est fini de la prise de tête des fichiers php à ajouter manuellement en require_once. Composer est une pépite car, à terme, ton projet va faire usage de plusieurs librairies externes. Le site https://packagist.org/ en recense par milliers. A chaque fois que tu vois une librairie qu'on installe à coup de composer require xxx; bingo, tu sais quoi faire et tu sais que c'est hyper aisé.

[laurentSc]

Comme dit dans le post précédent, j'ai commenté l'ancien autoloader.

Mon composer.json est le suivant :

Code json :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
{
  "name": "schmitt/ticket",
  "description": "tool to manage data extracted from databases (ARM and Remedy)",
  "type": "project",
  "license": "MIT",
  "authors": [
    {
      "name": "Laurent Schmitt",
      "email": "adresse_mail@se.com"
    }
  ],
  "keywords": [
    "php"
  ],
  "minimum-stability": "dev",
  "require": {
    "php": ">=7.2.0"
  },
  "autoload": {
    "classmap": [
      "src/"
    ]
  }
}

Dans index.php :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
define('DIR_ROOT', __DIR__.DIRECTORY_SEPARATOR);
 
require(DIR_ROOT."vendor\autoload.php") ;

Tout au départ, c'est la méthode invoke de la classe Home qui est appelée.

Tout au début de cette méthode, j'appelle statiquement une méthode de debug :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
namespace ticket_rawsrc\src\controller;
 
use ticket_rawsrc\src\view\view;
use ticket_rawsrc\src\controller\UtilFct;
 
class Home
{
    public function invoke(array $data = [])
    {UtilFct::debug("controller home 11 ici ","");
     ...

et :

Fatal error: Uncaught Error: Class "ticket_rawsrc\src\controller\UtilFct" not found in C:\projets\ticket_rawsrc\src\controller\Home.php:11 Stack trace: #0 C:\projets\ticket_rawsrc\index.php(115): ticket_rawsrc\src\controller\Home->invoke(Array) #1 {main} thrown in C:\projets\ticket_rawsrc\src\controller\Home.php on line 11

En effet, avec xdebug, je vois dans ClassLoader.php et $this->classMap :ticket_rawsrc\controller\UtilFct = "C:\projets\ticket_rawsrc\vendor\composer/../../src/controller/UtilFct.php"Dans le nom de l'index, il manque src car la classe UtilFct se trouve dans C:\projets\ticket_rawsrc\src\controller. Comment cela se fait-il ?

[cavo789]

Tu ne dis pas si tu as exécuté un composer update... Ou encore ici, un composer dump-autoload

[laurentSc]

J'avais fait composer update mais en te lisant, j'ai essayé composer dump-autoload et ça a marché ! C'est quoi la différence ?

Sinon, il y a d'autres soucis ; ça attendra demain...

[laurentSc]

Bonjour Christophe,

la lecture du post #11 (que j'avais pas vu hier) m'a remotivé car avant de le lire, je pensais jeter l'éponge...
Car même si au post #14, je disais que ça marchait, en fait, y a un progrès, mais ça marche pas tout à fait et les autres soucis dont je parlais hier soir, c'est ça.

Je ne comprends pas tout à fait. Tu aurais donc deux namespace de premier niveau différents (ticket_rawsrc et rawsrc)? Ce n'est pas un souci mais puisque tu as deux niveaux, tu aurais deux sous-dossiers dans /src.

C'est cette phrase-là qui m'a interpelé car justement, mon souci vient des outils (logiciels) liés au deuxième namespace.
En fait, pour ce projet, j'utilise deux "outils" (des classes) développées par rawsrc (d'où le nom du namespace), ex-modérateur à dvp (il a arrêté pour raisons personnelles en avril 2020) : pdoplusplus (pour gérer MySQL) et phpecho (pour gérer les affichages)(selon moi, 2 bijoux, d'une utilisation simple (car à ma portée) mais à la complexité extraordinaire).
C'est tellement complexe que je n'ose y toucher, même pour changer l'espace de nom.
L'ancien autoloader, développé aussi par rawsrc, donné au post #10 gérait cette dualité de namespace au 1er niveau.
Comme tu dis que pour gérer cette dualité, il faut créer 2 sous-dossiers dans src, voici mon arborescence :

ticket_rawsrc
   src
       controller
       model
       view
       vendor
           rawsrc
               rawsrc
                   PhpEcho
                       PhpEcho.php
                       + 2 autres fichiers
                   PDOPlusPlus
                       PDOPlusPlus.php

    vendor (le dossier créé par composer)
        composer
        autoload.php

    index.php

Comme rawsrc suppose l'existence d'un dossier vendor, je l'ai gardé.
Les namespaces sont ceux donnés au post #10.
Comme tout est localisé dans le répertoire src, mon composer.json reste bon.

Donc j'ai fait un composer autoload-dump (en ligne de commande) en me mettant à la racine du site et dans principal (index.php)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
define('DIR_ROOT', __DIR__.DIRECTORY_SEPARATOR);
 
require(DIR_ROOT."vendor\\autoload.php") ;

Quand je lance mon projet :

Fatal error: Uncaught TypeError: src\rawsrc\rawsrc\PhpEcho\PhpEcho::{closure}(): Return value must be of type rawsrc\PhpEcho\PhpEcho, src\rawsrc\rawsrc\PhpEcho\PhpEcho returned in C:\projets\ticket_rawsrc\src\vendor\rawsrc\rawsrc\PhpEcho\stdPhpEchoHelpers.php:359 Stack trace: #0 C:\projets\ticket_rawsrc\src\vendor\rawsrc\rawsrc\PhpEcho\PhpEcho.php(535): src\rawsrc\rawsrc\PhpEcho\PhpEcho->{closure}() #1 C:\projets\ticket_rawsrc\src\vendor\rawsrc\rawsrc\PhpEcho\PhpEcho.php(554): src\rawsrc\rawsrc\PhpEcho\PhpEcho->__invoke(Object(Closure)) #2 C:\projets\ticket_rawsrc\src\view\DispMsg.php(18): src\rawsrc\rawsrc\PhpEcho\PhpEcho->__toString() #3 C:\projets\ticket_rawsrc\src\controller\Home.php(13): ticket_rawsrc\src\view\DispMsg:: DispMsg('test_dispmsg ho...', 'debug') #4 C:\projets\ticket_rawsrc\index.php(115): ticket_rawsrc\src\controller\Home->invoke(Array) #5 {main} thrown in C:\projets\ticket_rawsrc\src\vendor\rawsrc\rawsrc\PhpEcho\stdPhpEchoHelpers.php on line 359

Tu crois que je peux m'en sortir ?

[cavo789]

Bienvenue dans le monde merveilleux de composer...

Rawsrc est donc une librairie externe (ce n'est pas ton code) que tu utilises dans ton projet. En vocabulaire composer cela se nomme une dépendance.

Je vois cette page : https://packagist.org/packages/rawsrc/phpecho

Du coup le développeur a prévu l'installation via composer require rawsrc/phpecho. Et bingo tu as rawsrc installé et tenu à jour par composer. Tu peux supprimer ta copie, plus besoin.

(BRAVO pour ta persévérance, cela vaut le coup)

[laurentSc]

Merci pour l'aide. Comme il y a 2 dépendances, j'ai fait composer require rawsrc/phpecho et composer require rawsrc/pdoplusplus. J'ai aussi simplifié mon arborescence :

ticket_rawsrc
   src
       controller
       model
       view

    vendor (le dossier créé par composer)
        composer
        autoload.php

    index.php

Néanmoins

Fatal error: Uncaught Error: Class "rawsrc\PhpEcho\PhpEcho" not found in C:\projets\ticket_rawsrc\src\view\DispMsg.php:13 Stack trace: #0 C:\projets\ticket_rawsrc\src\controller\Home.php(13): ticket_rawsrc\src\view\DispMsg:: DispMsg('test_dispmsg ho...', 'debug') #1 C:\projets\ticket_rawsrc\index.php(115): ticket_rawsrc\src\controller\Home->invoke(Array) #2 {main} thrown in C:\projets\ticket_rawsrc\src\view\DispMsg.php on line 13

Pourtant, tout au début de la classe DispMsg :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
namespace ticket_rawsrc\src\view;
 
use rawsrc\PhpEcho\PhpEcho;

Qu'est-ce qui va pas ?

[cavo789]

Il me semble que cela aurait dû fonctionner. Tente un composer dump-autoload...

Est-ce que ton projet serait sur github ? Je pourrais l'installer et checker...

[laurentSc]

Je venais de faire composer dump-autoload...j'ai recommencé mais pareil.

Mon projet n'est pas sur GitHub pour 2 raisons :
- je maîtrise pas donc j'ai jamais rien mis sur GitHub
- mon projet gère une bdd pleine de données confidentielles (cela dit, sur GitHub, on pourrait la vider car ça doit marcher avec une bdd vide)

Tu m'as montré que rawsrc avait pris en compte composer. Moi, qui croyais, non pas qu'il ignorait cet outil, mais qu'il voulait exister sans cet outil....

[cavo789]

Ce que github reçoit, ce sont tes fichiers. Si tu n'as pas de fichiers .sql avec le contenu de la DB, zéro souci. Et même, il suffirait d'interdire l'envoi des fichiers .sql au travers du fichier .gitignore. Tu peux donc publier ton code source sans publier la DB mais, c'est juste pour info : c'est toi qui voit; pas de souci. Note encore : github permet d'avoir des projets (=repositories) privés.

Pour composer, c'est dommage de "refuser" de l'utiliser; comme je l'ai déjà mentionné, il existe des milliers de librairies existantes afin de ne pas réinventer la roue. J'ai cité le cas de monolog qui permet d'écrire des fichiers logs sans aucune prise de tête. L'objectif d'un développeur n'est pas de réinventer sans cesse la roue mais de bosser sur sa fonctionnalité, son business, de créer un logiciel pour répondre à son besoin et s'il peut réutiliser du code existant; tant mieux.

Poste un peu le contenu de ton fichier composer.json pour voir ? Est-ce que tu as bien les deux projets dans /vendor (il s'agira de deux sous-dossiers) ?