add namespace autoloader

[pifou25]

Description

Bonjour,
Je propose d'ajouter la gestion de namespaces via l'autoloader de Composer. Le namespace permet d'éviter des conflits de classes qui auraient le même nom, en particulier avec tous les plugins. Cela permettra à chaque plugin de faire ce qu'il veut dans son propre namespace. Et autre avantage, toutes les classes des plugins seront automatiquement chargées.
En plus, la fonction autoloader est grandement simplifiée

classmap: scanne automatiquement les répertoires indiqués et ajoute les classes détectées dans un autoloader vendor/composer/autoload_classmap.php
files: ajoute tous les fichiers requis sur chaque requête
psr-4: comme détaillé par kwizer un peu plus bas ça permettra de déplacer les classes du core dans de nouvelles classes namespacées, dans /src avec un namespace Jeedom\Core ... Et pour chaque plugin qui le souhaite d'utiliser son propre namespace, il suffit pour cela de créer nos classe dans le namespace suivant: Jeedom\plugins\idplugin\src par exemple :)

Point d'attention:

• dans translate.class.php on a une fonction en dehors de la classe (la fameuse fonction __ !! ) je la déplace donc dans utils.inc.php
• dans files il faut placer utils.inc.php avant jeedom.config.php car ce fichier de config utilise la fonction de traduction __
• l'autoloader spécifique jeedom n'est plus utile que pour la classe *Cmd de chaque plugin, que Composer ne voit pas forcément s'il est dans le même fichier qu'une autre classe.
• il faudrait refaire un composer dump-autoload pour regénérer l'autoloader après chaque installation / suppression de plugin

Il y a encore plein de code php en dehors de toute classe, qui gagnerait à être déplacé dans de nouvelles classes. Ceci est géré par la méthode include_file dans utils.inc.php ça ne change pas.

Suggested changelog entry

migration to Composer autoloader

Related issues/external references

Fixes #

Types of changes

• Bug fix (non-breaking change which fixes)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the [La ligne directrice pour contribuer à ce projet / Contribution guidelines for this project).
• I grant the project the right to include and distribute the code under the GNU.
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added MD documentation for the sniff.

[kwizer15]

Ça doit pouvoir s'appeler directement depuis le code php de composer. Je veux dire, sans passer par la commande. Le mieux c'est surement de l'intégrer directement après le d/l du plugin. Je suis assez d'accord pour l'update de jeedom, mais c'est à vérifier tout de même.

[kwizer15]

Ah ça veut pas ! 😅

[pifou25]

Ah ça veut pas ! 😅

ben non, vraiment pas... Et la, je ne vois pas pourquoi, on dirait que quelqu'un ou quelque chose déclenche malgré tout une tentative de connexion à la db. Peut être un appel à la classe log quelque part ?

[kwizer15]

Je pense qu’il y a un soucis de conception à la base. J’ai mon idée de comment "corriger" mais c’est pas léger. Je te propose de faire sans les fichiers qui posent problème dans un premier temps (jeedom.config.php et d’autres si c’est le cas) et de garder le fonctionnement actuel pour ces fichiers. On essaiera de les gérer dans un second temps sur une autre PR.

[pifou25]

