Registrierung

Der Registry ist der Modulkonfigurations-Cache von Nibiru. Beim Booten durchläuft er jedes Verzeichnis unter application/module/, analysiert die jeweilige settings/*.ini-Datei eines Moduls und macht die geparste Konfiguration über einen einzigen Accessor zugänglich. Denken Sie daran, dass es sich um das Gravitationszentrum handelt, das die Module gegeneinander in Orbit hält.

Wie die Erkennung funktioniert

Für jedes Modul unter application/module/<name>/settings/:

1. Der Registrierungsprozess durchsucht Dateien mit dem Muster *.ini.
2. Für jede Datei versucht er zunächst den umgebungspezifischen Dateinamen (<base>.<env>.<ext>, z.B. users.production.ini); falls dies nicht möglich ist, greift er auf den Basisnamen zurück (users.ini).
3. Er ruft die Funktion parse_ini_file($path, true) (mehrere Abschnitte) auf.
4. Er sucht nach einem Abschnitt mit dem Namen des Moduls, in Großbuchstaben — [USERS], [CMS], [ANALYTICS].
5. Die geparsten Schlüssel-Wert-Paare werden zu einem \stdClass-Objekt, das durch den Modulnamen indiziert ist.

Ein Modul konfigurieren lesen

$users = \Nibiru\Registry::getInstance()->loadModuleConfigByName('users');
$users->session_lifetime;
$users->password_min_length;
$users->allowed_roles;        / array

Innerhalb des Moduls selbst ist die Konvention, dies in einen Setter zu verpacken:

class Users extends ModuleAdapter implements IModule
{
    const CONFIG_MODULE_NAME = 'users';
    protected static \stdClass $usersRegistry;

    protected function setUsersRegistry(): void {
        self::$usersRegistry = Registry::getInstance()
            ->loadModuleConfigByName(self::CONFIG_MODULE_NAME);
    }

    public static function lifetime(): int {
        return (int) self::$usersRegistry->session_lifetime;
    }
}

Warum Großbuchstaben in Abschnittsnamen verwendet werden?

INI-Abschnittsnamen werden üblicherweise in Großbuchstaben geschrieben, um sie optisch zu trennen. Der Registrierungsmechanismus setzt dies voraus, daher sucht ein Modul namens cms nach [CMS]. Verwenden Sie immer Großbuchstaben.

Multi-INI pro Modul

Nichts hindert Sie daran, mehr als eine INI-Datei im Modulordner settings/ zu haben. Der Registrierungsmechanismus analysiert alle Dateien und fügt alles zusammen, was mit [<MODULE>] übereinstimmt, in das gleiche \stdClass. Nützlich für die Aufteilung von Verantwortlichkeiten:

application/module/users/settings/
├── users.ini              # [USERS] base config
├── users.smtp.ini         # [USERS] mail-related keys
└── users.production.ini   # production override

Wann der Registry gegenüber der Config verwendet werden sollte

	Config	Registry
Quelle	settings.<env>.ini (eine Datei)	pro-Modul INIs (mehrere Dateien)
Umfang	app-weit, Framework-Konfiguration	Modulspezifische Konfiguration
Abschnitte	gemischt (DATABASE, SETTINGS, ENGINE…)	ein pro Modul
Suche	Config::getInstance()->getConfig()['DATABASE']['driver']	Registry::getInstance()->loadModuleConfigByName('users')

Ein Modul, das den [DATABASE] Treiber lesen muss, greift auf Config zu. Ein Modul, das seine eigene [USERS] session_lifetime liest, greift auf Registry zu.

Auflistung aller geladenen Module

$registry = \Nibiru\Registry::getInstance();
foreach ($registry->getModuleNames() as $name) {
    $cfg = $registry->loadModuleConfigByName($name);
    echo "$name → " . print_r($cfg, true) . "\n";
}

Nützlich in einem Debug-Controller oder einer Admin-Dashboard.

Neuladen-Semantik

Wie Config ist das Registry ein Singleton, das einmal pro Anfrage aufgefüllt wird. Wenn Sie eine INI-Datei eines Moduls ändern, müssen Sie die Anfrage aktualisieren, um die neuen Werte zu sehen. Es gibt eine destroy()-Methode im Singleton-Registry, falls Sie wirklich während der Anfrage neu laden müssen, aber in den normalen Flows wird dies nicht passieren.

Häufige Fallen

• Abschnittsnamen stimmen nicht mit dem Modulordner überein. Ordner users/, erwarteter Abschnitt [USERS]. Nicht übereinstimmend → leere Konfiguration.
• INI-Dateierweiterung. Nur *.ini wird verarbeitet. Eine *.conf oder *.config-Datei wird ignoriert.
• Umgebungsdatei schattet Basisedatei stumm. Wenn users.production.ini mit [USERS] existiert, schattet sie users.ini vollständig – nicht zusammengeführt. Behalten Sie beide Dateien synchron oder verwenden Sie eine + ein Overlay.