Jeroen Keppens está escribiendo en su blog una serie de artículos muy muy interesantes acerca de cómo implementar módulos autocontenidos empleando Zend Framework. Esta estrategia es increíblemente potente ya que, al ser módulos autocontenidos, podremos copiarlos directamente a un proyecto nuevo y ya funcionarán. Si se programan de forma suficientemente versátil, se podrán encajar entre sí como piezas de un lego que dan forma a la aplicación final. ¿No es genial? :)

En el primero de ellos nos muestra cómo crear el esqueleto de un módulo. Los pasos básicos a seguir son:

  1. zf create project .
  2. zf create module nombremodulo
  3. zf create controller index 1 nombremodulo
    1. Bug – Renombrar el nombre de la clase del controlador añadiendo el prefijo Nombremodulo_.
  4. Añadir configuración de módulos en application.ini:
    resources.frontController.moduleDirectory = APPLICATION_PATH “/modules”
    resources.modules[] =

Básicamente con eso ya lo tenemos, accesible en el path relativo /nombremodulo. ¡Ha sido sencillo!

Por supuesto cada módulo se comporta como una mini-aplicación, por lo que podremos completarlo con su propio fichero Bootstrap.php. Nota: A mi me surgió la duda de cómo poder asegurarse de que un determinado método del Bootstrap principal se ha ejecutado (Por ejemplo, el resource db). Nada más tenemos que llamar a $this->getApplication() y obtendremos el Bootstrap principal. ¿Y esto por qué? Porque al estar contextualizados dentro de un módulo, no obtenemos el objeto Application como cabría esperar, sino el Bootstrap.

Llevado por la emoción, y teniendo en cuenta varios proyectos que tengo pendientes, me puse manos a la obra a programar mi primer módulo autocontenido: Usuarios. Será un módulo muy configurable que permita manejar sesiones, mostrar captchas, registro libre de usuarios o sólo por parte del administrador, acl, facebook connect, y más. Cuando tenga algo presentable lo liberaré :)

El caso, necesitaba que mi módulo fuera configurable. Por ejemplo, ¿se muestran captchas para hacer login? ¿Tras cuantos intentos fallidos? ¿Y qué tipo de captcha? ¿Dónde se almacenan los usuarios? ¿Y en qué campos? Para resolver eso necesitaba de un fichero de configuración. En lugar de tratar de que el propio módulo ejecute sus propios resources en su Bootstrap, opté por la solución fácil: Cargar a mano el fichero de configuración, y revisar sus opciones.

Pero de nuevo Jeroen Keppens ha dado en el clavo proponiendo la solución pro. En su segundo artículo sugiere un ingenioso y completo método para manejar configuraciones a nivel de módulo. No implementa aun manejo de errores, pues se trata de una pre-beta, pero ilustra a la perfección cómo solucionarlo.

Sólo le veo una pega a las soluciones que propone: Dependen en gran parte de su biblioteca extendida, es decir, es necesario tener accesibles a nivel de aplicación numerosas clases desarrolladas por él. Por supuesto, siempre hay una segunda opinión, y en mi caso ubico dichas bibliotecas en /modules/modulename/library/, pese a que en un futuro eso suponga ficheros repetidos. ¿No se trataba de tener módulos autocontenidos? ;)