J'ai donc enlevé jeedom.config.php de l'autoloader Composer et remis dans core.inc.php
et phpstan est heureux :) et je ne comprends pas pourquoi il ne passait pas :(
Il faudrait mettre cette constante dans une classe avec un init au runtime, mais ça change l'appel et il faudrait voir partout où cette constante est appelée...

[kwizer15]

C'est à peu près mon idée. Pour moi faudrait transformer ce tableau en un objet qui implémente ArrayAccess. Ca permettrait de garder l'utilisation actuelle, mais aussi de l'initialiser seulement au premier accès.
Je sais pas encore si ca vaut le coup, par experience, c'est pas complètement safe à faire.

[kwizer15]

Proposition de modification du fichier jeedom.config.php

Référence : https://github.com/kwizer15/core/blob/d76183abb920a394ce191bb5cc82f40d025fa48a/core/config/jeedom.config.php

Approche adoptée :
Cette solution s'appuie sur votre concept de __toString tout en résolvant le problème des concaténations directes présentes dans la configuration actuelle.

Implémentation :

• Création d'un objet Translation contenant :

  • La clé de traduction
  • Un préfixe (optionnel)
  • Un suffixe (optionnel)
  • Les deux paramètres de traduction existants (qui conservent leurs valeurs par défaut dans notre contexte)

• Introduction de la fonction t() : similaire à __() mais génère directement un objet Translation avec support de __toString

• Possibilité d'ajouter un préfixe et un suffixe non traduits à la fonction t()

Avantage principal :
L'évaluation de __toString est différée jusqu'à l'utilisation effective, évitant ainsi son déclenchement prématuré lors du chargement de la configuration.

Note : L'extraction de la classe et de la fonction interne reste optionnelle selon les besoins.

[kwizer15]

(optionel) Rajouter un

  "Jeedom\\Core\\": "src/"

pour permettre d’initialiser de nouvelles classes PSR-4 (futur PR?)

[pifou25]

je n'ai pas répondu avant, pourquoi pas ajouter un namespace pour les classes du core mais dans ce cas, pourquoi dans src ? je l'aurais laissé dans /core/class ou un autre rep du /core pour conserver la structure actuelle.

[kwizer15]

Je comprends ta question sur le choix de src/. L'idée derrière cette approche, c'est de préparer une migration progressive vers du PSR-4 moderne.

Pourquoi src/ plutôt que garder dans /core/class ? Plusieurs raisons :

1. Standards de l'écosystème
PSR-4 recommande src/ comme racine pour les classes namespacées. Ça nous alignerait sur ce que fait tout l'écosystème PHP aujourd'hui, ce qui faciliterait l'intégration avec les outils modernes (IDE, analyseurs de code, etc.).

2. Clarté de la migration
En gardant deux arbos distinctes :

• /core/class/ → l'ancien système (fichiers *.class.php)
• src/ → le nouveau (classes PSR-4 propres)

On évite le mélange des genres et c'est plus clair pour tout le monde ce qui est "legacy" vs "moderne".

3. Stratégie de transition
L'objectif c'est que les anciennes classes deviennent des « wrappers » qui appellent les nouvelles implémentations. Comme ça, zero breaking change pour les plugins existants, mais on peut développer du code plus propre en interne.

Au final, c'est plus une question de préparation pour l'avenir que de besoin immédiat. Mais si on veut un jour pouvoir faire évoluer Jeedom vers des pratiques plus modernes, autant poser les bonnes bases dès maintenant.

Ça permettrait, par exemple, de mettre immédiatement la classe Translation (ou Trad) de la configuration jeedom.config.php dans un namespace dédié et d’éviter les confusions avec la classe translate déjà existante.

Qu'est-ce que tu en penses ?

[pifou25]

ok pour /src moi ça me va très bien

[pifou25]

Merci pour tes retours je les ai pris en compte :)
Je vais laisser le fichier jeedom.config.php tel quel, ça mérite de faire une autre PR pour ce sujet, avec la reprise de la fonction __() de partout.

[kwizer15]

Ok pense juste a remettre le incluse dans le core dans ce cas. Le dim. 14 sept. 2025, 18:12, Pifou25 ***@***.***> a écrit :

…

*pifou25* left a comment (jeedom/core#2910) <#2910 (comment)> Merci pour tes retours je les ai pris en compte :) Je vais laisser le fichier jeedom.config.php tel quel, ça mérite de faire une autre PR pour ce sujet, avec la reprise de la fonction __() de partout. — Reply to this email directly, view it on GitHub <#2910 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEKOTULM3L6QMF5OSXIDR33SWHVBAVCNFSM6AAAAABOUPRCRWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEOBZGY2TSMRRGM> . You are receiving this because you commented.Message ID: ***@***.***>