A veces no es bueno quedarse pegado con un objetivo, pudiendo romper otro más rápidamente.

Entre ayer y hoy, logré romper el segundo objetivo del Roadmap inicial de Gonium, consistente en crear la arquitectura modular para el Backend administrativo.

Ahora, la aplicación cuenta con 2 sistemas modulares independientes, uno para el Frontend (el sitio visible para todo usuario) y otro para el Backend (donde solo usuarios con privilegios pueden modificar cosas).

Esto significa, por ejemplo, que el módulo «user» que puede ver un usuario corriente (donde podrá modificar su perfil y esas cosas), será distinto del módulo «user» del administrador (donde se podrá crear/borrar/modificar cuantas usuarios).

Para dejarlo plenamente funcional, aún falta crear los módulos administrativos (así como los de usuario corriente), pero al menos, la arquitectura de directorios y bootstraping ya están adaptados para trabajar de esta manera.

Implementación

La técnica utilizada, consistió de los siguientes pasos:

Separar el bootstrap de Frontend del boostrap del Backend

Se creo un admin.php en el public_html, al mismo nivel de index.php, el cual carga el Core/boostrap.php pero cambiando el Environment a ‘Admin’.

Esto significó modificar las reglas de .htaccess para redirigir las peticiones que pasaran por la url admin/ a admin.php

Crear clases «inicializadoras» para cada Environment distinto

Esto debido a que ciertos plugins básicos y configuraciones especificas del Frontend no tienen sentido en el Backend (y los futuros de Backend no tienen sentido en el Frontend).

Cambiar la estructura de directorios

Casi vuelvo a dejar la embarrá con la copia de trabajo, pero finalmente lo salvé. Se tuvo que armar una nueva arquitectura de directorios para alojar los módulos administrativos. Aprovechando eso, también se movieron los módulos básico del Frontend y el controlador de errores, los 3 ahora son subcarpetas de /application/Core/Module. Esto fue pensado debido a que las clases controladoras son las única que no respetan el codding-standar de usar prefijos por cada carpeta, para separarlas como si fueran distintos namespaces. No lo necesitan tampoco, porque estas clases jamás se deberían cargar como librerías (al estilo de Zend_Loader).

Separar el controlador de errores del Frontend

Ya tenía implementado un controlador de errors, que despliega por pantalla cualquier Exception disparada durante el proceso del dispatcher. El problema es que este controlador estaba sujeto al módulo «default» del frontend, por lo tanto, no se podía usar desde el backend directamente. Se resolvió separar este controlador de ambos directorios, dejandolo independiente, y siendo este agragado al «Front Controller». como una carpeta independiente. Este controlador DEBE estar disponible en todos los ‘Environments’.

Agregar un enrutador especial para el Backend

Había estado trabajando con un enrutador corriente como lo es el Zend_Controller_Router_Route con una regla sencilla. Pero no me percaté que el enrutador predeterminado, usaba internamente (y por defecto) un enrutador llamado Zend_Controller_Router_Route_Module. Cambiandolo a ese, logré crear un enrutador 'admin' que funciona bien en la estructura modular separada del backend.

Pensé que sería más sencillo… D:

No me quedo otra que hacerlo por esta vía, ya que las rutas se resuelven en tiempo de «dispatching», por ende no puedo configurarlas despues que la aplicación ya empieza a correr.

Si alguien conoce alguna solución más limpia, favor de comunicarse conmigo, sino pruebenlo, ya hice el respectivo commit al repositorio del proyecto.