Votre demande de fonctionnalité est-elle liée à un problème ? Veuillez le décrire.

Actuellement, Jeedom Core utilise une architecture de classes sans namespaces, ce qui pose plusieurs problèmes :

• Risques de conflits de noms avec les plugins ou bibliothèques externes
• Impossibilité d'utiliser l'autoloading PSR-4 de Composer de manière optimale
• Code moins maintenable et moins conforme aux standards PHP modernes
• Difficultés pour structurer le code de manière hiérarchique

Décrivez la solution que vous souhaitez

Créer un dossier src/ à la racine du projet (ou dans core/) pour introduire progressivement les namespaces PHP en suivant PSR-4, tout en conservant la compatibilité avec l'API existante.

Structure proposée :

core/
├── src/
│   └── Jeedom/
│       └── Core/
│           ├── Database/
│           │   └── DB.php
│           ├── Equipment/
│           │   └── EqLogic.php
│           └── ...
├── class/
│   ├── DB.class.php (facade vers Jeedom\Core\Database\DB)
│   └── ...
└── composer.json (avec autoload PSR-4)

Exemple concret avec la classe DB :

Nouvelle classe namespacée (src/Jeedom/Core/Database/DB.php) :

<?php
namespace Jeedom\Core\Database;

class DB 
{
    public static function execute(string $query, array $params = []): Result 
    {
        // Nouvelle implémentation moderne qui retourne un objet Result
        // avec des méthodes comme ->fetchAll(), ->rowCount(), etc.
    }
    
    public static function transaction(callable $callback): mixed 
    {
        // Nouvelle méthode pour gérer les transactions proprement
    }
    
    // ... autres méthodes avec une API moderne
}

Classe facade existante (core/class/DB.class.php) :

<?php
require_once __DIR__ . '/../vendor/autoload.php';

class DB 
{
    // Méthodes legacy qui adaptent vers la nouvelle API
    public static function prepare(string $query, array $params = []): \PDOStatement 
    {
        // Adaptation : utilise la nouvelle méthode execute() 
        // mais retourne un PDOStatement pour compatibilité
        $result = \Jeedom\Core\Database\DB::execute($query, $params);
        return $result->getPDOStatement(); // méthode d'adaptation
    }
    
    public static function execute(string $query, array $params = []): bool 
    {
        // Adaptation : utilise la nouvelle API mais retourne un bool
        $result = \Jeedom\Core\Database\DB::execute($query, $params);
        return $result->isSuccessful();
    }
    
    // ... autres méthodes d'adaptation
}

Configuration Composer (composer.json) :

{
    "autoload": {
        "psr-4": {
            "Jeedom\\Core\\": "src/Jeedom/Core/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Tests\\": "tests/"
        }
    },
    "require-dev": {
        "phpunit/phpunit": "^10.0"
    }
}

Tests obligatoires avant migration (tests/Database/DBTest.php) :

<?php
namespace Tests\Database;

use PHPUnit\Framework\TestCase;

class DBTest extends TestCase 
{
    public function testPrepareReturnsPDOStatement(): void 
    {
        $stmt = DB::prepare("SELECT 1");
        $this->assertInstanceOf(\PDOStatement::class, $stmt);
    }
    
    public function testExecuteReturnsBool(): void 
    {
        $result = DB::execute("SELECT 1");
        $this->assertIsBool($result);
    }
    
    // ... autres tests couvrant l'API publique
}

Plan de migration progressive :

1. Phase 1 : Mise en place de l'infrastructure (dossier src, composer autoload)
2. Phase 2 : Prérequis obligatoire - Création des tests unitaires pour les classes à migrer
3. Phase 3 : Migration des classes centrales (DB, config, log) avec leurs tests
4. Phase 4 : Migration méthode par méthode des classes complexes (toujours avec tests)
5. Phase 5 : Optimisation et nettoyage des facades

Prérequis de migration par classe :

• Tests unitaires couvrant l'API publique existante (facade)
• Tests d'intégration pour les fonctionnalités critiques
• Validation que tous les tests passent avant ET après migration
• Documentation des changements d'API interne

Décrivez les alternatives que vous avez envisagées

• Migration complète immédiate : Trop risquée pour la compatibilité plugins
• Utilisation d'alias de classes : Moins flexible que l'héritage pour les extensions futures
• Namespace à la racine : Jeedom\Core\ offre plus de flexibilité pour l'organisation

Contexte supplémentaire

Cette évolution s'inscrit dans la modernisation de Jeedom Core et permettra :

• Une meilleure intégration avec l'écosystème Composer
• Un code plus maintenable et testable avec une API moderne
• Une transition douce pour les développeurs de plugins via les facades d'adaptation
• L'adoption progressive des bonnes pratiques PHP modernes
• La liberté d'évoluer l'API interne sans casser la compatibilité

Importance des tests :
Les tests unitaires sont un prérequis absolu pour cette migration car ils :

• Garantissent que la compatibilité est maintenue après chaque migration
• Documentent le comportement attendu de chaque classe
• Permettent de détecter les régressions lors des refactorings
• Facilitent la maintenance future du code

La compatibilité totale avec les plugins existants est garantie par le système de facades qui adaptent les appels legacy vers la nouvelle API, validé par une suite de tests complète.