Registro

El Registro es la caché de configuración de módulos de Nibiru. Al arrancar, recorre cada directorio bajo application/module/, analiza cada archivo settings/*.ini de los módulos y expone la configuración analizada a través de un único acceso. Piensa en ello como el centro gravitatorio que mantiene a los módulos en órbita unos alrededor de otros.

Cómo funciona la descubrimiento

Para cada módulo bajo application/module/<nombre>/settings/:

1. El Registro itera archivos que coinciden con *.ini.
2. Para cada uno, intenta primero el nombre de archivo específico del entorno (<base>.<env>.<ext>, por ejemplo, users.production.ini); si no, cae en el nombre base (users.ini).
3. Llama a parse_ini_file($path, true) (multi-sección).
4. Busca una sección nombrada después del módulo, en mayúsculas — [USERS], [CMS], [ANALYTICS].
5. Los pares clave/valor analizados se convierten en un \stdClass indexado por el nombre del módulo.

Leyendo la configuración de un módulo

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

Dentro del módulo mismo, la convención es envolver esto en un setter:

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;
    }
}

¿Por qué los nombres de secciones en mayúsculas?

Los nombres de secciones INI suelen escribirse en mayúsculas para hacerlos visualmente distintos. El Registro asume esto, por lo que un módulo llamado cms busca [CMS]. Siempre use mayúsculas.

Multi-INI por módulo

Nada te impide tener más de un archivo INI en la carpeta settings/ de un módulo. El Registro los analiza todos y fusiona todo lo que coincida con [<MÓDULO>] en el mismo \stdClass. Útil para dividir las responsabilidades:

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

Cuándo usar el Registro frente a la Configuración

	Config	Registry
Fuente	settings.<env>.ini (un archivo)	INIs por módulo (muchos archivos)
Alcance	configuración de marco a nivel de aplicación	configuración específica del módulo
Secciones	mixtas (DATABASE, SETTINGS, ENGINE…)	una por módulo
Búsqueda	Config::getInstance()->getConfig()['DATABASE']['driver']	Registry::getInstance()->loadModuleConfigByName('users')

Un módulo que necesita leer el controlador [DATABASE] se dirige a Config. Un módulo que necesita leer su propia [USERS] session_lifetime se dirige a Registry.

Listando todos los módulos cargados

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

Útil en un controlador de depuración o un panel de administración.

Semántica de recarga

Como Config, el Registro es un singleton que se pobla una vez por solicitud. Si cambias la INI de un módulo, necesitas refrescar la solicitud para ver los nuevos valores. Hay un método destroy() en el singleton del Registro si realmente necesitas recargar a mitad de solicitud, pero en flujos normales no lo harás.

Trucos comunes

• El nombre de la sección no coincide con la carpeta del módulo. Carpeta users/, se esperaba la sección [USERS]. Mismatch → configuración vacía.
• Extensión de archivo INI. Solo se analiza *.ini. Un archivo *.conf o *.config es ignorado.
• El archivo de entorno anula silenciosamente el archivo base. Si existe users.production.ini con [USERS], lo oculta completamente a users.ini — no se fusionan. Mantenga ambos archivos sincronizados, o utilice uno más un superponer.