6.1. El Controlador Frontal

Todas las peticiones web son manejadas por un solo controlador frontal, que es el punto de entrada único de toda la aplicación en un entorno determinado.

Cuando el controlador frontal recibe una petición, utiliza el sistema de enrutamiento para asociar el nombre de una acción y el nombre de un módulo con la URL escrita (o pinchada) por el usuario. Por ejemplo, la siguientes URL llama al script index.php (que es el controlador frontal) y será entendido como llamada a la acción miAccion del módulo mimodulo:

http://localhost/index.php/mimodulo/miAccion

Si no estás interesado en los mecanismos internos de Symfony, eso es todo que necesitas saber sobre el controlador frontal. Es un componente imprescindible de la arquitectura MVC de Symfony, pero raramente necesitarás cambiarlo. Si no quieres conocer las tripas del controlador frontal, puedes saltarte el resto de esta sección.

6.1.1. El Trabajo del Controlador Frontal en Detalle

El controlador frontal se encarga de despachar las peticiones, lo que implica algo más que detectar la acción que se ejecuta. De hecho, ejecuta el código común a todas las acciones, incluyendo:

1. Define las constantes del núcleo.
2. Localiza la librería de Symfony
3. Carga e inicializa las clases del núcleo del framework.
4. Carga la configuración.
5. Decodifica la URL de la petición para determinar la acción a ejecutar y los parámetros de la petición.
6. Si la acción no existe, redireccionará a la acción del error 404.
7. Activa los filtros (por ejemplo, si la petición necesita autenticación).
8. Ejecuta los filtros, primera pasada.
9. Ejecuta la acción y produce la vista.
10. Ejecuta los filtros, segunda pasada.
11. Muestra la respuesta.

6.1.2. El Controlador Frontal por defecto

El controlador frontal por defecto, llamado index.php y ubicado en el directorio web/ del proyecto, es un simple script, como lo muestra el Listado 6-1.

Listado 6-1 - El Controlador Frontal por Omisión

<?php

define('SF_ROOT_DIR',    realpath(dirname(__FILE__).'/..'));
define('SF_APP',         'miaplicacion');
define('SF_ENVIRONMENT', 'prod');
define('SF_DEBUG',       false);

    require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');

sfContext::getInstance()->getController()->dispatch();

La definición de las constantes corresponde al primer paso descrito en la sección anterior. Después el controlador frontal incluye el config.php de la aplicación, que se ocupa de los pasos 2 a 4. La llamada al método dispatch() del objeto sfController (que es el objeto correspondiente al controlador del núcleo de la arquitectura MVC de Symfony) envía la petición, ocupándose de los pasos 5 a 7. Los últimos pasos son manejados por la cadena de filtros, según lo explicado más adelante este capítulo.

6.1.3. Llamando a Otro Controlador Frontal para Cambiar el Entorno

Cada entorno dispone de un controlador frontal. De hecho, es la existencia del controlador frontal lo que define un entorno. El entorno se define en la constante SF_ENVIRONMENT.

Para cambiar el entorno en el que se está viendo la aplicación, simplemente se elige otro controlador frontal. Los controladores frontales disponibles cuando creas una aplicación con la tarea symfony init-app son index.php para el entorno de producción y miaplicacion_dev.php para el entorno de desarrollo (suponiendo que tu aplicación se llame miaplicacion). La configuración por defecto de mod_rewrite utiliza index.php cuando la URL no contiene el nombre de un script correspondiente a un controlador frontal. Así que estas dos URL muestran la misma página (mimodulo/index) en el entorno de producción:

http://localhost/index.php/mimodulo/index
http://localhost/mimodulo/index

y esta URL muestra la misma página en el entorno de desarrollo:

http://localhost/miaplicacion_dev.php/mimodulo/index

Crear un nuevo entorno es tan fácil como crear un nuevo controlador frontal. Por ejemplo, puede ser necesario un entorno llamado staging que permita a tus clientes probar la aplicación antes de ir a producción. Para crear el entorno staging, simplemente copia web/miaplicacion_dev.php en web/miaplicacion_staging.php y cambia el valor de la constante SF_ENVIRONMENT a staging. Ahora en todos los archivos de configuración, puedes añadir una nueva sección staging: para establecer los valores específicos para este entorno, como se muestra en el Listado 6-2

Listado 6-2 - Ejemplo de app.yml con valores específicos para el entorno staging

staging:
  mail:
    webmaster:    [email protected]
    contacto:     [email protected]
all:
  mail:
    webmaster:    [email protected]
    contacto:     [email protected]

Si quieres ver cómo se comporta la aplicación en el nuevo entorno, utiliza el nuevo controlador frontal:

http://localhost/miaplicacion_staging.php/mimodulo/index

6.1.4. Archivos por Lotes

En ocasiones es necesario ejecutar un script desde la línea de comandos (o mediante una tarea programada) con acceso a todas las clases y características de Symfony, por ejemplo para realizar tareas como el envío programado de correos electrónicos o para actualizar periódicamente el modelo mediante una serie de cálculos complejos. Para este tipo de scripts, es necesario incluir al principio del archivo por lotes las mismas líneas que en el controlador frontal. El listado 6-3 muestra el principio de un archivo por lotes de este tipo.

Listado 6-3 - Ejemplo de archivo por lotes

<?php

define('SF_ROOT_DIR',    realpath(dirname(__FILE__).'/..'));
define('SF_APP',         'miaplicacion');
define('SF_ENVIRONMENT', 'prod');
define('SF_DEBUG',       false);

    require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');

// Agregar código aquí

Puedes ver que la única línea que falta es la que llama al método dispatch() del objeto sfController, que solo puede ser utilizada con un navegador web, no en un proceso por lotes. Definir una aplicación y un entorno te permite disponer de una configuración específica. Incluir el archivo config.php inicializa el contexto y el cargado automático de las clases.