Ver índice de contenidos del libro

10.1. El inicio

Todo empieza en el controlador de tu aplicación. Supongamos que tienes un controlador llamado frontend y un entorno llamado dev (algo muy común al empezar a desarrollar un proyecto Symfony). En este caso, tu controlador frontal se encuentra en el archivo web/frontend_dev.php. ¿Qué es exactamente lo que sucede en este archivo? En unas pocas líneas de código Symfony obtiene la configuración de la aplicación y crea una instancia de sfContext, que es el encargado de despachar la petición. La configuración de la aplicación es necesaria cuando se crea el objeto sfContext, que es el motor que hace funcionar a Symfony y que depende de la aplicación.

Nota Symfony concede al programador cierto control en este punto ya que permite pasar como cuarto argumento de ProjectConfiguration::getApplicationConfiguration() un directorio raíz propio para la aplicación, así como una clase de contexto propia como tercer (y último) argumento de sfContext::createInstance() (pero recuerda que debe heredar de sfContext).

Obtener la configuración de la aplicación es un paso muy importante. En primer lugar, sfProjectConfiguration se encarga de adivinar la clase de configuración de la aplicación, normalmente llamada ${application}Configuration y guardada en el archivo apps/${application}/config/${application}Configuration.class.php.

La clase sfApplicationConfiguration hereda de ProjectConfiguration, por lo que cualquier método de ProjectConfiguration está disponible en todas las aplicaciones del proyecto. Esto también significa que sfApplicationConfiguration comparte su constructor tanto con ProjectConfiguration como con sfProjectConfiguration. Esto es una gran ventaja porque muchos aspectos del proyecto se configuran en el constructor de sfProjectConfiguration. Su primera tarea es calcular y guardar varios valores útiles, como el directorio raíz del proyecto y el directorio de la librería de Symfony. sfProjectConfiguration también crea un despachador de eventos (event dispatcher) de tipo sfEventDispatcher, a menos que se le pase un despachador propio como quinto argumento de ProjectConfiguration::getApplicationConfiguration() en el controlador frontal.

Justo después de esto, tienes la primera oportunidad para interactuar con el proceso de configuración redefiniendo el método setup() de ProjectConfiguration. Este es normalmente el mejor lugar para activar o desactivar plugins mediante sfProjectConfiguration::setPlugins(), sfProjectConfiguration::enablePlugins(), sfProjectConfiguration::disablePlugins() o sfProjectConfiguration::enableAllPluginsExcept()).

A continuación se cargan los plugins mediante sfProjectConfiguration::loadPlugins() y el programador puede interactuar con este proceso redefiniendo el método sfProjectConfiguration::setupPlugins().

La inicialización de los plugins es muy sencilla. Symfony busca para cada plugin una clase llamada ${plugin}Configuration (por ejemplo, sfGuardPluginConfiguration) y si la encuentra, crea una instancia. Si no la encuentra, utiliza la clase genérica sfPluginConfigurationGeneric. Los siguientes dos métodos permiten modificar la configuración de un plugin:

  • ${plugin}Configuration::configure(), antes de que se realice la carga automática de clases
  • ${plugin}Configuration::initialize(), después de la carga automática de clases

Seguidamente sfApplicationConfiguration ejecuta su método configure(), que también se puede utilizar para personalizar la configuración de cada aplicación antes de que comience el proceso de inicialización de la configuración interna en sfApplicationConfiguration::initConfiguration().

Esta parte del proceso de configuración de Symfony se encarga de muchas tareas y tiene varios puntos preparados para que puedas interactuar. Si quieres interactuar por ejemplo con la configuración del cargador automático de clases, puedes conectarte al evento autoload.filter_config. A continuación se cargan varios archivos de configuración muy importantes, incluyendo settings.yml y app.yml. Por último, se ejecuta la última parte de la configuración de los plugins mediante el archivo config/config.php de cada plugin o con el método initialize() de la clase de configuración.

Si la opción sf_check_lock está activada, Symfony busca un archivo de lock (por ejemplo el que crea la tarea project:disable). Si se encuentra el archivo de lock, se comprueban los siguientes archivos y se incluye el primero que se encuentra, además de terminar de forma inmediata el script:

  1. apps/${application}/config/unavailable.php,
  2. config/unavailable.php,
  3. web/errors/unavailable.php,
  4. lib/vendor/symfony/lib/exception/data/unavailable.php,

Finalmente, el programador tiene una última oportunidad para personalizar la inicialización de la aplicación a través del método sfApplicationConfiguration::initialize().

10.1.1. Resumen del inicio y su configuración

  • Se obtiene la configuración de la aplicación
    • ProjectConfiguration::setup() (aquí se definen los plugins)
    • Se cargan los plugins
      • ${plugin}Configuration::configure()
      • ${plugin}Configuration::initialize()
    • ProjectConfiguration::setupPlugins() (aquí se configuran los plugins)
    • ${application}Configuration::configure()
    • Se notifica el evento autoload.filter_config
    • Se cargan settings.yml y app.yml
    • ${application}Configuration::initialize()
  • Se crea la instancia de sfContext