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:
apps/${application}/config/unavailable.php,config/unavailable.php,web/errors/unavailable.php,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.ymlyapp.yml ${application}Configuration::initialize()
- Se crea la instancia de
sfContext