Symfony 1.2 La guía definitiva

¿Qué puedes hacer con Symfony? ¿Qué necesitas para utilizarlo? Este capítulo responde a todas estas preguntas.

Un framework simplifica el desarrollo de una aplicación mediante la automatización de algunos de los patrones utilizados para resolver las tareas comunes. Además, un framework proporciona estructura al código fuente, forzando al desarrollador a crear código más legible y más fácil de mantener. Por último, un framework facilita la programación de aplicaciones, ya que encapsula operaciones complejas en instrucciones sencillas.

Symfony es un completo framework diseñado para optimizar, gracias a sus características, el desarrollo de las aplicaciones web. Para empezar, separa la lógica de negocio, la lógica de servidor y la presentación de la aplicación web. Proporciona varias herramientas y clases encaminadas a reducir el tiempo de desarrollo de una aplicación web compleja. Además, automatiza las tareas más comunes, permitiendo al desarrollador dedicarse por completo a los aspectos específicos de cada aplicación. El resultado de todas estas ventajas es que no se debe reinventar la rueda cada vez que se crea una nueva aplicación web.

Symfony está desarrollado completamente con PHP 5. Ha sido probado en numerosos proyectos reales y se utiliza en sitios web de comercio electrónico de primer nivel. Symfony es compatible con la mayoría de gestores de bases de datos, como MySQL, PostgreSQL, Oracle y SQL Server de Microsoft. Se puede ejecutar tanto en plataformas *nix (Unix, Linux, etc.) como en plataformas Windows. A continuación se muestran algunas de sus características.

Symfony se diseñó para que se ajustara a los siguientes requisitos:

• Fácil de instalar y configurar en la mayoría de plataformas (y con la garantía de que funciona correctamente en los sistemas Windows y *nix estándares)
• Independiente del sistema gestor de bases de datos
• Sencillo de usar en la mayoría de casos, pero lo suficientemente flexible como para adaptarse a los casos más complejos
• Basado en la premisa de "convenir en vez de configurar", en la que el desarrollador solo debe configurar aquello que no es convencional
• Sigue la mayoría de mejores prácticas y patrones de diseño para la web
• Preparado para aplicaciones empresariales y adaptable a las políticas y arquitecturas propias de cada empresa, además de ser lo suficientemente estable como para desarrollar aplicaciones a largo plazo
• Código fácil de leer que incluye comentarios de phpDocumentor y que permite un mantenimiento muy sencillo
• Fácil de extender, lo que permite su integración con librerías desarrolladas por terceros

Symfony automatiza la mayoría de elementos comunes de los proyectos web, como por ejemplo:

• La capa de internacionalización que incluye Symfony permite la traducción de los datos y de la interfaz, así como la adaptación local de los contenidos.
• La capa de presentación utiliza plantillas y layouts que pueden ser creados por diseñadores HTML sin ningún tipo de conocimiento del framework. Los helpers incluidos permiten minimizar el código utilizado en la presentación, ya que encapsulan grandes bloques de código en llamadas simples a funciones.
• Los formularios incluyen validación automatizada y relleno automático de datos ("repopulation"), lo que asegura la obtención de datos correctos y mejora la experiencia de usuario.
• Los datos incluyen mecanismos de escape que permiten una mejor protección contra los ataques producidos por datos corruptos.
• La gestión de la caché reduce el ancho de banda utilizado y la carga del servidor.
• La autenticación y la gestión de credenciales simplifican la creación de secciones restringidas y la gestión de la seguridad de usuario.
• El sistema de enrutamiento y las URL limpias permiten considerar a las direcciones de las páginas como parte de la interfaz, además de estar optimizadas para los buscadores.
• El soporte de e-mail incluido y la gestión de APIs permiten a las aplicaciones web interactuar más allá de los navegadores.
• Los listados son más fáciles de utilizar debido a la paginación automatizada, el filtrado y la ordenación de datos.
• Los plugins, las factorías (patrón de diseño "Factory") y los "mixin" permiten realizar extensiones a medida de Symfony.
• Las interacciones con Ajax son muy fáciles de implementar mediante los helpers que permiten encapsular los efectos JavaScript compatibles con todos los navegadores en una única línea de código.

Symfony puede ser completamente personalizado para cumplir con los requisitos de las empresas que disponen de sus propias políticas y reglas para la gestión de proyectos y la programación de aplicaciones. Por defecto incorpora varios entornos de desarrollo diferentes e incluye varias herramientas que permiten automatizar las tareas más comunes de la ingeniería del software:

• Las herramientas que generan automáticamente código han sido diseñadas para hacer prototipos de aplicaciones y para crear fácilmente la parte de gestión de las aplicaciones.
• El framework de desarrollo de pruebas unitarias y funcionales proporciona las herramientas ideales para el desarrollo basado en pruebas ("test-driven development").
• La barra de depuración web simplifica la depuración de las aplicaciones, ya que muestra toda la información que los programadores necesitan sobre la página en la que están trabajando.
• La interfaz de línea de comandos automatiza la instalación de las aplicaciones entre servidores.
• Es posible realizar cambios "en caliente" de la configuración (sin necesidad de reiniciar el servidor).
• El completo sistema de log permite a los administradores acceder hasta el último detalle de las actividades que realiza la aplicación.

La primera versión de Symfony fue publicada en Octubre de 2005 por Fabien Potencier, fundador del proyecto y coautor de este libro. Fabien es el presidente de Sensio (http://www.sensio.com/), una empresa francesa de desarrollo de aplicaciones web conocida por sus innovaciones en este campo.

En el año 2003, Fabien realizó una investigación sobre las herramientas de software libre disponibles para el desarrollo de aplicaciones web con PHP. Fabien llegó a la conclusión de que no existía ninguna herramienta con esas características. Después del lanzamiento de la versión 5 de PHP, decidió que las herramientas disponibles habían alcanzado un grado de madurez suficiente como para integrarlas en un framework completo. Fabien empleó un año entero para desarrollar el núcleo de Symfony, basando su trabajo en el framework Mojavi (que también era un framework que seguía el funcionamiento MVC), en la herramienta Propel para el mapeo de objetos a bases de datos (conocido como ORM, de "object-relational mapping") y en los helpers empleados por Ruby on Rails en sus plantillas.

Fabien desarrolló originalmente Symfony para utilizarlo en los proyectos de Sensio, ya que disponer de un framework efectivo es la mejor ayuda para el desarrollo eficiente y rápido de las aplicaciones. Además, el desarrollo web se hace más intuitivo y las aplicaciones resultantes son más robustas y más fáciles de mantener. El framework se utilizó por primera vez en el desarrollo de un sitio de comercio electrónico para un vendedor de lencería y posteriormente se utilizó en otros proyectos.

Después de utilizar Symfony en algunos proyectos, Fabien decidió publicarlo bajo una licencia de software libre. Sus razones para liberar el proyecto fueron para donar su trabajo a la comunidad, aprovechar la respuesta de los usuarios, mostrar la experiencia de Sensio y porque considera que es divertido hacerlo.

Para que Symfony fuera un proyecto de software libre exitoso, debía tener una documentación amplia y en inglés, para aumentar la incorporación de usuarios al proyecto. Fabien pidió a su compañero de trabajo François Zaninotto, el otro coautor de este libro, que investigara el código fuente del programa y escribiera un libro sobre Symfony. Aunque el proceso fue arduo, cuando el proyecto se lanzó públicamente, la documentación era suficiente como para atraer a muchos desarrolladores. El resto es historia.

En cuanto se abrió al público el sitio web de Symfony (http://www.symfony-project.org/) muchos desarrolladores de todo el mundo se descargaron e instalaron el framework, comenzaron a leer la documentación y construyeron sus primeras aplicaciones con Symfony, aumentando poco a poco la popularidad de Symfony.

En ese momento, los frameworks para el desarrollo de aplicaciones web estaban en pleno apogeo, y era muy necesario disponer de un completo framework realizado con PHP. Symfony proporcionaba una solución irresistible a esa carencia, debido a la calidad de su código fuente y a la gran cantidad de documentación disponible, dos ventajas muy importantes sobre otros frameworks disponibles. Los colaboradores aparecieron en seguida proponiendo parches y mejoras, detectando los errores de la documentación y realizando otras tareas muy importantes.

El repositorio público de código fuente y el sistema de notificación de errores y mejoras mediante tickets permite varias formas de contribuir al proyecto y todos los voluntarios son bienvenidos. Fabien continua siendo el mayor contribuidor de código al repositorio y se encarga de garantizar la calidad del código.

Actualmente, el foro de Symfony, las listas de correo y el IRC ofrecen otras alternativas válidas para el soporte del framework, con el que cada pregunta suele obtener una media de 4 respuestas. Cada día nuevos usuarios instalan Symfony y el wiki y la sección de fragmentos de código almacenan una gran cantidad de documentación generada por los usuarios. Cada semana el número de aplicaciones conocidas desarrolladas con Symfony se incrementa en 5 y el aumento continua.

La comunidad Symfony es el tercer pilar del framework y esperamos que tu también te unas a ella después de leer este libro.

Independientemente de que seas un experto programador de PHP 5 o un principiante en el desarrollo de aplicaciones web, podrás utilizar Symfony de forma sencilla. El principal argumento para decidir si deberías o no utilizar Symfony es el tamaño del proyecto.

Si tu proyecto consiste en desarrollar un sitio web sencillo con 5 o 10 páginas diferentes, acceso simple a bases de datos y no es importante asegurar un gran rendimiento o una documentación adecuada, deberías realizar tu proyecto solo con PHP. En ese caso, no vas a obtener grandes ventajas por utilizar un framework de desarrollo de aplicaciones web, además de que utilizar objetos y el modelo MVC (Modelo Vista Controlador) solamente va a ralentizar el desarrollo de tu proyecto. Además, Symfony no está optimizado para ejecutarse de forma eficiente en un servidor compartido en el que los scripts de PHP se ejecutan solamente mediante CGI (Common Gateway Interface).

Por otra parte, si desarrollas aplicaciones web complejas con mucha lógica de negocio, no es recomendable utilizar solo PHP. Para asegurar el mantenimiento y las ampliaciones futuras de la aplicación, es necesario que el código sea ligero, legible y efectivo. Si quieres incorporar los últimos avances en interacción con usuarios (como por ejemplo Ajax), puedes acabar escribiendo cientos de líneas de JavaScript. Si quieres desarrollar aplicaciones de forma divertida y muy rápida, no es aconsejable utilizar solo PHP. En todos estos casos, deberías utilizar Symfony.

Si eres un desarrollador web profesional, ya conoces todas las ventajas de utilizar un framework de desarrollo de aplicaciones web y solo necesitas un framework que sea maduro, bien documentado y con una gran comunidad que lo apoye. En este caso, deberías dejar de buscar porque Symfony es lo que necesitas.

Antes de empezar con Symfony, deberías conocer algunos conceptos básicos. Puedes saltarte esta sección si conoces el significado de OOP, ORM, RAD, DRY, KISS, TDD, YAML y PEAR.

Symfony está programado en PHP 5 (http://www.php.net/) y está enfocado al desarrollo de aplicaciones web en el mismo lenguaje de programación. Por este motivo, es obligatorio disponer de unos conocimientos avanzados de PHP 5 para sacar el máximo partido al framework. La versión mínima de PHP requerida para ejecutar Symfony es PHP 5.2.

Los programadores que conocen PHP 4 pero que no han trabajado con PHP 5 deberían centrarse en el nuevo modelo orientado a objetos de PHP.

La programación orientada a objetos (OOP, por sus siglas en inglés Object-oriented programming) no va a ser explicada en este capítulo, ya que se necesitaría un libro entero para ello. Como Symfony hace un uso continuo de los mecanismos orientados a objetos disponibles en PHP 5, es un requisito obligatorio el conocer la OOP antes de aprender Symfony.

En la Wikipedia se explica la OOP de la siguiente manera:

La idea de la programación orientada a objetos es que una aplicación se puede considerar como una colección de unidades individuales, llamadas objetos, que interactúan entre sí. Los programas tradicionales pueden considerarse como una colección de funciones o como una lista de instrucciones de programación.

PHP 5 incluye los conceptos de clase, objeto, método, herencia y muchos otros propios de la programación orientada a objetos. Aquellos que no estén familiarizados con estos conceptos, deberían consultar la documentación oficial de PHP disponible en http://www.php.net/manual/es/language.oop5.basic.php.

Uno de los puntos fuertes de los objetos de PHP es la utilización de los "métodos mágicos". Este tipo de métodos permiten redefinir el comportamiento de las clases sin modificar el código externo. Con estos métodos es posible que la sintaxis de PHP sea más concisa y más fácil de extender. Además, estos métodos son fáciles de reconocer ya que sus nombres siempre empiezan con 2 guiones bajos seguidos (__).

Por ejemplo, al mostrar un objeto, PHP busca de forma implícita un método llamado __toString() en ese objeto y que permite comprobar si se ha creado una visualización personalizada para ese objeto:

$miObjeto = new miClase();

echo $miObjeto;
 
// Se busca el método mágico
echo $miObjeto->__toString();

Symfony utiliza los métodos mágicos de PHP, por lo que deberías conocer su funcionamiento. La documentación oficial de PHP también explica los métodos mágicos (http://www.php.net/manual/es/language.oop5.magic.php)

PEAR es un "framework y sistema de distribución para componentes PHP reutilizables". PEAR permite descargar, instalar, actualizar y desinstalar scripts de PHP. Si se utiliza un paquete de PEAR, no es necesario decidir donde guardar los scripts, cómo hacer que se puedan utilizar o cómo extender la línea de comandos (CLI).

PEAR es un proyecto creado por la comunidad de usuarios de PHP, está desarrollado con PHP y se incluye en las distribuciones estándar de PHP.

PEAR es el método más profesional para instalar librerías externas en PHP. Symfony aconseja el uso de PEAR para disponer de una instalación única y centralizada que pueda ser utilizada en varios proyectos. Los plugins de Symfony son paquetes de PEAR con una configuración especial. El propio framework Symfony también está disponible como paquete de PEAR.

Afortunadamente, no es necesario conocer la sintaxis de PEAR para utilizar Symfony. Lo único necesario es entender su funcionamiento y tenerlo instalado. Para comprobar si PEAR está instalado en el sistema, se puede escribir lo siguiente en una línea de comandos:

> pear info pear

El comando anterior muestra la versión de PEAR instalada en el sistema.

El proyecto Symfony dispone de su propio repositorio PEAR, también llamado canal. Los canales de PEAR solamente se pueden utilizar a partir de la versión 1.4.0, por lo que es necesario actualizar PEAR si se dispone de una versión anterior. Para actualizar PEAR, se debe ejecutar el siguiente comando:

> pear upgrade PEAR

Las bases de datos siguen una estructura relacional. PHP 5 y Symfony por el contrario son orientados a objetos. Por este motivo, para acceder a la base de datos como si fuera orientada a objetos, es necesario una interfaz que traduzca la lógica de los objetos a la lógica relacional. Esta interfaz se denomina "mapeo de objetos a bases de datos" (ORM, de sus siglas en inglés "object-relational mapping").

Un ORM consiste en una serie de objetos que permiten acceder a los datos y que contienen en su interior cierta lógica de negocio.

Una de las ventajas de utilizar estas capas de abstracción de objetos/relacional es que evita utilizar una sintaxis específica de un sistema de bases de datos concreto. Esta capa transforma automáticamente las llamadas a los objetos en consultas SQL optimizadas para el sistema gestor de bases de datos que se está utilizando en cada momento.

De esta forma, es muy sencillo cambiar a otro sistema de bases de datos completamente diferente en mitad del desarrollo de un proyecto. Estas técnicas son útiles por ejemplo cuando se debe desarrollar un prototipo rápido de una aplicación y el cliente aun no ha decidido el sistema de bases de datos que más le conviene. El prototipo se puede realizar utilizando SQLite y después se puede cambiar fácilmente a MySQL, PostgreSQL u Oracle cuando el cliente se haya decidido. El cambio se puede realizar modificando solamente una línea en un archivo de configuración.

La capa de abstracción utilizada encapsula toda la lógica de los datos. El resto de la aplicación no tiene que preocuparse por las consultas SQL y el código SQL que se encarga del acceso a la base de datos es fácil de encontrar. Los desarrolladores especializados en la programación con bases de datos pueden localizar fácilmente el código.

Utilizar objetos en vez de registros y clases en vez de tablas tiene otra ventaja: se pueden definir nuevos métodos de acceso a las tablas. Por ejemplo, si se dispone de una tabla llamada Cliente con 2 campos, Nombre y Apellido, puede que sea necesario acceder directamente al nombre completo (NombreCompleto). Con la programación orientada a objetos, este problema se resuelve añadiendo un nuevo método de acceso a la clase Cliente de la siguiente forma:

public function getNombreCompleto()
{
  return $this->getNombre().' '.$this->getApellido();

}

Todas las funciones comunes de acceso a los datos y toda la lógica de negocio relacionada con los datos se puede mantener dentro de ese tipo de objetos. Por ejemplo, la siguiente clase CarritoCompra almacena los productos (que son objetos). Para obtener el precio total de los productos del carrito y así realizar el pago, se puede añadir un método llamado getTotal() de la siguiente forma:

public function getTotal()

{
  $total = 0;
  foreach ($this->getProductos() as $producto)

  {
    $total += $producto->getPrecio() * $item->getCantidad();
  }

  return $total;
}

Y eso es todo. Imagina cuanto te hubiera costado escribir una consulta SQL que hiciera lo mismo.

Propel, que también es un proyecto de software libre, es una de las mejores capas de abstracción de objetos/relacional disponibles en PHP 5. Propel está completamente integrado en Symfony e incluso es su ORM por defecto, por lo que la mayoría de las manipulaciones de datos realizadas en este libro siguen la sintaxis de Propel. En el libro se describe la utilización de los objetos de Propel, pero se puede encontrar una referencia más completa en el sitio web de Propel (http://propel.phpdb.org/trac/).

Durante mucho tiempo, la programación de aplicaciones web fue un tarea tediosa y muy lenta. Siguiendo los ciclos habituales de la ingeniería del software (como los propuestos por el Proceso Racional Unificado o Rational Unified Process) el desarrollo de una aplicación web no puede comenzar hasta que se han establecido por escrito una serie de requisitos, se han creado los diagramas UML (Unified Modeling Language) y se ha producido abundante documentación sobre el proyecto. Este modelo se veía favorecido por la baja velocidad de desarrollo, la falta de versatilidad de los lenguajes de programación (antes de ejecutar el programa se debe construir, compilar y reiniciar) y sobre todo por el hecho de que los clientes no estaban dispuestos a adaptarse a otras metodologías.

Hoy en día, las empresas reaccionan más rápidamente y los clientes cambian de opinión constantemente durante el desarrollo de los proyectos. De este modo, los equipos de desarrollo deben adaptarse a esas necesidades y tienen que poder cambiar la estructura de una aplicación de forma rápida. Afortunadamente, el uso de lenguajes de script como Perl y PHP permiten seguir otras estrategias de programación, como RAD (desarrollo rápido de aplicaciones) y el desarrollo ágil de software.

Una de las ideas centrales de esta metodología es que el desarrollo empieza lo antes posible para que el cliente pueda revisar un prototipo que funciona y pueda indicar el camino a seguir. A partir de ahí, la aplicación se desarrolla de forma iterativa, en la que cada nueva versión incorpora nuevas funcionalidades y se desarrolla en un breve espacio de tiempo.

Las consecuencias de estas metodologías para el desarrollador son numerosas. El programador no debe pensar acerca de las versiones futuras al incluir una nueva funcionalidad. Los métodos utilizados deben ser lo más sencillos y directos posibles. Estas ideas se resumen en el principio denominado KISS: ¡Hazlo sencillo, idiota! (Keep It Simple, Stupid)

Cuando se modifican los requisitos o cuando se añade una nueva funcionalidad, normalmente se debe reescribir parte del código existente. Este proceso se llama refactorización y sucede a menudo durante el desarrollo de una aplicación web. El código suele moverse a otros lugares en función de su naturaleza. Los bloques de código repetidos se refactorizan en un único lugar, aplicando el principio DRY: No te repitas (Don't Repeat Yourself).

Para asegurar que la aplicación sigue funcionando correctamente a pesar de los cambios constantes, se necesita una serie de pruebas unitarias que puedan ser automatizadas. Si están bien escritas, las pruebas unitarias permiten asegurar que nada ha dejado de funcionar después de haber refactorizado parte del código de la aplicación. Algunas metodologías de desarrollo de aplicaciones obligan a escribir las pruebas antes que el propio código, lo que se conoce como TDD: desarrollo basado en pruebas (test-driven development).

Symfony es la herramienta ideal para el RAD. De hecho, el framework ha sido desarrollado por una empresa que aplica el RAD a sus propios proyectos. Por este motivo, aprender a utilizar Symfony no es como aprender un nuevo lenguaje de programación, sino que consite en aprender a tomar las decisiones correctas para desarrollar las aplicaciones de forma más efectiva.

Según el sitio web oficial de YAML (http://www.yaml.org/), YAML es "un formato para serializar datos que es fácil de procesar por las máquinas, fácil de leer para las personas y fácil de interactuar con los lenguajes de script". Dicho de otra forma, YAML es un lenguaje muy sencillo que permite describir los datos como en XML, pero con una sintaxis mucho más sencilla. YAML es un formato especialmente útil para describir datos que pueden ser transformados en arrays simples y asociativos, como por ejemplo:

$casa = array(
  'familia' => array(
    'apellido'  => 'García',
    'padres'  => array('Antonio', 'María'),
    'hijos'   => array('Jose', 'Manuel', 'Carmen')

  ),
  'direccion' => array(
    'numero'        => 34,
    'calle'         => 'Gran Vía',
    'ciudad'        => 'Cualquiera',
    'codigopostal'  => '12345'

  )
);

Este array de PHP se puede crear directamente procesando esta cadena de texto en formato YAML:

casa:
  familia:
    apellido: García
    padres:
      - Antonio
      - María
    hijos:
      - Jose
      - Manuel
      - Carmen
  direccion:
    numero: 34

    calle: Gran Vía
    ciudad: Cualquiera
    codigopostal: "12345"

YAML utiliza la tabulación para indicar su estructura, los elementos que forman una secuencia utilizan un guión medio y los pares clave/valor de los array asociativos se separan con dos puntos. YAML también dispone de una notación resumida para describir la misma estructura con menos líneas: los arrays simples se definen con [] y los arrays asociativos se definen con {}. Por tanto, los datos YAML anteriores se pueden escribir de forma abreviada de la siguiente manera:

casa:
  familia: { apellido: García, padres: [Antonio, María], hijos: [Jose, Manuel, Carmen] }

  direccion: { numero: 34, direccion: Gran Vía, ciudad: Cualquiera, codigopostal: "12345" }

YAML es el acrónimo de "YAML Ain't Markup Language" ("YAML No es un Lenguaje de Marcado") y se pronuncia "yamel". El formato se lleva utilizando desde 2001 y existen utilidades para procesar YAML en una gran variedad de lenguajes de programación.

Como se ha visto, YAML es mucho más rápido de escribir que XML (ya que no hacen falta las etiquetas de cierre y el uso continuo de las comillas) y es mucho más poderoso que los tradicionales archivos .ini (ya que estos últimos no soportan la herencia y las estructuras complejas). Por este motivo, Symfony utiliza el formato YAML como el lenguaje preferido para almacenar su configuración. Este libro contiene muchos archivos YAML, pero como es tan sencillo, probablemente no necesites aprender más detalles de este formato.

Symfony es un framework para desarrollar aplicaciones web creado con PHP 5. Añade una nueva capa por encima de PHP y proporciona herramientas que simplifican el desarrollo de las aplicaciones web complejas. Este libro contiene todos los detalles del funcionamiento de Symfony y para entenderlo, solamente es necesario estar familiarizado con los conceptos básicos de la programación moderna, sobre todo la programación orientada a objetos (OOP), el mapeo de objetos a bases de datos (ORM) y el desarrollo rápido de aplicaciones (RAD). El único requisito técnico obligatorio es el conocimiento de PHP 5.

La primera vez que se accede al código fuente de una aplicación realizada con Symfony, puede desanimar un poco a los nuevos desarrolladores. El código está dividido en muchos directorios y muchos scripts y los archivos son un conjunto de clases PHP, código HTML e incluso una mezcla de los dos. Además, existen referencias a clases que no se pueden encontrar dentro del directorio del proyecto y la anidación de directorios puede llegar hasta los seis niveles. Sin embargo, cuando comprendas las razones que están detrás de esta aparente complejidad, lo verás como algo completamente natural y no querrás cambiar la estructura de una aplicación Symfony por ninguna otra. En este capítulo se explica con detalle toda esa estructura.

Como se ha visto en los capítulos anteriores, el framework Symfony está formado por un conjunto de archivos escritos en PHP. Los proyectos realizados con Symfony utilizan estos archivos, por lo que la instalación de Symfony consiste en obtener esos archivos y hacer que estén disponibles para los proyectos.

La versión mínima de PHP requerida para ejecutar Symfony 1.2 es PHP 5.2. Por tanto, es necesario asegurarse de que se encuentra instalado, para lo cual se puede ejecutar el siguiente comando en la línea de comandos del sistema operativo:

> php -v
 
PHP 5.2.5 (cli) (built: Nov 20 2007 16:55:40) 
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

Si el número de la versión que se muestra es 5.2 o superior, ya es posible realizar la instalación de Symfony que se describe en este capítulo.

Si lo único que quieres es comprobar lo que puede dar de sí Symfony, lo mejor es que te decantes por la instalación rápida. En este caso, se utiliza el "entorno de pruebas" o sandbox.

El entorno de pruebas está formado por un conjunto de archivos. Contiene un proyecto vacío de Symfony e incluye todas las librerías necesarias (Symfony, lime, Prototype con Scriptaculous, Doctrine y Propel con Phing), una aplicación de prueba y la configuración básica. No es necesario realizar ninguna configuración en el servidor ni instalar ningún paquete adicional para que funcione correctamente.

Para instalar el entorno de pruebas, se debe descargar su archivo comprimido desde http://www.symfony-project.org/get/sf_sandbox_1_2.tgz. Una vez descargado el archivo, es esencial asegurarse que tiene la extensión .tgz, ya que de otro modo no se descomprimirá correctamente. La extensión .tgz no es muy común en sistemas operativos tipo Windows, pero programas como WinRAR o 7-Zip lo pueden descomprimir sin problemas. A continuación, se descomprime su contenido en el directorio raíz del servidor web, que normalmente es web/ o www/. Para asegurar cierta uniformidad en la documentación, en este capítulo se supone que se ha descomprimido el entorno de pruebas en el directorio sf_sandbox/.

Se puede comprobar si se ha realizado correctamente la instalación del entorno de pruebas mediante los comandos proporcionados por Symfony. Entra en el directorio sf_sandbox/ y ejecuta el siguiente comando:

> php symfony -V

El resultado del comando debería mostrar la versión del entorno de pruebas:

symfony version 1.2.0 (/ruta/hasta/el/directorio/lib/dir/utilizado/por/el/entorno/de/pruebas)

A continuación, se prueba si el servidor web puede acceder al entorno de pruebas mediante la siguiente URL:

http://localhost/sf_sandbox/web/frontend_dev.php/

Si todo ha ido bien, deberías ver una página de bienvenida como la que se muestra en la figura 3-1, con lo que la instalación rápida se puede dar por concluida. Si no se muestra esa página, se mostrará un mensaje de error que te indica los cambios necesarios en la configuración. También puedes consultar la sección "Resolución de problemas" que se encuentra más adelante en este capítulo.

Figura 3.1. Página de bienvenida del entorno de pruebas

El entorno de pruebas está pensado para que practiques con Symfony en un servidor local, no para desarrollar aplicaciones complejas que acaban siendo publicadas en la web. No obstante, la versión de Symfony que está incluida en el entorno de pruebas es completamente funcional y equivalente a la que se instala vía PEAR.

Para desinstalar el entorno de pruebas, borra el directorio sf_sandbox/ de la carpeta web/ de tu servidor.

Al desarrollar aplicaciones con Symfony, es probable que tengas que instalarlo dos veces: una para el entorno de desarrollo y otra para el servidor de producción (a no ser que el servicio de hosting que utilices tenga Symfony preinstalado). En cada uno de los servidores lo lógico es evitar duplicidades juntando todos los archivos de Symfony en un único directorio, independientemente de que desarrolles una o varias aplicaciones.

Como el desarrollo de Symfony evoluciona rápidamente, es posible que esté disponible una nueva versión estable del framework unos días después de la primera instalación. La actualización del framework es algo a tener muy en cuenta, por lo que se trata de otra razón de peso para juntar en un único directorio todas las librerías de Symfony.

Existen dos alternativas para instalar las librerías necesarias para el desarrollo de las aplicaciones:

• La instalación que utiliza PEAR es la recomendada para la mayoría de usuarios. Con este método, la instalación es bastante sencilla, además de ser fácil de compartir y de actualizar.
• La instalación que utiliza Subversion (SVN) solamente se recomienda para los programadores de PHP más avanzados y es el método con el que pueden obtener los últimos parches, pueden añadir sus propias características al framework y pueden colaborar con el proyecto Symfony.

Symfony integra algunos paquetes externos:

• lime es una utilidad para las pruebas unitarias.
• Propel se utiliza para el ORM. Proporciona persistencia para los objetos y un servicio de consultas.
• Phing es una utilidad que emplea Propel para generar las clases del modelo.

Lime ha sido desarrollado por el equipo de Symfony. Propel y Phing han sido creados por otros equipos de desarrollo y se publican bajo la licencia GNU Lesser Public General License (LGPL). Todos estos paquetes están incluidos en Symfony.

El paquete PEAR de Symfony incluye las librerías propias de Symfony y todas sus dependencias. Además, también contiene un script que permite extender la línea de comandos del sistema para que funcione el comando symfony.

Para instalar Symfony de esta manera, en primer lugar se debe añadir el canal Symfony a PEAR mediante este comando:

> pear channel-discover pear.symfony-project.com

Para comprobar las librerías disponibles en ese canal, se puede ejecutar lo siguiente:

> pear remote-list -c symfony

Una vez añadido el canal, ya es posible instalar la última versión estable de Symfony mediante el siguiente comando:

> pear install symfony/symfony

 
downloading symfony-1.2.0.tgz ...
Starting to download symfony-1.2.0.tgz (1,283,270 bytes)
.................................................................
.................................................................
.............done: 1,283,270 bytes
install ok: channel://pear.symfony-project.com/symfony-1.2.0

Y la instalación ya ha terminado. Los archivos y las utilidades de línea de comandos de Symfony ya se han instalado. Para asegurarte de que se ha instalado correctamente, prueba a ejecutar el comando symfony para que te muestre la versión de Symfony que se encuentra instalada:

> symfony -V
 
symfony version 1.2.0 (/ruta/hasta/el/directorio/lib/dir/de/Symfony/en/PEAR)

Después de la instalación, las librerías de Symfony se encuentran en los siguientes directorios:

• $php_dir/symfony/ contiene las principales librerías.
• $data_dir/symfony/ contiene los archivos web que utilizan por defecto los módulos de Symfony.
• $doc_dir/symfony/ contiene la documentación.
• $test_dir/symfony/ contiene las pruebas unitarias y funcionales de Symfony.

Las variables que acaban en _dir se definen en la configuración de PEAR. Para ver sus valores, puedes ejecutar el siguiente comando:

> pear config-show

En los servidores de producción, o cuando no es posible utilizar PEAR, se puede descargar la última versión de las librerías Symfony directamente desde el repositorio Subversion que utiliza Symfony:

> mkdir /ruta/a/symfony
> cd /ruta/a/symfony
> svn checkout http://svn.symfony-project.com/tags/RELEASE_1_2_0/ .

El comando symfony, que solamente está disponible en las instalaciones PEAR, en realidad es una llamada al script que se encuentra en /ruta/a/symfony/data/bin/symfony. Por tanto, en una instalación realizada con SVN, el comando symfony -V es equivalente a:

> php /ruta/a/symfony/data/bin/symfony -V
 
symfony version 1.2.0 (/ruta/hasta/el/directorio/lib/dir/de/Symfony/en/SVN)

Si instalas Symfony mediante Subversion, es posible que ya tuvieras creado un proyecto con Symfony. Para que ese proyecto utilice la nueva versión de Symfony es necesario modificar el valor de la ruta definida en el archivo config/ProjectConfiguration.class.php del proyecto, como se muestra a continuación:

<?php
 
require_once '/ruta/hasta/lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();

 
class ProjectConfiguration extends sfProjectConfiguration
{
  // ...
}

El Capítulo 19 muestra otras opciones para enlazar un proyecto con una instalación de Symfony, incluyendo el uso de enlaces simbólicos y rutas relativas.

Como se vio en el Capítulo 2, Symfony agrupa las aplicaciones relacionadas en proyectos. Todas las aplicaciones de un proyecto comparten la misma base de datos. Por tanto, para crear una aplicación web en primer lugar se debe crear un proyecto.

Los proyectos de Symfony siguen una estructura de directorios predefinida. Los comandos que proporciona Symfony permiten automatizar la creación de nuevos proyectos, ya que se encargan de crear la estructura de directorios básica del proyecto y con los permisos adecuados. Por tanto, para crear un proyecto se debe crear un directorio y decirle a Symfony que cree un proyecto en su interior.

Si has utilizado la instalación con PEAR, ejecuta los siguientes comandos:

> mkdir ~/miproyecto
> cd ~/miproyecto
> symfony generate:project miproyecto

Si has instalado Symfony mediante SVN, puedes crear un proyecto con los siguientes comandos:

> mkdir ~/miproyecto
> cd ~/miproyecto
> php /ruta/hasta/data/bin/symfony generate:project miproyecto

La estructura de directorios creada por Symfony se muestra a continuación:

apps/
cache/
config/
data/
doc/
lib/
log/
plugins/
test/
web/

El proyecto recién creado está incompleto, ya que requiere por lo menos de una aplicación. Para crear la aplicación, se utiliza el comando symfony generate:app, al que se le tiene que pasar como argumento el nombre de la nueva aplicación:

> php symfony generate:app frontend

El comando anterior crea un directorio llamado frontend/ dentro del directorio apps/ que se encuentra en la raíz del proyecto. Por defecto se crea una configuración básica de la aplicación y una serie de directorios:

apps/
  frontend/
    config/
    i18n/
    lib/
    modules/
    templates/

En el directorio web del proyecto también se crean algunos archivos PHP correspondientes a los controladores frontales de cada uno de los entornos de ejecución de la aplicación:

web/
  index.php
  frontend_dev.php

El archivo index.php es el controlador frontal de producción de la nueva aplicación. Como se trata de la primera aplicación, Symfony crea un archivo llamado index.php en vez de frontend.php (si después se crea una nueva aplicación llamada por ejemplo backend, el controlador frontal del entorno de producción que se crea se llamará backend.php). Para ejecutar la aplicación en el entorno de desarrollo, se debe ejecutar el controlador frontal llamado frontend_dev.php. Por razones de seguridad el controlador frontal de desarrollo sólo se puede ejecutar por defecto desde localhost. El Capítulo 5 explica en detalle los distintos entornos de ejecución.

El comando symfony siempre se ejecuta en el directorio raíz del proyecto (miproyecto/ en los ejemplos anteriores) porque todas las tareas que ejecuta este comando dependen del proyecto.

Los scripts que se encuentran en el directorio web/ son los únicos puntos de entrada a la aplicación. Por este motivo, debe configurarse el servidor web para que puedan ser accedidos desde Internet. En el servidor de desarrollo y en los servicios de hosting profesionales, se suele tener acceso a la configuración completa de Apache para poder configurar servidores virtuales (virtual host). En los servicios de alojamiento compartido, lo normal es tener acceso solamente a los archivos .htaccess.

El listado 3-1 muestra un ejemplo de la configuración necesaria para crear un nuevo servidor virtual en Apache mediante la modificación del archivo httpd.conf.

Listado 3-1 - Ejemplo de configuración de Apache, en apache/conf/httpd.conf

<VirtualHost *:80>
  ServerName miaplicacion.ejemplo.com
  DocumentRoot "/home/juan/miproyecto/web"
  DirectoryIndex index.php
  Alias /sf /$sf_symfony_data_dir/web/sf
  <Directory "/$sf_symfony_data_dir/web/sf">
    AllowOverride All
    Allow from All
  </Directory>
  <Directory "/home/steve/miproyecto/web">
    AllowOverride All
    Allow from All
  </Directory>

</VirtualHost>

En la configuración del listado 3-1, se debe sustituir la variable $sf_symfony_data_dir por la ruta real del directorio de datos de Symfony. Por ejemplo, la ruta en un sistema *nix en el que se ha instalado Symfony mediante PEAR sería:

Alias /sf /usr/local/lib/php/data/symfony/web/sf

No te olvides reiniciar Apache para que los cambios surtan efecto. La aplicación recién creada ya se puede acceder con cualquier navegador en esta dirección:

http://localhost/frontend_dev.php/

Al acceder a la aplicación, se debería mostrar una imagen similar a la mostrada en la figura 3-1.

AddModule mod_rewrite.c
LoadModule rewrite_module modules/mod_rewrite.so

En los servidores de alojamiento compartido es un poco más complicado instalar las aplicaciones creadas con Symfony, ya que los servidores suelen tener una estructura de directorios que no se puede modificar.

Imaginemos que el servidor compartido llama a la carpeta web www/ en vez de web/ y que no es posible modificar el archivo de configuración httpd.conf, sino que solo es posible acceder a un archivo de tipo .htaccess en ese directorio.

Los proyectos creados con Symfony permiten configurar cada ruta de cada directorio. En el Capítulo 19 se detalla la configuración de los directorios, pero mientras tanto, se va a renombrar el directorio web a www y se va a modificar la configuración de la aplicación para que lo tenga en cuenta. El listado 3-2 muestra los cambios que es preciso añadir al final del archivo config/ProjectConfiguration.class.php.

Listado 3-2 - Modificación de la estructura de directorios por defecto, en config/ProjectConfiguration.class.php

class ProjectConfiguration extends sfProjectConfiguration

{
   public function setup()
   {
     $this->setWebDir($this->getRootDir().'/www');
   }

}

La carpeta web de la raíz del servidor contiene por defecto un archivo de tipo .htaccess. El listado 3-3 muestra su contenido, que debe ser modificado de acuerdo a los requerimientos de tu servidor compartido.

Listado 3-3 - Configuración por defecto de .htaccess, ahora guardado en miproyecto/www/.htaccess

Options +FollowSymLinks +ExecCGI

<IfModule mod_rewrite.c>

  RewriteEngine On

  # uncomment the following line, if you are having trouble
  # getting no_script_name to work
  #RewriteBase /

  # we skip all files with .something
  #RewriteCond %{REQUEST_URI} \..+$
  #RewriteCond %{REQUEST_URI} !\.html$
  #RewriteRule .* - [L]

  # we check if the .html version is here (caching)
  RewriteRule ^$ index.html [QSA]
  RewriteRule ^([^.]+)$ $1.html [QSA]
  RewriteCond %{REQUEST_FILENAME} !-f

  # no, so we redirect to our front web controller
  RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>

Después de realizar los cambios, ya debería ser posible acceder a la aplicación. Comprueba si se muestra la página de bienvenida accediendo a esta dirección:

http://www.ejemplo.com/frontend_dev.php/

Si se producen errores durante la instalación, lo mejor es intentar mostrar los mensajes de error en el navegador o en la consola de comandos. Normalmente los errores muestran pistas sobre su posible causa y hasta pueden contener enlaces a algunos recursos disponibles en Internet sobre ese problema.

Si continuan los problemas con Symfony, puedes comprobar los siguientes errores comunes:

• Algunas instalaciones de PHP incluyen tanto PHP 4 como PHP 5. En este caso, suele ser habitual que el comando de PHP 5 sea php5, por lo que se debe ejecutar la instrucción php5 symfony en vez de symfony. Puede que también sea necesario añadir la directiva SetEnv PHP_VER 5 en el archivo de configuración .htaccess e incluso puede que tengas que renombrar los scripts del directorio web/ para que tengan una extensión .php5 en vez de la tradicional extensión .php. Cuando se intenta ejecutar Symfony con PHP 4, el error que se muestra es similar al siguiente:

Parse error, unexpected ',', expecting '(' in .../symfony.php on line 19.

• El límite de memoria utilizado por PHP se define en el archivo de configuración php.ini y debería valer por lo menos 32M (equivalente a 32 MB). El síntoma común de este problema es cuando se muestra un mensaje de error al instalar Symfony mediante PEAR o cuando se utiliza la línea de comandos:

Allowed memory size of 8388608 bytes exhausted

• La directiva zend.ze1_compatibility_mode del archivo de configuración de PHP (php.ini) debe tener un valor igual a off. Si no es así, cuando se intenta acceder a cualquier script, se muestra el siguiente mensaje de error:

Strict Standards: Implicit cloning object of class 'sfTimer'because of 'zend.ze1_compatibility_mode'

• Los directorios log/ y cache/ del proyecto deben tener permiso de escritura para el servidor web. Si se ejecuta una aplicación sin estos permisos, se muestra la siguiente excepción:

sfCacheException [message] Unable to write cache file"/usr/miproyecto/cache/frontend/prod/config/config_config_handlers.yml.php"

• La ruta del sistema debe incluir la ruta al comando php, y la directiva include_path del archivo de configuración de PHP (php.ini) debe contener una ruta a PEAR (en el caso de que se utilice PEAR).

• En ocasiones, existe más de un archivo php.ini en el sistema (por ejemplo cuando se instala PHP mediante el paquete WAMP). En estos casos, se puede realizar una llamada a la función phpinfo() de PHP para saber la ruta exacta del archivo php.ini que está utilizando la aplicación.

Existen varias formas de encontrar soluciones a los problemas típicos y que ya les han ocurrido a otros usuarios:

• El foro de instalación de Symfony (http://www.symfony-project.org/forum/) contiene muchas preguntas sobre configuraciones en diferentes plataformas, entornos y servidores.
• La lista de correo de usuarios de Symfony (http://groups.google.es/group/symfony-es) permite buscar en sus archivos de mensajes, por lo que es posible que encuentres a otros usuarios que han pasado por los mismos problemas.
• El wiki de Symfony (http://trac.symfony-project.org/#Installingsymfony) contiene tutoriales detallados paso a paso sobre la instalación de Symfony que han sido creados por otros usuarios.

Si no encuentras la respuesta en esos recursos, puedes preguntar a la comunidad de Symfony. Las preguntas puedes hacerlas en el foro, en la lista de correo e incluso en el canal IRC de Symfony (#symfony) para obtener la respuesta de los miembros más activos de la comunidad.

Una vez creada la aplicación, se recomienda empezar con el versionado del código fuente (también llamado control de versiones). El versionado almacena todas las modificaciones realizadas en el código, permite acceder a las versiones anteriores de cualquier archivo, simplifica la creación de parches y permite trabajar en equipo de forma eficiente. Symfony soporta de forma nativa el uso de CVS, aunque recomienda el uso de Subversion (http://subversion.tigris.org/). Los ejemplos que se muestran a continuación utilizan comandos de Subversion y presuponen que existe un servidor de Subversion instalado y que se va a crear un nuevo repositorio para el proyecto. Para los usuarios de Windows, se recomienda utilizar TortoiseSVN (http://tortoisesvn.tigris.org/) como cliente de Subversion. La documentación oficial de Subversion es un buen recurso para ampliar los conocimientos sobre el versionado del código y sobre los comandos que utilizan los siguientes ejemplos.

Los siguientes ejemplos requieren que exista una variable de entorno llamada $SVNREP_DIR y cuyo valor es la ruta completa al repositorio. Si no es posible definir la variable de entorno, en los siguientes comandos se debe escribir la ruta completa al repositorio en vez de $SVNREP_DIR.

En primer lugar se crea un nuevo repositorio para el proyecto miproyecto:

> svnadmin create $SVNREP_DIR/miproyecto

Después se crea el layout o estructura básica del repositorio mediante los directorios trunk, tags y branches. El comando necesario es bastante largo:

> svn mkdir -m "Creacion del layout" file:///$SVNREP_DIR/miproyecto/trunk file:///$SVNREP_DIR/miproyecto/tags file:///$SVNREP_DIR/miproyecto/branches

A continuación se realiza la primera versión, para lo que es necesario importar todos los archivos del proyecto salvo los archivos temporales de cache/ y log/:

> cd ~/miproyecto

> rm -rf cache/*
> rm -rf log/*
> svn import -m "Primera importacion" . file:///$SVNREP_DIR/miproyecto/trunk

El siguiente comando permite comprobar si se han subido correctamente los archivos:

> svn ls file:///$SVNREP_DIR/miproyecto/trunk/

Por el momento todo va bien, ya que ahora el repositorio SVN contiene una versión de referencia de todos los archivos del proyecto. De esta forma, los archivos del directorio miproyecto/ deben hacer referencia a los que almacena el repositorio. Para ello, renombra el directorio miproyecto/ (si todo funciona correctamente lo podrás borrar) y descarga los contenidos del repositorio en un nuevo directorio:

> cd ~
> mv miproyecto miproyecto.original
> svn co file:///$SVNREP_DIR/miproyecto/trunk miproyecto
> ls miproyecto

Y eso es todo. Ahora ya es posible trabajar con los archivos que se encuentran en el directorio miproyecto/ y subir todos los cambios al repositorio. Puedes borrar el directorio miproyecto.original/ porque ya no se utiliza.

Solamente es necesario realizar una última configuración. Si se suben todos los archivos del directorio al repositorio, se van a copiar algunos archivos innecesarios, como los que se encuentran en los directorios cache/ y log/. Subversion permite establecer una lista de archivos que se ignoran al subir los contenidos al repositorio. Además, es preciso establecer de nuevo los permisos correctos a los directorios cache/ y log/:

> cd ~/miproyecto

> chmod 777 cache
> chmod 777 log
> svn propedit svn:ignore log
> svn propedit svn:ignore cache

Al ejecutar los comandos anteriores, Subversion muestra el editor de textos configurado por defecto. Si no se muestra nada, configura el editor de textos que utiliza Subversion por defecto mediante el siguiente comando:

> export SVN_EDITOR=<nombre_del_editor_de_textos>

> svn propedit svn:ignore log
> svn propedit svn:ignore cache

Para incluir todos los archivos de los directorios, se debe escribir lo siguiente cuando se muestre el editor de textos:

*

Para finalizar, guarda los cambios y cierra el editor.

Para probar y jugar con Symfony en un servidor local, la mejor opción es instalar el entorno de pruebas o sandbox, que contiene un entorno de ejecución preconfigurado para Symfony.

Para desarrollar aplicaciones web reales o para instalarlo en un servidor de producción, se puede optar por la instalación via PEAR o mediante el repositorio de Subversion. Estos métodos instalan las librerías de Symfony, pero se deben crear manualmente los proyectos y las aplicaciones. El último paso de la configuración de las aplicaciones es la configuración del servidor web, que puede realizarse de muchas formas. Symfony funciona muy bien con los servidores virtuales y de hecho es el método recomendado.

Si se producen errores durante la instalación, existen muchos tutoriales y preguntas frecuentes en el sitio web de Symfony. Incluso es posible trasladar tu problema a la comunidad Symfony para obtener una respuesta en general rápida y efectiva.

Después de crear el proyecto, se recomienda empezar con el versionado del código fuente para realizar el control de versiones.

Una vez que ya se puede utilizar Symfony, es un buen momento para desarrollar la primera aplicación web básica.

Curiosamente, el primer tutorial que utilizan los programadores para aprender cualquier lenguaje de programación o framework es el que muestra por pantalla el mensaje "¡Hola Mundo!" (del inglés Hello, world!). Resulta extraño creer que un ordenador pueda ser capaz de saludar a todo el mundo, ya que todos los intentos que ha habido hasta ahora en el campo de la inteligencia artificial han resultado en unos sistemas artificiales de conversación bastante pobres. No obstante, Symfony no es más tonto que cualquier otro framework, y la prueba es que se puede crear una página que muestre el mensaje "Hola, <tu_nombre>".

En este capítulo se muestra como crear un módulo, que es el elemento que agrupa a las páginas. También se aprende cómo crear una página, que a su vez se divide en una acción y una plantilla, siguiendo la arquitectura MVC. Las interacciones básicas con las páginas se realizan mediante enlaces y formularios, por lo que también se muestra como incluirlos en las plantillas y como manejarlos en las acciones.

Como se vio en el Capítulo 2, Symfony agrupa las páginas en módulos. Por tanto, antes de crear una página es necesario crear un módulo, que inicialmente no es más que una estructura vacía de directorios y archivos que Symfony puede reconocer.

La línea de comandos de Symfony automatiza la creación de los módulos. Sólo se necesita llamar a la tarea generate:module indicando como argumentos el nombre de la aplicación y el nombre del nuevo módulo. En el capítulo anterior se creó una aplicación llamada frontend. Para añadirle un módulo llamado contenido, se deben ejecutar los siguientes comandos:

> cd ~/miproyecto
> php symfony generate:module frontend contenido
 
>> dir+      ~/miproyecto/apps/frontend/modules/contenido/actions
>> file+     ~/miproyecto/apps/frontend/modules/contenido/actions/actions.class.php
>> dir+      ~/miproyecto/apps/frontend/modules/contenido/templates
>> file+     ~/miproyecto/apps/frontend/modules/contenido/templates/indexSuccess.php
>> file+     ~/miproyecto/test/functional/frontend/contenidoActionsTest.php

>> tokens    ~/miproyecto/test/functional/frontend/contenidoActionsTest.php
>> tokens    ~/miproyecto/apps/frontend/modules/contenido/actions/actions.class.php
>> tokens    ~/miproyecto/apps/frontend/modules/contenido/templates/indexSuccess.php

Además de los directorios actions/ y templates/ este comando crea tres archivos. El archivo que se encuentra en el directorio test/ está relacionado con las pruebas funcionales, que se ven en el Capítulo 15. El archivo actions.class.php (que se muestra en el listado 4-1) redirige la acción a la página de bienvenida del módulo por defecto. Por último, el archivo templates/indexSuccess.php está vacío.

Listado 4-1 - La acción generada por defecto, en actions/actions.class.php

<?php
 
class contenidoActions extends sfActions
{

  public function executeIndex()
  {
    $this->forward('default', 'module');
  }

}

En cada nuevo módulo, Symfony crea una acción por defecto llamada index. La acción completa se compone del método executeIndex de la acción y del archivo de su plantilla llamada indexSuccess.php. El significado del prefijo execute y del sufijo Success se explican detalladamente en los Capítulos 6 y 7 respectivamente. Por el momento se puede considerar que esta forma de nombrar a los archivos y métodos es una convención que sigue Symfony. Para visualizar la página generada (que se muestra en la figura 4-1) se debe acceder a la siguiente dirección en un navegador:

http://localhost/frontend_dev.php/contenido/index

En este capítulo no se utiliza la acción index, por lo que se puede borrar el método executeIndex() del archivo actions.class.php y también se puede borrar el archivo indexSuccess.php del directorio templates/.

Figura 4.1. La página de índice generada automáticamente

En Symfony la lógica o código de las páginas se define en la acción y la presentación se define en las plantillas. Las páginas estáticas que no requieren de ninguna lógica necesitan definir una acción vacía.

En este ejemplo, la página que muestra el mensaje "¡Hola Mundo!" se puede acceder mediante una acción llamada ver. Para crearla, solamente es necesario añadir el método executeVer en la clase contenidoActions, como muestra el Listado 4-2.

Listado 4-2 - Añadir una acción es equivalente a añadir un método de tipo execute en la clase de la acción

<?php
 
class contenidoActions extends sfActions
{
  public function executeVer()

  {
  }
}

El nombre del método de la acción siempre es execute + Xxxxxxx + (), donde la segunda parte del nombre es el nombre de la acción con la primera letra en mayúsculas.

Por tanto, si ahora se accede a la siguiente dirección:

http://localhost/frontend_dev.php/contenido/ver

Symfony mostrará un mensaje de error indicando que la plantilla verSuccess.php no existe. Se trata de un error normal por el momento, ya que las páginas siempre están formadas por una acción y una plantilla.

http://localhost/frontend_dev.php/articulo/index?id=123

http://localhost/articulos/europa/francia/economia.html

http://localhost/articulos/etiquetas/economia+francia+euro

La acción espera una plantilla para mostrarse en pantalla. Una plantilla es un archivo que está ubicado en el directorio templates/ de un módulo, y su nombre está compuesto por el nombre de la acción y el resultado de la misma. El resultado por defecto es success (exitoso), por lo que el archivo de plantilla que se crea para la acción ver se llamará verSuccess.php.

Se supone que las plantillas sólo deben contener código de presentación, así que procura mantener la menor cantidad de código PHP en ellas como sea posible. De hecho, una página que muestre "¡Hola, mundo!" puede tener una plantilla tan simple como la del Listado 4-3.

Listado 4-3 - La plantilla contenido/templates/verSuccess.php

<p>¡Hola, mundo!</p>

Si necesitas ejecutar algún código PHP en la plantilla, es mejor evitar la sintaxis usual de PHP, como se muestra en el Listado 4-4. En su lugar, es preferible escribir las plantillas utilizando la sintaxis alternativa de PHP, mostrada en el Listado 4-5, para mantener el código entendible para personas sin conocimientos de PHP. De esta forma, no sólo el código final estará correctamente indentado, sino que además ayudará a mantener el código complejo de PHP en la acción, dado que sólo las estructuras de control (if, foreach, while y demás) poseen una sintaxis alternativa.

Listado 4-4 - La sintaxis tradicional de PHP, buena para las acciones, pero mala para las plantillas

<p>¡Hola, mundo!</p>
<?php
 
if ($prueba)

{
  echo "<p>".time()."</p>";

}
 
?>

Listado 4-5 - La sintaxis alternativa de PHP, buena para las plantillas

<p>¡Hola, mundo!</p>
<?php if ($prueba): ?>

  <p><?php echo time(); ?></p>
<?php endif; ?>

La tarea de la acción es realizar los cálculos complejos, obtener datos, realizar comprobaciones, y crear o inicializar las variables necesarias para que se presenten o se utilicen en la plantilla. Symfony hace que los atributos de la clase de la acción (disponibles vía $this->nombreDeVariable en la acción), estén directamente accesibles en la plantilla en el ámbito global (vía $nombreVariable). Los listados 4-6 y 4-7 muestran cómo pasar información de la acción a la plantilla.

Listado 4-6 - Configurando un atributo de acción dentro de ella para hacerlo disponible para la plantilla

<?php
 
class contenidoActions extends sfActions
{
  public function executeVer()

  {
    $hoy = getdate();
    $this->hora = $hoy['hours'];
  }

}

Listado 4-7 - La plantilla tiene acceso directo a los atributos de la acción

<p>¡Hola, Mundo!</p>
<?php if ($hora >= 18): ?>

  <p>Quizás debería decir buenas tardes. Ya son las <?php echo $hora ?>.</p>
<?php endif; ?>

El uso de etiquetas cortas de apertura (<?=, equivalente a <?php echo) no se recomienda para aplicaciones web profesionales, debido a que el servidor web de producción puede ser capaz de entender más de un lenguaje de script, y por tanto, confundirse. Además, las etiquetas cortas de apertura no funcionan con la configuración por defecto de PHP y necesitan de ajustes en el servidor para ser activadas. Por último, a la hora de lidiar con XML y la validación, fallará inmediatamente porque <? tiene un significado especial en XML.

Ya se ha comentado que existe una independencia total entre el nombre de la acción y la URL utilizada para llamarla, por lo que si se crea un enlace a actualizar en una plantilla como en el Listado 4-10, sólo funcionará con el enrutamiento establecido por defecto. Si más tarde se decide modificar la manera de mostrar las URL, entonces será necesario verificar todas las plantillas para modificar los enlaces o hipervínculos.

Listado 4-10 - Forma clásica de incluir los enlaces

<a href="/frontend_dev.php/contenido/actualizar?nombre=anonimo">
  Nunca digo mi nombre
</a>

Para evitar este inconveniente, es necesario siempre utilizar el helper link_to() para crear enlaces a las acciones de la aplicación. Si lo único que quieres es obtener la URL del enlace, entonces debes utilizar el helper url_for().

Un helper es una función PHP definida por Symfony y que está pensada para ser utilizada en las plantillas. Los helpers generan código HTML y normalmente resultan más eficientes que escribir a mano ese mismo código HTML. El Listado 4-11 muestra el uso de los helpers para enlaces.

Listado 4-11 - Los helpers link_to() y url_for()

<p>¡Hola, Mundo!</p>
<?php if ($hora >= 18): ?>

<p>Quizás debería decir buenas tardes. Ya son las <?php echo $hora ?>.</p>
<?php endif; ?>

<form method="post" action="<?php echo url_for('contenido/actualizar') ?>">
  <label for="nombre">¿Cómo te llamas?</label>
  <input type="text" name="nombre" id="nombre" value="" />

  <input type="submit" value="Ok" />
  <?php echo link_to('Nunca digo mi nombre','contenido/actualizar?nombre=anonymous') ?>

</form>

El código HTML resultante es el mismo que el anterior, pero en este caso, si se modifican las reglas de enrutamiento, todas las plantillas siguen funcionando correctamente ya que se actualizan las URL de forma automática.

Los formularios merecen un capítulo completo para ellos, ya que Symfony provee muchas herramientas, sobre todo helpers, para facilitar tu trabajo. En el capítulo 10 aprenderás todo sobre estos helpers.

El helper link_to(), al igual que muchos otros, acepta un argumento para opciones especiales y atributos de etiqueta adicionales. El Listado 4-12 muestra un ejemplo de un argumento option y su código HTML resultante. El argumento option puede ser tanto un array asociativo como una simple cadena de texto mostrando pares de clave=valor separados por espacios.

Listado 4-12 - La mayoría de los helpers aceptan un argumento option

// Argumento "option" como un array asociativo
<?php echo link_to('Nunca digo mi nombre', 'contenido/actualizar?nombre=anonimo',
  array(

    'class'    => 'enlace_especial',
    'confirm'  => '¿Estás seguro?',
    'absolute' => true

)) ?>
 
// Argumento "option" como una cadena de texto
<?php echo link_to('Nunca digo mi nombre', 'contenido/actualizar?nombre=anonimo',
  'class=enlace_especial confirm=¿Estás seguro? absolute=true') ?>

 
// Las dos funciones generan el mismo resultado
 => <a class="enlace_especial" onclick="return confirm('¿Estás seguro?');"
    href="http://localhost/frontend_dev.php/contenido/actualizar/nombre/anonimo">

    Nunca digo mi nombre</a>

Siempre que se utiliza un helper de Symfony que devuelve una etiqueta HTML, es posible insertar atributos de etiqueta adicionales (como el atributo class en el ejemplo del Listado 4-12) en el argumento option. Incluso es posible escribir estos atributos a la vieja usanza que utiliza HTML 4.0 (sin comillas dobles), y Symfony se encargará de mostrarlos correctamente formateados en XHTML. Esta es otra razón por la que los helpers son más rápidos de escribir que el HTML puro.

Al igual que el resto de helpers de Symfony, los helpers de enlaces son muy numerosos y tienen muchas opciones. En el capítulo 9 se explican todos estos helpers con más detalle.

El método getParameter() del objeto sfRequest permite recuperar desde la acción los datos relacionados con la información que envía el usuario a través de un formulario (normalmente en una petición POST) o a través de la URL (mediante una petición GET). El Listado 4-13 muestra cómo es posible obtener el valor del parámetro nombre en la acción actualizar.

Listado 4-13 - Recuperando datos de la petición dentro de una acción

<?php
 
class contenidoActions extends sfActions
{
  // ...

 
  public function executeActualizar($peticion)
  {
    $this->nombre = $peticion->getParameter('nombre');
  }

}

Para que el código sea más sencillo, a todos los métodos de tipo executeXxx() se les pasa como primer argumento el objeto que representa al sfRequest actual.

Si la manipulación de datos es simple, ni siquiera es necesario utilizar la acción para recuperar los parámetros de la petición. La plantilla tiene acceso a un objeto llamado $sf_params que ofrece un método get() para recuperar los parámetros de la petición, tal y como hace el método getParameter() en la acción.

Si la acción executeActualizar estuviera vacía, el listado 4-14 muestra cómo se puede obtener el valor del parámetro nombre desde la plantilla actualizarSuccess.php.

Listado 4-14 - Obteniendo datos de la petición directamente en la plantilla

<p>Hola, <?php echo $sf_params->get('nombre') ?>!</p>

El objeto $sf_params es más potente que simplemente añadir una especie de getter a un array. Por ejemplo, si sólo se desea probar la existencia de un parámetro de petición, se puede utilizar simplemente el método $sf_parameter->has(), en lugar de comprobar el valor en cuestión con get(), tal como en el Listado 4-15.

Listado 4-15 - Comprobando la existencia de un parámetro de petición en la plantilla

<?php if ($sf_params->has('nombre')): ?>

  <p>¡Hola, <?php echo $sf_params->get('nombre') ?>!</p>

<?php else: ?>
  <p>¡Hola, Juan Pérez!</p>
<?php endif; ?>

Como puede que hayas adivinado, el código anterior puede escribirse en una sola línea. Al igual que la mayoría de los métodos getter de Symfony, tanto el método $peticion->getParameter() en la acción, como el método $sf_params->get() en la plantilla (que por cierto llama al mismo método del mismo objeto), aceptan un segundo argumento: el valor por defecto a utilizar si dicho parámetro de petición no está presente.

<p>¡Hola, <?php echo $sf_params->get('nombre', 'Juan Pérez') ?>!</p>

En Symfony, las páginas están compuestas por una acción (un método del archivo actions/actions.class.php con el prefijo execute) y una plantilla (un archivo en el directorio templates/, normalmente terminado en Success.php). Las páginas se agrupan en módulos, de acuerdo a su función en la aplicación. Escribir plantillas es muy sencillo con la ayuda de los helpers, funciones provistas por Symfony para generar código HTML. Además es necesario pensar que la URL es parte de la respuesta, por lo que se puede formatear de cualquier forma que se necesite, sólo debes abstenerte de utilizar cualquier referencia directa a la URL en el nombre de la acción o al recuperar un parámetro de petición.

Una vez aprendidos estos principios básicos, es posible escribir una aplicación web completa con Symfony. Pero te costaría mucho tiempo, dado que casi cualquier tarea a completar durante el transcurso del desarrollo de la aplicación, se simplifica de una forma u otra por alguna funcionalidad de Symfony...motivo por el que este libro aún no termina.

Para simplificar su uso, Symfony define una serie de convenciones o normas que se ajustan a los requisitos habituales de las aplicaciones web estándar. De todas formas, los archivos de configuración, a pesar de ser tan sencillos de utilizar, son lo suficientemente potentes como para personalizar cualquier aspecto del framework y la forma en que interactúan las aplicaciones. También es posible con estos archivos de configuración añadir parámetros específicos para las aplicaciones.

En este capítulo se explica cómo funciona el mecanismo de configuración:

• La configuración de Symfony se guarda en archivos escritos con YAML, aunque se puede utilizar otro formato.
• En la estructura de directorios del proyecto, existen archivos de configuración a nivel de proyecto, de aplicación y de módulo.
• También es posible definir conjuntos de opciones de configuración. En Symfony, un conjunto de opciones de configuración se llama entorno.
• Desde cualquier punto del código de la aplicación se puede acceder a los valores establecidos en los archivos de configuración.
• Además, Symfony permite utilizar código PHP dentro de los archivos YAML y algún que otro truco más para hacer más flexible el sistema de configuración.

La mayoría de aplicaciones web comparten una serie de características, independientemente de su finalidad. Por ejemplo, es habitual restringir algunas partes de la aplicación a una serie de usuarios, utilizar un layout común para mostrar todas las páginas, los formularios deben volver a mostrar los datos que ha introducido el usuario después de una validación errónea. El framework define el comportamiento básico de estas características y el programador puede adaptar cada una mediante las opciones de configuración. Esta forma de trabajar ahorra mucho tiempo de desarrollo, ya que muchos cambios importantes no necesitan modificar ni siquiera una línea de código, aunque estos cambios impliquen muchos cambios internos. Además se trata de una forma mucho más eficiente, ya que permite asegurar que toda la configuración se encuentra en un lugar único y fácilmente localizable.

No obstante, este método también tiene dos inconvenientes muy importantes:

• Los programadores acaban escribiendo archivos XML complejos y muy largos.
• En una arquitectura basada en PHP, cada petición consumiría mucho más tiempo de proceso.

Considerando todas estas desventajas, Symfony utiliza solamente lo mejor de los archivos de configuración. De hecho, el objetivo del sistema de configuración de Symfony es ser:

• Potente: todo lo que puede ser gestionado con archivos de configuración, se gestiona con archivos de configuración.
• Simple: muchas de las características de la configuración no se utilizan habitualmente, por lo que las aplicaciones normales no tienen que tratar con ellas.
• Sencillo: los archivos de configuración son sencillos de leer, de modificar y de crear por parte de los desarrolladores.
• Personalizable: el lenguaje que se utiliza por defecto en los archivos de configuración es YAML, pero se puede cambiar por archivos INI, XML o cualquier otro formato que prefiera el programador.
• Rápido: la aplicación nunca procesa los archivos de configuración, sino que se encarga de ello el sistema de configuración, que compila todos los archivos de configuración en trozos de código PHP que se pueden procesar muy rápidamente.

Symfony utiliza por defecto el formato YAML para la configuración, en vez de los tradicionales formatos INI y XML. El formato YAML indica su estructura mediante la tabulación y es muy rápido de escribir. El Capítulo 1 ya describe algunas de sus ventajas y las reglas más básicas. No obstante, se deben tener presentes algunas convenciones al escribir archivos YAML. En esta sección se mencionan las convenciones o normas más importantes. El sitio web de YAML (http://www.yaml.org/) contiene la lista completa de normas del formato.

En primer lugar, no se deben utilizar tabuladores en los archivos YAML, sino que siempre se deben utilizar espacios en blanco. Los sistemas que procesan YAML no son capaces de tratar con los tabuladores, por lo que la tabulación de los archivos se debe crear con espacios en blanco como se muestra en el listado 5-1 (en YAML un tabulador se indica mediante 2 espacios en blanco seguidos).

Listado 5-1 - Los archivos YAML no permiten los tabuladores

# No utilices tabuladores
all:
  -> mail:
  -> -> webmaster:  webmaster@ejemplo.com
 
# Utiliza espacios en blanco

all:
  mail:
    webmaster: webmaster@ejemplo.com

Si los parámetros son cadenas de texto que contienen espacios en blanco al principio o al final, se debe encerrar la cadena entera entre comillas simples. Si la cadena de texto contiene caracteres especiales, también se encierran con comillas simples, como se muestra en el listado 5-2.

Listado 5-2 - Las cadenas de texto especiales deben encerrarse entre comillas simples

error1: Este campo es obligatorio
error2: '  Este campo es obligatorio  '

 
# Las comillas simples que aparecen dentro de las cadenas de
# texto, se deben escribir dos veces
error3: 'Este [nowiki]''campo''[/nowiki] es obligatorio'

Se pueden escribir cadenas de texto muy largas en varias líneas, además de juntar cadenas escritas en varias líneas. En este último caso, se debe utilizar un carácter especial para indicar que se van a escribir varias líneas (se puede utilizar > o |) y se debe añadir una pequeña tabulación (dos espacios en blanco) a cada línea del grupo de cadenas de texto. El listado 5-3 muestra este caso.

Listado 5-3 - Definir cadenas de texto muy largas y cadenas de texto multi-línea

# Las cadenas de texto muy largas se pueden escribir en
# varias líneas utilizando el carácter >
# Posteriormente, cada nueva línea se transforma en un
# espacio en blanco para formar la cadena de texto original.
# De esta forma, el archivo YAML es más fácil de leer
frase_para_recordar: >

  Vive como si fueras a morir mañana y
  aprende como si fueras a vivir para siempre.
 
# Si un texto está formado por varias líneas, se utiliza
# el carácter | para separar cada nueva línea. Los espacios
# en blanco utilizados para tabular las líneas no se tienen
# en cuenta.
direccion: |
  Mi calle, número X
  Nombre de mi ciudad
  CP XXXXX

Los arrays se definen mediante corchetes que encierran a los elementos o mediante la sintaxis expandida que utiliza guiones medios para cada elemento del array, como se muestra en el listado 5-4.

Listado 5-4 - Sintaxis de YAML para incluir arrays

# Sintaxis abreviada para los arrays
idiomas: [ Alemán, Francés, Inglés, Italiano ]
 
# Sintaxis expandida para los arrays
idiomas:
  - Alemán
  - Francés
  - Inglés
  - Italiano

Para definir arrays asociativos, se deben encerrar los elementos mediante llaves ({ y }) y siempre se debe insertar un espacio en blanco entre la clave y el valor de cada par clave: valor. También existe una sintaxis expandida que requiere indicar cada par clave: valor en una nueva línea y con una tabulación (es decir, con 2 espacios en blanco delante) como se muestra en el listado 5-5.

Listado 5-5 - Sintaxis de YAML para incluir arrays asociativos

# Sintaxis incorrecta, falta un espacio después de los 2 puntos
mail: {webmaster:webmaster@ejemplo.com,contacto:contacto@ejemplo.com}
 
# Sintaxis abreviada correcta para los array asociativos
mail: { webmaster: webmaster@ejemplo.com, contacto: contacto@ejemplo.com }

 
# Sintaxis expandida para los arrays asociativos
mail:
  webmaster: webmaster@ejemplo.com
  contacto:  contacto@ejemplo.com

Para los parámetros booleanos, se pueden utilizar los valores on, 1 o true para los valores verdaderos y off, 0 o false para los valores falsos. El listado 5-6 muestra los posibles valores booleanos.

Listado 5-6 - Sintaxis de YAML para los valores booleanos

valores_verdaderos:   [ on, 1, true ]
valores_falsos:       [ off, 0, false ]

Es recomendable añadir comentarios (que se definen mediante el carácter #) y todos los espacios en blanco adicionales que hagan falta para hacer más fáciles de leer los archivos YAML, como se muestra en el listado 5-7.

Listado 5-7 - Comentarios en YAML y espacios adicionales para alinear valores

# Esta línea es un comentario
mail:
  webmaster: webmaster@ejemplo.com
  contacto:  contacto@ejemplo.com
  admin:     admin@ejemplo.com   # se añaden espacios en blanco para alinear los valores

En algunos archivos de configuración de Symfony, se ven líneas que empiezan por # (y por tanto se consideran comentarios y se ignoran) pero que parecen opciones de configuración correctas. Se trata de una de las convenciones de Symfony: la configuración por defecto, heredada de los archivos YAML del núcleo de Symfony, se repite en forma de líneas comentadas a lo largo de los archivos de configuracion de cada aplicación, con el único objetivo de informar al desarrollador. De esta forma, para modificar esa opción de configuración, solamente es necesario eliminar el carácter de los comentarios y establecer su nuevo valor. El listado 5-8 muestra un ejemplo.

Listado 5-8 - La configuración por defecto se muestra en forma de comentarios

# Por defecto la cache está desactivada
settings:
# cache: off
 
# Para modificar esta opción, se debe descomentar la línea
settings:
  cache: on

En ocasiones, Symfony agrupa varias opciones de configuración en categorías. Todas las opciones que pertenecen a una categoría se muestran tabuladas y bajo el nombre de esa categoría. La configuración es más sencilla de leer si se agrupan las listas largas de pares clave: valor. Los nombres de las categorías comienzan siempre con un punto (.) y el listado 5-19 muestra un ejemplo de uso de categorías.

Listado 5-9 - Los nombres de categorías son como los nombres de las clave, pero empiezan con un punto

all:
  .general:
    impuestos:  19.6
 
mail:
  webmaster:    webmaster@ejemplo.com

En el ejemplo anterior, mail es una clave y general sólo es el nombre de la categoría. En realidad, el archivo YAML se procesa como si no existiera el nombre de la categoría, es decir, como se muestra en el listado 5-10. El parámetro impuestos realmente es descendiente directo de la clave all. No obstante, el uso de nombres de categorías facilita a Symfony el manejo de los arrays que se encuentran bajo la clave all.

Listado 5-10 - Los nombres de categorías solo se utilizan para hacer más fácil de leer los archivos YAML y la aplicación los ignora

all:
  impuestos:    19.6
 
mail:
  webmaster:    webmaster@ejemplo.com

Los archivos YAML se procesan y se transforman en array asociativos y arrays normales de PHP. Después, estos valores transformados son los que se utilizan en la aplicación para modificar el comportamiento de la vista, el modelo y el controlador. Por este motivo, cuando existe un error en un archivo YAML, normalmente no se detecta hasta que se utiliza ese valor específico. Para complicar las cosas, el error o la excepción que se muestra no siempre indica de forma clara que puede tratarse de un error en los archivos YAML de configuración.

Si la aplicación deja de funcionar después de un cambio en la configuración, se debe comprobar que no se ha cometido alguno de los errores típicos de los desarrolladores principiantes con YAML:

• No existe un espacio en blanco entre la clave y su valor:

clave1:valor1      # Falta un espacio después del :

• Alguna clave de una secuencia de valores está mal tabulada:

all:
  clave1:  valor1
   clave2: valor2  # Su tabulación no es igual que los otros miembros de la secuencia
  clave3:  valor3

• Alguna clave o valor contiene caracteres reservados por YAML que no han sido encerrados por las comillas simples:

mensaje: dile lo siguiente: hola    # :, [, ], { y } están reservados por YAML
mensaje: 'dile lo siguiente: hola'  # Sintaxis correcta

• La línea que se modifica está comentada:

# clave: valor     # No se tiene en cuenta porque empieza por #

• Existen 2 claves iguales con diferentes valores dentro del mismo nivel:

clave1: valor1
clave2: valor2
clave1: valor3     # clave1 está definida 2 veces, solo se tiene en cuenta su último valor

• Todos los valores se consideran cadenas de texto, salvo que se convierta de forma explícita su valor:

ingresos: 12,345   # El valor es una cadena de texto y no un número, salvo que se convierta

La configuración de las aplicaciones realizadas con Symfony se distribuye en varios archivos según su propósito. Los archivos contienen definiciones de parámetros, normalmente llamadas opciones de configuración. Algunos parámetros se pueden redefinir en varios niveles de la aplicación web (proyecto, aplicación y módulo) y otros parámetros son exclusivos de algún nivel. En los siguientes capítulos se muestran los diversos archivos de configuración relacionados con el tema de cada capítulo. En el Capítulo 19 se explica la configuración avanzada.

Symfony crea por defecto algunos archivos de configuración relacionados con el proyecto. El directorio miproyecto/config/ contiene los siguientes archivos:

• ProjectConfiguration.class.php: se trata del primer archivo que se incluye con cada petición o comando. Contiene la ruta a los archivos del framework y se puede modificar para realizar una instalación personalizada. El Capítulo 19 muestra el uso más avanzado de este archivo.
• databases.yml: contiene la definición de los accesos a bases de datos y las opciones de conexión de cada acceso (servidor, nombre de usuario, contraseña, nombre de base de datos, etc.) El Capítulo 8 lo explica en detalle. Sus parámetros se pueden redefinir en el nivel de la aplicación.
• properties.ini: contiene algunos parámetros que utiliza la herramienta de línea de comandos, como son el nombre del proyecto y las opciones para conectar con servidores remotos. El Capítulo 16 muestra las opciones de este archivo.
• rsync_exclude.txt: indica los directorios que se excluyen durante la sincronización entre servidores. El Capítulo 16 también incluye una explicación de este archivo.
• schema.yml y propel.ini: son los archivos de configuración que utiliza Propel para el acceso a los datos (recuerda que Propel es el sistema ORM que incorpora Symfony). Se utilizan para que las librerías de Propel puedan interactuar con las clases de Symfony y con los datos de la aplicación. schema.yml contiene la representación del modelo de datos relacional del proyecto. propel.ini se genera de forma automática y es muy probable que no necesites modificarlo. Si no se utiliza Propel, estos dos archivos son innecesarios. El Capítulo 8 explica en detalle el uso de estos dos archivos.

La mayoría de estos archivos los utilizan componentes externos o la línea de comandos e incluso algunos son procesados antes de que se inicie la herramienta que procesa archivos en formato YAML. Por este motivo, algunos de estos archivos no utilizan el formato YAML.

La configuración de la aplicación es la parte más importante de toda la configuración. La configuración se distribuye entre el controlador frontal (que se encuentra en el directorio web/) que contiene la configuración principal, el directorio config/ de la aplicación que contiene diversos archivos en formato YAML, los archivos de internacionalización que se encuentran en el directorio i18n/ y también existen otros archivos del framework que contienen opciones de configuración ocultas pero útiles para la configuración de la aplicación.

La primera configuración de la aplicación se encuentra en su controlador frontal, que es el primer script que se ejecuta con cada petición. El listado 5-11 muestra el código por defecto del controlador frontal generado automáticamente:

Listado 5-11 - El controlador frontal de producción generado automáticamente

<?php
 
require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');

 
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'prod', false);
sfContext::createInstance($configuration)->dispatch();

Después de definir el nombre de la aplicación (frontend) y el entorno en el que se ejecuta la aplicación (prod), se carga el archivo general de configuración, se crea un contexto y se despacha la petición (dispatching). En la clase de configuración de la aplicación se definen algunos métodos importantes:

• $configuration->getRootDir(): directorio raíz del proyecto (en general no hay que modificar su valor, salvo que se cambie la estructura de archivos del proyecto).
• $configuration->getApplication(): el nombre de la aplicación, que se utiliza para determinar las rutas de los archivos.
• $configuration->getEnvironment(): nombre del entorno en el que se ejecuta la aplicación (prod, dev o cualquier otro valor que se haya definido). Se utiliza para determinar las opciones de configuración que se utilizan. Al final de este capítulo se explican los entornos de ejecución.
• $configuration->isDebug(): activa el modo de depuración de la aplicación (el capítulo 16 contiene los detalles).

Cuando se quiere cambiar alguno de estos valores, normalmente se crea un nuevo controlador frontal. El siguiente capítulo explica su funcionamiento y cómo crear nuevos controladores.

La configuración más importante de la aplicación se encuentra en el directorio miproyecto/apps/frontend/config/:

• app.yml: contiene la configuración específica de la aplicación; por ejemplo se pueden almacenar variables globales que se utilizan en la lógica de negocio de la aplicación y que no se almacenan en una base de datos. Los ejemplos habituales de estas variables son los porcentajes de los impuestos como el IVA, los gastos de envío, direcciones de email de contacto, etc. Por defecto el archivo está vacío.
• frontendConfiguration.class.php: esta clase inicia la ejecucion de la aplicación, ya que realiza todas las inicializaciones necesarias para que la aplicación se pueda ejecutar. En este archivo se puede personalizar la estructura de directorios de la aplicación y se pueden añadir constantes que manejan las aplicaciones (el Capítulo 19 lo explica con más detalle). Esta clase hereda de la clase ProjectConfiguration.
• factories.yml: Symfony incluye sus propias clases para el manejo de la vista, de las peticiones, de las respuestas, de la sesión, etc. No obstante, es posible definir otras clases propias para realizar estas tareas. El Capítulo 17 lo explica más detalladamente.
• filters.yml: los filtros son trozos de código que se ejecutan con cada petición. En este archivo se definen los filtros que se van a procesar y cada módulo puede redefinir los filtros que se procesan. El Capítulo 6 explica en detalle los filtros.
• routing.yml: almacena las reglas de enrutamiento, que permiten transformar las URL habituales de las aplicaciones web en URL limpias y sencillas de recordar. Cada vez que se crea una aplicación se crean unas cuantas reglas básicas por defecto. El Capítulo 9 está dedicado a los enlaces y el sistema de enrutamiento.
• settings.yml: contiene las principales opciones de configuración de una aplicación Symfony. Entre otras, permite especificar si la aplicación utiliza la internacionalización, el idioma por defecto de la aplicación, el tiempo de expiración de las peticiones y si se activa o no la cache. Un cambio en una única línea de configuración de este archivo permite detener el acceso a la aplicación para realizar tareas de mantenimiento o para actualizar alguno de sus componentes. Las opciones más habituales y su uso se describen en el Capítulo 19.
• view.yml: establece la estructura de la vista por defecto: el nombre del layout, las hojas de estilos CSS y los archivos JavaScript que se incluyen, el Content-Type, etc. El capítulo 7 explica detalladamente todas sus posibilidades. Cada módulo puede redefinir el valor de todas estas opciones.

Las aplicaciones con soporte de internacionalización son las que pueden mostrar una misma página en diferentes idiomas. Para conseguirlo, es necesario realizar una configuración específica. Los dos sitios donde se configura la internacionalización en Symfony son:

• Archivo factories.yml del directorio config/ de la aplicación: en este archivo se define la factoría encargada de la internacionalización y otras opciones comunes para la traducción de páginas, como por ejemplo el idioma por defecto, si las traducciones se guardan en archivos o bases de datos y su formato.
• Los archivos de traducción en el directorio i18n/ de la aplicación: se trata de una especie de diccionarios que indican la traducción de cada frase que utilizan las plantillas de la aplicación de forma que cuando el usuario cambie de idioma sea posible mostrar las páginas en ese idioma.

Para activar el mecanismo de i18n, se debe modificar el archivo settings.yml. El Capítulo 13 profundiza en todas las características relacionadas con la i18n.

Algunos archivos de configuración se encuentran en el directorio de instalación de Symfony (en $sf_symfony_lib_dir/config/config/) y por tanto no aparecen en los directorios de configuración de las aplicaciones. Las opciones que se encuentran en esos archivos son opciones para las que raramente se modifica su valor o que son globales a todos los proyectos. De todas formas, si necesitas modificar alguna de estas opciones, crea un archivo vacío con el mismo nombre en el directorio miproyecto/apps/frontend/config/ y redefine todas las opciones que quieras modificar. Las opciones definidas en una aplicación siempre tienen preferencia respecto a las opciones definidas por el framework. Los archivos de configuración que se encuentran en el directorio config/ de la instalación de Symfony son los siguientes:

• autoload.yml: contiene las opciones relativas a la carga automática de clases. Esta opción permite utilizar clases propias sin necesidad de incluirlas previamente en el script que las utiliza, siempre que esas clases se encuentren en algunos directorios determinados. El Capítulo 19 lo describe en detalle.
• core_compile.yml y bootstrap_compile.yml: define la lista de clases que se incluyen al iniciar la aplicación (en bootstrap_compile.yml) y las que se incluyen al procesar una petición (en core_compile.yml). Todas estas clases se concatenan en un único archivo PHP optimizado en el que se eliminan los comentarios y que acelera mucho la ejecución de la aplicación (ya que se reduce el número de archivos que se acceden a uno solo desde los más de 40 archivos necesarios originalmente para cada petición). Esta característica es muy necesaria cuando no se utiliza ningún acelerador de PHP. El Capítulo 18 incluye diversas técnicas para optimizar el rendimiento de las aplicaciones.
• config_handlers.yml: permite añadir o modificar los manejadores de archivos de configuración. El Capítulo 19 contiene todos los detalles.

Inicialmente los módulos no tienen ninguna configuración propia. En cualquier caso, es posible modificar las opciones de la aplicación en cualquier módulo que así lo requiera. Un ejemplo de configuración específica es aquel que permite incluir un archivo JavaScript concreto en todas las acciones de un módulo. También se pueden añadir nuevos parámetros exclusivamente para un módulo concreto.

Como se puede suponer, los archivos de configuración de los módulos se encuentran en el directorio miproyecto/apps/frontend/modules/mimodulo/config/. Los archivos disponibles son los siguientes:

• generator.yml: se utiliza para los módulos generados automáticamente a partir de una tabla de la base de datos, es decir, para los módulos utilizados en el scaffolding y para las partes de administración creadas de forma automática. Contiene las opciones que definen como se muestran las filas y los registros en las páginas generadas y también define las interacciones con el usuario: filtros, ordenación, botones, etc. El Capítulo 14 explica todas estas características.
• module.yml: contiene la configuración de la acción y otros parámetros específicos del módulo (es un archivo equivalente al archivo app.yml de la aplicación). El Capítulo 6 lo explica en detalle.
• security.yml: permite restringir el acceso a determinadas acciones del módulo. En este archivo se configura que una página solamente pueda ser accedida por los usuarios registrados o por un grupo de usuarios registrados con permisos especiales. En el Capítulo 6 se detalla su funcionamiento.
• view.yml: permite configurar las vistas de una o de todas las acciones del módulo. Redefine las opciones del archivo view.yml de la aplicación y su funcionamiento se describe en el Capítulo 7.

Casi todos los archivos de configuración de los módulos permiten definir parámetros para todas las vistas y/o acciones del módulo o solo para una serie de vistas y/o acciones.

Cuando se desarrolla una aplicación, es habitual disponer de varias configuraciones distintas pero relacionadas. Por ejemplo durante el desarrollo se tiene un archivo de configuración con los datos de conexión a la base de datos de pruebas, mientras que en el servidor de producción los datos de conexión necesarios son los de la base de datos de producción. Symfony permite definir diferentes entornos de ejecución para poder manejar de forma sencilla las diferentes configuraciones.

Las aplicaciones de Symfony se pueden ejecutar en diferentes entornos. Todos los entornos comparten el mismo código PHP (salvo el código del controlador frontal) pero pueden tener configuraciones completamente diferentes. Cuando se crea una aplicación, Symfony crea por defecto 3 entornos: producción (prod), pruebas (test) y desarrollo (dev). También es posible añadir cualquier nuevo entorno que se considere necesario.

En cierta forma, un entorno y una configuración son sinónimos. Por ejemplo el entorno de pruebas registra las alertas y los errores en el archivo de log, mientras que el entorno de producción solamente registra los errores. En el entorno de desarrollo se suele desactivar la cache, pero está activa en los entornos de pruebas y de producción. Los entornos de pruebas y desarrollo normalmente trabajan con una base de datos que contiene datos de prueba, mientras que el servidor de producción trabaja con la base de datos buena. En este caso, la configuración de la base de datos varía en los diferentes entornos. Todos los entornos pueden ejecutarse en una misma máquina, aunque en los servidores de producción normalmente solo se instala el entorno de producción.

El entorno de desarrollo tiene activadas las opciones de log y de depuración de aplicaciones, ya que es más importante el mantenimiento de la aplicación que su rendimiento. Sin embargo, en el entorno de producción se ajustan las opciones de configuración para obtener el máximo rendimiento, por lo que muchas características están desactivadas por defecto. Una buena regla general suele ser la de utilizar el entorno de desarrollo hasta que consideres que la funcionalidad de la aplicación en la que estás trabajando se encuentra terminada y después pasarse al entorno de producción para comprobar su rendimiento.

El entorno de pruebas varía respecto del de desarrollo y el de producción. La única forma de interactuar con este entorno es mediante la línea de comandos para realizar pruebas funcionales y ejecutar scripts. De esta forma, el entorno de pruebas es parecido al de producción, pero no se accede a través de un navegador. De todas formas, simula el uso de cookies y otros componentes específicos de HTTP.

Para ejecutar la aplicación en otro entorno, solamente es necesario cambiar de controlador frontal. Hasta ahora, en todos los ejemplos se accedía al entorno de desarrollo, ya que las URL utilizadas llamaban al controlador frontal de desarrollo:

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

Sin embargo, si se quiere acceder a la aplicación en el entorno de producción, es necesario modificar la URL para llamar al controlador frontal de producción:

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

Si el servidor web tiene habilitado el mod_rewrite, es posible utilizar las reglas de reescritura de URL de Symfony, que se encuentran en web/.htaccess. Estas reglas definen que el controlador frontal de producción es el script que se ejecuta por defecto en las peticiones, por lo que se pueden utilizar URL como la siguiente:

http://localhost/mimodulo/index

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

Servidor = localhost
Entorno  = frontend_dev.php  (es decir, entorno de desarrollo)

Una misma opción de configuración puede estar definida más de una vez en archivos diferentes. De esta forma es posible por ejemplo definir que el tipo MIME de las páginas de la aplicación sea text/html, pero que las páginas creadas con el módulo que se encarga del RSS tengan un tipo MIME igual a text/xml. Symfony permite establecer el primer valor en frontend/config/view.yml y el segundo en frontend/modules/rss/config/view.yml. El sistema de configuración se encarga de que una opción establecida a nivel de módulo tenga más prioridad que la opción definida a nivel de aplicación.

De hecho, Symfony define varios niveles de configuración:

• Niveles de granularidad:
  • Configuración por defecto establecida por el framework
  • Configuración global del proyecto (en miproyecto/config/)
  • Configuración local de cada aplicación (en miproyecto/apps/frontend/config/)
  • Configuración local de cada módulo (en miproyecto/apps/frontend/modules/mimodulo/config/)
• Niveles de entornos de ejecución:
  • Específico para un solo entorno
  • Para todos los entornos

Muchas de las opciones que se pueden establecer dependen del entorno de ejecución. Por este motivo, los archivos de configuración YAML están divididos por entornos, además de incluir una sección que se aplica a todos los entornos. De esta forma, un archivo de configuración típico de Symfony se parece al que se muestra en el listado 5-12.

Listado 5-12 - La estructura típica de los archivos de configuración de Symfony

# Opciones para el entorno de producción
prod:
  ...
 
# Opciones para el entorno de desarrollo
dev:
  ...
 
# Opciones para el entorno de pruebas
test:
  ...
 
# Opciones para un entorno creado a medida

mientorno:
  ...
 
# Opciones para todos los entornos
all:
  ...

Además de estas opciones, el propio framework define otros valores por defecto en archivos que no se encuentran en la estructura de directorios del proyecto, sino que se encuentran en el directorio $sf_symfony_lib_dir/config/config/ de la instalación de Symfony. El listado 5-13 muestra la configuración por defecto de estos archivos. Todas las aplicaciones heredan estas opciones.

Listado 5-13 - La configuración por defecto, en $sf_symfony_lib_dir/config/config/settings.yml

# Opciones por defecto:
default:
  default_module:         default
  default_action:         index
  ...

Las opciones de estos archivos se incluyen como opciones comentadas en los archivos de configuración del proyecto, la aplicación y los módulos, como se muestra en el listado 5-14. De esta forma, se puede conocer el valor por defecto de algunas opciones y modificarlo si es necesario.

Listado 5-14 - La configuración por defecto, repetida en varios archivos para conocer fácilmente su valor, en frontend/config/settings.yml

#all:

  #  default_module:         default
  #  default_action:         index
  #...

El resultado final es que una misma opción puede ser definida varias veces y el valor que se considera en cada momento se genera mediante la configuración en cascada. Una opción definida en un entorno de ejecución específico tiene más prioridad sobre la misma opción definida para todos los entornos, que también tiene preferencia sobre las opciones definidas por defecto. Las opciones definidas a nivel de módulo tienen preferencia sobre las mismas opciones definidas a nivel de aplicación, que a su vez tienen preferencia sobre las definidas a nivel de proyecto. Todas estas prioridades se resumen en la siguiente lista de prioridades, en el que el primer valor es el más prioritario de todos:

1. Módulo
2. Aplicación
3. Proyecto
4. Entorno específico
5. Todos los entornos
6. Opciones por defecto

Si cada nueva petición tuviera que procesar todos los archivos YAML de configuración y tuviera que aplicar la configuración en cascada, se produciría una gran penalización en el rendimiento de la aplicación. Symfony incluye un mecanismo de cache de configuración para aumentar la velocidad de respuesta de las peticiones.

Unas clases especiales, llamadas manejadores, procesan todos los archivos de configuración originales y los transforman en código PHP que se puede procesar de forma muy rápida. En el entorno de desarrollo se prima la interactividad y no el rendimiento, por lo que en cada petición se comprueba si se ha modificado la configuración. Como se procesan siempre los archivos modificados, cualquier cambio de un archivo YAML se refleja de forma inmediata. Sin embargo, en el entorno de producción solamente se procesa la configuración una vez durante la primera petición y se almacena en una cache el código PHP generado, para que lo utilicen las siguientes peticiones. El rendimiento en el entorno producción no se resiente, ya que las peticiones solamente ejecutan código PHP optimizado.

Si por ejemplo el archivo app.yml contiene lo siguiente:

all:                   # Opciones para todos los entornos
  mail:
    webmaster:         webmaster@ejemplo.com

La carpeta cache/ del proyecto contendrá un archivo llamado config_app.yml.php y con el siguiente contenido:

<?php
 
sfConfig::add(array(
  'app_mail_webmaster' => 'webmaster@ejemplo.com',

));

La consecuencia es que los archivos YAML raramente son procesados por el framework, ya que se utiliza la cache de la configuración siempre que sea posible. Sin embargo, en el entorno de desarrollo cada nueva petición obliga a Symfony a comparar las fechas de modificación de los archivos YAML y las de los archivos almacenados en la cache. Solamente se vuelven a procesar aquellos archivos que hayan sido modificados desde la petición anterior.

Este mecanismo supone una gran ventaja respecto de otros frameworks de PHP, en los que se compilan los archivos de configuración en cada petición, incluso en producción. Al contrario de lo que sucede con Java, PHP no define un conexto de ejecución común a todas las peticiones. En otros frameworks de PHP, se produce una pérdida de rendimiento importante al procesar toda la configuración con cada petición. Gracias al sistema de cache, Symfony no sufre esta penalización ya que la pérdida de rendimiento provocada por la configuración es muy baja.

La cache de la configuración implica una consecuencia muy importante. Si se modifica la configuración en el entorno de producción, se debe forzar a Symfony a que vuelva a procesar los archivos de configuración para que se tengan en cuenta los cambios. Para ello, solo es necesario borrar la cache, borrando todos los contenidos del directorio cache/ o utilizando una tarea específica proporcionada por Symfony:

> php symfony cache:clear

Los archivos de configuración se transforman en código PHP y la mayoría de sus opciones solamente son utilizadas por el framework. Sin embargo, en ocasiones es necesario acceder a los archivos de configuración desde el código de la aplicación (en las acciones, plantillas, clases propias, etc.) Se puede acceder a todas las opciones definidas en los archivos settings.yml, app.yml y module.yml mediante una clase especial llamada sfConfig.

Desde cualquier punto del código de la aplicación se puede acceder a las opciones de configuración mediante la clase sfConfig. Se trata de un registro de opciones de configuración que proporciona un método getter que puede ser utilizado en cualquier parte del código:

// Obtiene una opción
opcion = sfConfig::get('nombre_opcion', $valor_por_defecto);

También se pueden crear o redefinir opciones desde el código de la aplicación:

// Crear una nueva opción

sfConfig::set('nombre_opcion', $valor);

El nombre de la opción se construye concatenando varios elementos y separándolos con guiones bajos en este orden:

• Un prefijo relacionado con el nombre del archivo de configuración (sf_ para settings.yml, app_ para app.yml, mod_ para module.yml)
• Si existen, todas las claves ascendentes de la opción (y en minúsculas)
• El nombre de la clave, en minúsculas

No es necesario incluir el nombre del entorno de ejecución, ya que el código PHP solo tiene acceso a los valores definidos para el entorno en el que se está ejecutando.

El listado 5-16 muestra el código necesario para acceder a los valores de las opciones definidas en el archivo app.yml mostrado en el listado 5-15.

Listado 5-15 - Ejemplo de configuración del archivo app.yml

all:
  .general:
    impuestos:    19.6
  usuario_por_defecto:
    nombre:       Juan Pérez
  email:
    webmaster:    webmaster@ejemplo.com
    contacto:     contacto@ejemplo.com
dev:
  email:
    webmaster:    otro@ejemplo.com
    contacto:     otro@ejemplo.com

Listado 5-16 - Acceso a las opciones de configuración desde el entorno de desarrollo

echo sfConfig::get('app_impuestos');   // Recuerda que se ignora el nombre de la categoría
                                       // Es decir, no es necesario incluir 'general'

=> '19.6'
echo sfConfig::get('app_usuario_por_defecto_nombre');
=> 'Juan Pérez'
echo sfConfig::get('app_email_webmaster');
=> 'otro@ejemplo.com'

echo sfConfig::get('app_email_contacto');
=> 'otro@ejemplo.com'

Las opciones de configuración de Symfony tienen todas las ventajas de las constantes PHP, pero sin sus desventajas, ya que se puede modificar su valor durante la ejecución de la aplicación.

Considerando el funcionamiento que se ha mostrado, el archivo settings.yml que se utiliza para establecer las opciones del framework en cada aplicación, es equivalente a realizar varias llamadas a la función sfConfig::set(). Así que el listado 5-17 se interpreta de la misma forma que el listado 5-18.

Listado 5-17 - Extracto del archivo de configuración settings.yml

all:
  .settings:
    csrf_secret:       false
    escaping_strategy: off
    escaping_method:   ESC_SPECIALCHARS

Listado 5-18 - Forma en la que Symfony procesa el archivo settings.yml

sfConfig::add(array(
  'sf_csrf_secret' => 'false',
  'sf_escaping_strategy' => 'false',
  'sf_escaping_method' => 'ESC_SPECIALCHARS',

));

El Capítulo 19 explica el significado de las opciones de configuración del archivo settings.yml.

El archivo app.yml, que se encuentra en el directorio miproyecto/apps/frontend/config/, contiene la mayoría de las opciones de configuración relacionadas con la aplicación. Por defecto el archivo está vacío y sus opciones se configuran para cada entorno de ejecución. En este archivo se deben incluir todas las opciones que necesiten modificarse rápidamente y se utiliza la clase sfConfig para acceder a sus valores desde el código de la aplicación. El listado 5-19 muestra un ejemplo.

Listado 5-19 - Archivo app.yml que define los tipos de tarjeta de crédito aceptados en un sitio

all:
  tarjetascredito:
    falsa:            off
    visa:             on
    americanexpress:  on
 
dev:
  tarjetascredito:
    falsa:            on

Para saber si las tarjetas de crédito falsas se aceptan en el entorno de ejecución de la aplicación, se debe utilizar la siguiente instrucción:

sfConfig::get('app_tarjetascredito_falsa');

all:
  .array:
    tarjetascredito:
      falsa:             off
      visa:              on
      americanexpress:   on

print_r(sfConfig::get('app_tarjetascredito'));
 
Array(

  [falsa] => false
  [visa] => true

  [americanexpress] => true
)

Los requerimientos de algunas aplicaciones complejas pueden dificultar el uso del archivo app.yml. En este caso, se puede almacenar la configuración en cualquier otro archivo, con el formato y la sintaxis que se prefiera y que sea procesado por un manejador realizado completamente a medida. El Capítulo 19 explica en detalle el funcionamiento de los manejadores de configuraciones.

Antes de empezar a crear los primeros archivos YAML, existen algunos trucos muy útiles que es conveniente aprender. Estos trucos permiten evitar la duplicidad de la configuración y permiten personalizar el formato YAML.

Algunas opciones de configuración dependen del valor de otras opciones. Para evitar escribir 2 veces el mismo valor, Symfony permite definir constantes dentro de los archivos YAML. Si el manejador de los archivos se encuentra con un nombre de opción todo en mayúsculas y encerrado entre los símbolos % y %, lo reemplaza por el valor que tenga en ese momento. El listado 5-20 muestra un ejemplo.

Listado 5-20 - Uso de constantes en los archivos YAML, ejemplo extraído del archivo autoload.yml

autoload:
  symfony:
    name:           symfony
    path:           %SF_SYMFONY_LIB_DIR%
    recursive:      on
    exclude:        [vendor]

El valor de la opción path es el que devuelve en ese momento la llamada a sfConfig::get('sf_symfony_lib_dir'). Si un archivo de configuración depende de otro archivo, es necesario que el archivo del que se depende sea procesado antes (en el código de Symfony se puede observar el orden en el que se procesan los archivos de configuración). El archivo app.yml es uno de los últimos que se procesan, por lo que sus opciones pueden depender de las opciones de otros archivos de configuración.

Puede ocurrir que los archivos de configuración dependan de parámetros externos (como por ejemplo una base de datos u otro archivo de configuración). Para poder procesar este tipo de casos, Symfony procesa los archivos de configuración como si fueran archivos de PHP antes de procesarlos como archivos de tipo YAML. De esta forma, como se muestra en el listado 5-21, es posible incluir código PHP dentro de un archivo YAML:

Listado 5-21 - Los archivos YAML puede contener código PHP

all:
  traduccion:
    formato:  <?php echo (sfConfig::get('sf_i18n') == true ? 'xliff' : 'none')."\n" ?>

El único inconveniente es que la configuración se procesa al principio de la ejecución de la petición del usuario, por lo que no están disponibles ninguno de los métodos y funciones de Symfony.

Además, como la instrucción echo no añade ningún retorno de carro por defecto, es necesario añadirlo explícitamente mediante \n o mediante el uso del helper echoln para cumplir con el formato YAML:

all: 
  traduccion:
    formato:  <?php echoln(sfConfig::get('sf_i18n') == true ? 'xliff' : 'none') ?>

La clase sfYaml permite procesar de forma sencilla cualquier archivo en formato YAML. Se trata de un procesador (parser) de archivos YAML que los convierte en arrays asociativos de PHP. El listado 5-22 muestra un archivo YAML de ejemplo y el listado 5-23 muestra como transformarlo en código PHP:

Listado 5-22 - Archivo de prueba llamado prueba.yml

casa:
  familia:
    apellido:      García
    padres:        [Antonio, María]
    hijos:         [Jose, Manuel, Carmen]

  direccion:
    numero:        34
    calle:         Gran Vía
    ciudad:        Cualquiera
    codigopostal:  12345

Listado 5-23 - Uso de la clase sfYaml para transformar el archivo YAML en un array asociativo

    $prueba = sfYaml::load('/ruta/a/prueba.yml');
    print_r($prueba);

 
    Array(
      [casa] => Array(
        [familia] => Array(

          [apellido] => García
          [padres] => Array(

            [0] => Antonio
            [1] => María
          )

          [hijos] => Array(
            [0] => Jose
            [1] => Manuel
            [2] => Carmen
          )

        )
        [direccion] => Array(
          [numero] => 34

          [calle] => Gran Vía
          [ciudad] => Cualquiera
          [codigopostal] => 12345

        )
      )
    )

El sistema de configuración de Symfony utiliza el lenguaje YAML por ser muy sencillo y fácil de leer. Los desarrolladores cuentan con la posibilidad de definir varios entornos de ejecución y con la opción de utilizar la configuración en cascada, lo que ofrece una gran versatilidad a su trabajo. Las opciones de configuración se pueden acceder desde el código de la aplicación mediante el objeto sfConfig, sobre todo las opciones de configuración de la aplicación que se definen en el archivo app.yml.

Aunque Symfony cuenta con muchos archivos de configuración, su ventaja es que así es más adaptable. Además, recuerda que solo las aplicaciones que requieren de una configuración muy personalizada tienen que utilizar estos archivos de configuración.

En Symfony, la capa del controlador, que contiene el código que liga la lógica de negocio con la presentación, está dividida en varios componentes que se utilizan para diversos propósitos:

• El controlador frontal es el único punto de entrada a la aplicación. Carga la configuración y determina la acción a ejecutarse.
• Las acciones contienen la lógica de la aplicación. Verifican la integridad de las peticiones y preparan los datos requeridos por la capa de presentación.
• Los objetos request, response y session dan acceso a los parámetros de la petición, las cabeceras de las respuestas y a los datos persistentes del usuario. Se utilizan muy a menudo en la capa del controlador.
• Los filtros son trozos de código ejecutados para cada petición, antes o después de una acción. Por ejemplo, los filtros de seguridad y validación son comúnmente utilizados en aplicaciones web. Puedes extender el framework creando tus propios filtros.

Este capítulo describe todos estos componentes, pero no te abrumes porque sean muchos componentes. Para una página básica, es probable que solo necesites escribir algunas líneas de código en la clase de la acción, y eso es todo. Los otros componentes del controlador solamente se utilizan en situaciones específicas.

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.

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. Carga la clase de configuración del proyecto y las librerías de Symfony.
2. Crea la configuración de la aplicación y el contexto 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.

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
 
require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');

 
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'prod', false);
sfContext::createInstance($configuration)->dispatch();

El controlador frontal incluye la configuración de la aplicación, lo que corresponde a los puntos 2, 3 y 4 anteriores. La llamada al método dispatch() del objeto sfController (que es el controlador principal de la arquitectura MVC de Symfony) despacha la petición, lo que corresponde a los puntos 5, 6 y 7 anteriores. El resto de tareas las realiza la cadena de filtros, tal y como se explica más adelante en este capítulo.

Cada entorno dispone de un controlador frontal. De hecho, es la existencia del controlador frontal lo que define un entorno. El entorno se define mediante el segundo argumento que se pasa en la llamada al método ProjectConfiguration::getApplicationConfiguration().

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 generate:app son index.php para el entorno de producción y frontend_dev.php para el entorno de desarrollo (suponiendo que tu aplicación se llame frontend). 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/frontend_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/frontend_dev.php en web/frontend_staging.php y cambia el valor del segundo argumento de ProjectConfiguration::getApplicationConfiguration() 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:    falso@misitio.com
    contacto:     falso@misitio.com
all:
  mail:
    webmaster:    webmaster@misitio.com
    contacto:     contacto@mysite.com

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

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

Las acciones son el corazón de la aplicación, puesto que contienen toda la lógica de la aplicación. Las acciones utilizan el modelo y definen variables para la vista. Cuando se realiza una petición web en una aplicación Symfony, la URL define una acción y los parámetros de la petición.

Las acciones son métodos con el nombre executeNombreAccion de una clase llamada nombreModuloActions que hereda de la clase sfActions y se encuentran agrupadas por módulos. La clase que representa las acciones de un módulo se encuentra en el archivo actions.class.php, en el directorio actions/ del módulo.

El listado 6-3 muestra un ejemplo de un archivo actions.class.php con una única acción index para todo el módulo mimodulo.

Listado 6-3 - Ejemplo de la clase de la acción, en app/frontend/modules/mimodulo/actions/actions.class.php

class mimoduloActions extends sfActions
{
  public function executeIndex()

  {
    // ...
  }
}

Para ejecutar un acción, se debe llamar al script del controlador frontal con el nombre del módulo y de la acción como parámetros. Por defecto, se añade nombre_modulo/nombre_accion al script. Esto significa que la acción del listado 6-3 se puede ejecutar llamándola con la siguiente URL:

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

Añadir más acciones simplemente significa agregar más métodos execute al objeto sfActions, como se muestra en el listado 6-4.

Listado 6-4 - Clase con dos acciones, en frontend/modules/mimodulo/actions/actions.class.php

class mimoduloActions extends sfActions
{
  public function executeIndex()

  {
    // ...
  }
 
  public function executeListar()

  {
    // ...
  }
}

Si el tamaño de la clase de la acción crece demasiado, probablemente tendrás que refactorizar la clase para mover algo de codigo a la capa del modelo. El código de las acciones debería ser muy corto (no mas que una pocas líneas), y toda la lógica del negocio debería encontrarse en el modelo.

Aun así, el número de acciones en un módulo puede llegar a ser tan importante que sea necesario dividirlas en 2 módulos.

Se puede utilizar una sintaxis alternativa para distribuir las acciones en archivos separados, un archivo por acción. En este caso, cada clase acción extiende sfAction (en lugar de sfActions) y su nombre es nombreAccionAction. El nombre del método es simplemente execute. El nombre del archivo es el mismo que el de la clase. Esto significa que el equivalente del Listado 6-4 puede ser escrito en dos archivos mostrados en los listados 6-5 y 6-6.

Listado 6-5 - Archivo de una sola acción, en frontend/modules/mimodulo/actions/indexAction.class.php

class indexAction extends sfAction
{
  public function execute($peticion)

  {
    // ...
  }
}

Listado 6-6 - Archivo de una sola acción, en frontend/modules/mimodulo/actions/listAction.class.php

class listarAction extends sfAction
{
  public function execute($peticion)

  {
    // ...
  }
}

Las clases de las acciones ofrecen un método para acceder a la información relacionada con el controlador y los objetos del núcleo de Symfony. El listado 6-7 muestra como utilizarlos.

Listado 6-7 - Métodos comunes de sfActions

class mimoduloActions extends sfActions
{

  public function executeIndex($peticion)
  {
    // Obteniendo parametros de la petición
    $password      = $peticion->getParameter('password');

 
    // Obteniendo información del controlador
    $nombreModulo  = $this->getModuleName();
    $nombreAccion  = $this->getActionName();

 
    // Obteniendo objetos del núcleo del framework
    $sesionUsuario = $this->getUser();
    $respuesta     = $this->getResponse();
    $controlador   = $this->getController();
    $contexto      = $this->getContext();

 
    // Creando variables de la acción para pasar información a la plantilla
    $this->setVar('parametro', 'valor');
    $this->parametro = 'valor';           // Versión corta.

  }
}

Existen varias alternativas posibles cuando se termina la ejecución de una acción. El valor retornado por el método de la acción determina como será producida la vista. Para especificar la plantilla que se utiliza al mostrar el resultado de la acción, se emplean las constantes de la clase sfView.

Si existe una vista por defecto que se debe llamar (este es el caso más común), la acción debería terminar de la siguiente manera:

return sfView::SUCCESS;

Symfony buscará entonces una plantilla llamada nombreAccionSuccess.php. Este comportamiento se ha definido como el comportamiento por defecto, por lo que si omites la sentencia return en el método de la acción, Symfony también buscará una plantilla llamada nombreAccionSuccess.php. Las acciones vacías también siguen este comportamiento. El listado 6-8 muestra un ejemplo de terminaciones exitosas de acciones.

Listado 6-8 - Acciones que llaman a las plantillas indexSuccess.php y listarSuccess.php

public function executeIndex()

{
  return sfView::SUCCESS;
}
 
public function executeListar()

{
}

Si existe una vista de error que se debe llamar, la acción deberá terminar de la siguiente manera:

return sfView::ERROR;

Symonfy entonces buscará un plantilla llamada nombreAccionError.php.

Para utilizar una vista personalizada, se debe utilizar el siguiente valor de retorno:

return 'MiResultado';

Symfony entonces buscará una plantilla llamada nombreAccionMiResultado.php.

Si no se utiliza ninguna vista --por ejemplo, en el caso de una acción ejecutada en un archivo de lotes-- la acción debe terminar de la siguiente forma:

return sfView::NONE;

En este caso, no se ejecuta ninguna plantilla. De esta forma, se evita por completo la capa de vista y se establece directamente el código HTML producido por la acción. Como muestra el Listado 6-9, Symfony provee un método renderText() específico para este caso. Este método puede ser útil cuando se necesita una respuesta muy rápida en una acción, como por ejemplo para las interacciones creadas con Ajax, como se verá en el Capítulo 11.

Listado 6-9 - Evitando la vista mediante una respuesta directa y un valor de retorno sfView::NONE

public function executeIndex()
{
  $this->getResponse()->setContent("<html><body>¡Hola Mundo!</body></html>");

 
  return sfView::NONE;
}
 
// Es equivalente a
public function executeIndex()

{
  return $this->renderText("<html><body>¡Hola Mundo!</body></html>");

}

En algunos casos, se necesita una respuesta vacía pero con algunas cabeceras definidas (sobre todo la cabecera X-JSON). Para conseguirlo, se definen las cabeceras con el objeto sfResponse, que se ve en el próximo capítulo, y se devuelve como valor de retorno la constante sfView::HEADER_ONLY, como muestra el Listado 6-10.

Listado 6-10 - Evitando la producción de la vista y enviando solo cabeceras

public function executeActualizar()

{
  $salida = '<"titulo","Mi carta sencilla"],["nombre","Sr. Pérez">';
  $this->getResponse()->setHttpHeader("X-JSON", '('.$salida.')');

 
  return sfView::HEADER_ONLY;
}

Si la acción debe ser producida por una plantilla específica, se debe prescindir de la sentencia return y se debe utilizar el método setTemplate() en su lugar.

$this->setTemplate('miPlantillaPersonalizada');

En algunos casos, la ejecución de un acción termina solicitando la ejecución de otra acción. Por ejemplo, una acción que maneja el envío de un formulario en una solicitud POST normalmente redirecciona a otra acción después de actualizar la base de datos. Otro ejemplo es el de crear un alias de una acción: la acción index normalmente se utiliza para mostrar un listado y de hecho se suele redireccionar a la acción list.

La clase de la acción provee dos métodos para ejecutar otra acción:

• Si la acción pasa la llamada hacia otra acción (forward):

$this->forward('otroModulo', 'index');

• Si la acción produce un redireccionamiento web (redirect):

$this->redirect('otroModulo/index');
$this->redirect('http://www.google.com/');

La elección entre redirect y forward es a veces engañosa. Para elegir la mejor solución, ten en cuenta que un forward es una llamada interna a la aplicación y transparente para el usuario. En lo que concierne al usuario, la URL mostrada es la misma que la solicitada. Por el contrario, un redirect resulta en un mensaje al navegador del usuario, involucrando una nueva petición por parte del mismo y un cambio en la URL final resultante.

Si la acción es llamada desde un formulario enviado con method="post", deberías siempre realizar un redirect. La principal ventaja es que si el usuario recarga la página resultante, el formulario no será enviado nuevamente; además, el botón de retroceder funciona como se espera, ya que muestra el formulario y no una alerta preguntando al usuario si desea reenviar una petición POST.

Existe un tipo especial de forward que se utiliza comúnmente. El método forward404() redirecciona a una acción de Página no encontrada. Este método se utiliza normalmente cuando un parámetro necesario para la ejecución de la acción no está presente en la petición (por tanto detectando una URL mal escrita). El Listado 6-11 muestra un ejemplo de una acción mostrar que espera un parámetro llamado id.

Listado 6-11 - Uso del método forward404()

public function executeVer($peticion)
{

  $articulo = ArticuloPeer::retrieveByPK($peticion->getParameter('id'));
  if (!$articulo)

  {
    $this->forward404();
  }
}

La experiencia muestra que, la mayoría de las veces, una acción hace un redirect o un forward después de probar algo, como en el listado 6-12. Por este motivo, la clase sfActions tiene algunos métodos más, llamados forwardIf(), forwardUnless(), forward404If(), forward404Unless(), redirectIf() y redirectUnless(). Estos métodos simplemente requieren un parámetro que representa la condición cuyo resultado se emplea para ejecutar el método. El método se ejecuta si el resultado de la condición es true y el método es de tipo xxxIf() o si el resultado de la condición es false y el método es de tipo xxxUnless(), como se muestra en el listado 6-12.

Listado 6-12 - Uso del método forward404If()

// Esta acción es equivalente a la mostrada en el Listado 6-11
public function executeVer($peticion)

{
  $articulo = ArticuloPeer::retrieveByPK($peticion->getParameter('id'));
  $this->forward404If(!$articulo);

}
 
// Esta acción también es equivalente
public function executeVer()
{
  $articulo = ArticuloPeer::retrieveByPK($peticion->getParameter('id'));
  $this->forward404Unless($articulo);

}

El uso de estos métodos permite mantener el código de las acciones muy corto y también lo hacen más fácil de leer.

La convención en el nombre de las acciones executeNombreAccion() (en el caso de una clase de tipo sfActions) o execute() (en el caso de una clase sfAction) garantiza que Symfony encontrará el método de la acción. Además, permite crear métodos propios que no serán considerados como acciones, siempre que su nombre no empiece con execute.

Existe otra convención útil cuando se necesita ejecutar repetidamente en cada acción una serie de sentencias antes de ejecutar la propia acción. Esas sentencias comunes se pueden colocar en el método preExecute() de la clase de la acción. De forma análoga, se pueden definir sentencias que se ejecuten después de cada acción añadiéndolas al método postExecute(). La sintaxis de estos métodos se muestra en el Listado 6-13.

Listado 6-13 - Usando los métodos preExecute(), postExecute() y otros métodos propios en la clase de la acción

class mimoduloActions extends sfActions
{
  public function preExecute()

  {
    // El código insertado aquí se ejecuta al principio de cada llamada a una acción
    // ...
  }
 
  public function executeIndex($peticion)

  {
    // ...
  }
 
  public function executeListar($peticion)

  {
    // ...
    $this->miPropioMetodo();  // Se puede acceder a cualquier método de la clase acción
  }

 
  public function postExecute()
  {
    // El código insertado aquí se ejecuta al final de cada llamada a la acción
    ...
  }

 
  protected function miPropioMetodo()
  {
    // Se pueden crear métodos propios, siempre que su nombre no comience por "execute" 
    // En ese case, es mejor declarar los métodos como protected o private

    // ...
  }
}

El primer argumento de cualquier método que ejecuta una acción es el objeto que representa a la petición, llamada sfWebRequest en Symfony. De todos sus métodos, ya se ha mostrado el método getParameter('miparametro') para obtener el valor de un parámetro de la petición a partir de su nombre. La tabla 6-1 resume algunos de los métodos más útiles de sfWebRequest.

Tabla 6-1. Métodos del objeto sfWebRequest

(1) Funciona con Prototype, Mootools y jQuery (2) Si se utilizan proxys, su valor puede ser inaccesible

Para peticiones de tipo multipart utilizadas cuando el usuario adjunta archivos, el objeto sfWebRequest provee métodos para acceder y mover estos archivos, como se muestra en el listado 6-14. Sin embargo, estos métodos han sido declarados como obsoletos en Symfony 1.1 (puedes ver más información en la sección de formularios y en la clase sfValidatorFile).

Listado 6-14 - El objeto sfWebRequest sabe cómo manejar archivos adjuntos

class mimoduloActions extends sfActions
{
  public function executeSubirArchivos($peticion)

  {
    if ($peticion->hasFiles())
    {

      foreach ($peticion->getFileNames() as $archivoSubido)
      {

        $nombreArchivo     = $peticion->getFileName($archivoSubido);
        $tamanoArchivo     = $peticion->getFileSize($archivoSubido);
        $tipoArchivo       = $peticion->getFileType($archivoSubido);
        $archivoErroneo    = $peticion->hasFileError($archivoSubido);
        $directorioSubidas = sfConfig::get('sf_upload_dir');
        $peticion->moveFile($archivoSubido, $directorioSubidas.'/'.$nombreArchivo);
      }

    }
  }
}

No tienes que preocuparte sobre si el servidor soporta las variables de PHP $_SERVER o $_ENV, o acerca de valores por defecto o problemas de compatibilidad del servidor, ya que los métodos de 'sfWebRequest lo hacen todo por tí. Además sus nombres son tan evidentes que no es necesario consultar la documentación de PHP para descubrir cómo obtener información sobre la petición.

Symfony maneja automáticamente las sesiones del usuario y es capaz de almacenar datos de forma persistente entre peticiones. Utiliza el mecanismo de manejo de sesiones incluido en PHP y lo mejora para hacerlo mas configurable y más fácil de usar.

El objeto sesión del usuario actual se accede en la acción con el método getUser(), que es una instancia de la clase sfUser. Esta clase dispone de un contenedor de parámetros que permite guardar cualquier atributo del usuario en el. Esta información estará disponible en otras peticiones hasta terminar la sesión del usuario, como se muestra en el Listado 6-15. Los atributos de usuarios pueden guardar cualquier tipo de información (cadenas de texto, arrays y arrays asociativos). Se pueden utilizar para cualquier usuario, incluso si ese usuario no se ha identificado.

Listado 6-15 - El objeto sfUser puede contener atributos personalizados del usuario disponibles en todas las peticiones

class mimoduloActions extends sfActions
{
  public function executePrimeraPagina($peticion)

  {
    $nombre = $peticion->getParameter('nombre');
 
    // Guardar información en la sesión del usuario

    $this->getUser()->setAttribute('nombre', $nombre);
  }
 

  public function executeSegundaPagina()
  {
    // Obtener información de la sesión del usuario con un valor por defecto
    $nombre = $this->getUser()->getAttribute('nombre', 'Anónimo');
  }

}

Como muchos otros getters en Symfony, el método getAttribute() acepta un segundo parámetro, especificando el valor por defecto a ser utilizado cuando el atributo no está definido. Para verificar si un atributo ha sido definido para un usuario, se utiliza el método hasAttribute(). Los atributos se guardan en un contenedor de parámetros que puede ser accedido por el método getAttributeHolder(). También permite un borrado rápido de los atributos del usuario con los métodos usuales del contenedor de parámetros, como se muestra en el listado 6-16.

Listado 6-16 - Eliminando información de la sesión del usuario

class mimoduloActions extends sfActions

{
  public function executeBorraNombre()
  {
    $this->getUser()->getAttributeHolder()->remove('nombre');
  }

 
  public function executeLimpia()
  {
    $this->getUser()->getAttributeHolder()->clear();
  }

}

Los atributos de la sesión del usuario también están disponibles por defecto en las plantillas mediante la variable $sf_user, que almacena el objeto sfUser actual, como se muestra en el listado 6-17.

Listado 6-17 - Las plantillas también tienen acceso a los atributos de la sesión del usuario

<p>

  Hola, <?php echo $sf_user->getAttribute('nombre') ?>
</p>

Un problema recurrente con los atributos del usuario es la limpieza de la sesión del usuario una vez que el atributo no se necesita más. Por ejemplo, puede ser necesario mostrar un mensaje de confirmación después de actualizar información mediante un formulario. Como la acción que maneja el formulario realiza una redirección, la única forma de pasar información desde esta acción a la acción que ha sido redireccionada es almacenar la información en la sesión del usuario. Pero una vez que se muestra el mensaje, es necesario borrar el atributo; ya que de otra forma, permanecerá en la sesión hasta que esta expire.

El atributo de tipo flash es un atributo fugaz que permite definirlo y olvidarse de el, sabiendo que desaparece automáticamente después de la siguiente petición y que deja la sesión limpia para las futuras peticiones. En la acción, se define el atributo flash de la siguiente manera:

$this->getUser()->setFlash('atributo', $valor);

La plantilla se procesa y se envía al usuario, quien después realiza una nueva petición hacia otra acción. En esta segunda acción, es posible obtener el valor del atributo flash de esta forma:

$valor = $this->getUser()->getFlash('atributo');

Luego ya te puedes olvidar de ese parámetro. Después de mostrar la segunda página, el atributo flash llamado atributo desaparece automáticamente. Incluso si no se utiliza el atributo durante la segunda acción, el atributo desaparece igualmente de la sesión.

Si necesitas acceder a un atributo flash desde la plantilla, puedes utilizar el objeto $sf_user:

<?php if ($sf_user->hasFlash('atributo')): ?>

  <?php echo $sf_user->getFlash('atributo') ?>
<?php endif; ?>

O simplemente:

<?php echo $sf_user->getFlash('atributo') ?>

Los atributos de tipo flash son una forma limpia de pasar información a la próxima petición.

El manejo de sesiones de Symfony se encarga de gestionar automáticamente el almacenamiento de los IDs de sesión tanto en el cliente como en el servidor. Sin embargo, si se necesita modificar este comportamiento por defecto, es posible hacerlo. Se trata de algo que solamente lo necesitan los usuarios más avanzados.

En el lado del cliente, las sesiones son manejadas por cookies. La cookie de Symfony se llama Symfony, pero se puede cambiar su nombre editando el archivo de configuración factories.yml, como se muestra en el Listado 6-18.

Listado 6-18 - Cambiando el nombre de la cookie de sesión, en apps/frontend/config/factories.yml

all:
  storage:
    class: sfSessionStorage
    param:
      session_name: mi_nombre_cookie

El manejo de sesiones de Symfony esta basado en las sesiones de PHP. Por tanto, si la gestión de la sesión en la parte del cliente se quiere realizar mediante parámetros en la URL en lugar de cookies, se debe modificar el valor de la directiva use_trans_sid en el archivo de configuración php.ini. No obstante, se recomienda no utilizar esta técnica.

session.use_trans_sid = 1

En el lado del servidor, Symfony guarda por defecto las sesiones de usuario en archivos. Se pueden almacenar en la base de datos cambiando el valor del parámetro class en factories.yml, como se muestra en el Listado 6-19.

Listado 6-19 - Cambiando el almacenamiento de las sesiones en el servidor, en apps/frontend/config/factories.yml

all:
  storage:
    class: sfMySQLSessionStorage
    param:
      db_table:    session              # Nombre de la tabla que guarda las sesiones
      database:    propel               # Nombre de la conexión a base de datos que se utiliza
      # Parámetros opcionales
      db_id_col:   sess_id              # Nombre de la columna que guarda el identificador de la sesión
      db_data_col: sess_data            # Nombre de la columna que guarda los datos de la sesión

      db_time_col: sess_time            # Nombre de la columna que guarda el timestamp de la sesión

La opción database define el nombre de la conexión a base de datos que se utiliza. Posteriormente, Symfony utiliza el archivo databases.yml (ver capítulo 8) para determinar los parámetros con los que realiza la conexión (host, nombre de la base de datos, usuario y password).

Las clases disponibles para el almacenamiento de sesiones son sfMySQLSessionStorage, sfMySQLiSessionStorage, sfPostgreSQLSessionStorage y sfPDOSessionStorage. La clase recomendada es sfPDOSessionStorage. Para deshabilitar completamente el almacenamiento de las sesiones, se puede utilizar la clase sfNoStorage.

La expiración de la sesión se produce automáticamente después de 30 minutos. El valor de esta opción se puede modificar para cada entorno en el mismo archivo de configuración factories.yml, concretamente en la factoría correspondiente al usuario (user), tal y como muestra el listado 6-20.

Listado 6-20 - Cambiando el tiempo de vida de la sesión, en apps/frontend/config/factories.yml

all:
  user:
    class:       myUser
    param:
      timeout:   1800           # Tiempo de vida de la sesión en segundos

El capítulo 19 explica detalladamente todas las opciones de las factorías.

La posibilidad de ejecutar una acción puede ser restringida a usuarios con ciertos privilegios. Las herramientas proporcionadas por Symfony para este propósito permiten la creación de aplicaciones seguras, en las que los usuarios necesitan estar autenticados antes de acceder a alguna característica o a partes de la aplicación. Añadir esta seguridad a una aplicación requiere dos pasos: declarar los requerimientos de seguridad para cada acción y autenticar a los usuarios con privilegios para que puedan acceder estas acciones seguras.

Antes de ser ejecutada, cada acción pasa por un filtro especial que verifica si el usuario actual tiene privilegios de acceder a la acción requerida. En Symfony, los privilegios estan compuestos por dos partes:

• Las acciones seguras requieren que los usuarios esten autenticados.
• Las credenciales son privilegios de seguridad agrupados bajo un nombre y que permiten organizar la seguridad en grupos.

Para restringir el acceso a una acción se crea y se edita un archivo de configuración YAML llamado security.yml en el directorio config/ del módulo. En este archivo, se pueden especificar los requerimientos de seguridad que los usuarios deberán satisfacer para cada acción o para todas (all) las acciones. El listado 6-21 muestra un ejemplo de security.yml.

Listado 6-21 - Estableciendo restricciones de acceso, en apps/frontend/modules/mimodulo/config/security.yml

ver:
  is_secure:   off       # Todos los usuarios pueden ejecutar la acción "ver"
 

modificar:
  is_secure:   on        # La acción "modificar" es sólo para usuarios autenticados
 
borrar:
  is_secure:   on        # Sólo para usuarios autenticados
  credentials: admin     # Con credencial "admin"
 
all:
  is_secure:  off        # off es el valor por defecto

Las acciones no incluyen restricciones de seguridad por defecto, asi que cuando no existe el archivo security.yml o no se indica ninguna acción en ese archivo, todas las acciones son accesibles por todos los usuarios. Si existe un archivo security.yml, Syfmony busca por el nombre de la acción y si existe, verifica que se satisfagan los requerimientos de seguridad. Lo que sucede cuando un usuario trata de acceder una acción restringida depende de sus credenciales:

• Si el usuario está autenticado y tiene las credenciales apropiadas, entonces la acción se ejecuta.
• Si el usuario no está autenticado, es redireccionado a la acción de login.
• Si el usuario está autenticado, pero no posee las credenciales apropiadas, será redirigido a la acción segura por defecto, como muestra la figura 6-1.

Las páginas login y secure son bastante simples, por lo que seguramente será necesario personalizarlas. Se puede configurar que acciones se ejecutan en caso de no disponer de suficientes privilegios en el archivo settings.yml de la aplicación cambiando el valor de las propiedades mostradas en el listado 6-22.

Figura 6.1. La página por defecto de la acción ''secure''

Listado 6-22 - Las acciones de seguridad por defecto se definen en apps/frontend/config/settings.yml

all:
  .actions:
    login_module:  default
    login_action:  login
 
    secure_module: default
    secure_action: secure

Para obtener acceso a áreas restringidas, los usuarios necesitan estar autenticados y/o poseer ciertas credenciales. Puedes extender los privilegios del usuario mediante llamadas a métodos del objeto sfUser. El estado autenticado se establece con el método setAuthenticated() y se puede comprobar con el método isAuthenticated(). El listado 6-23 muestra un ejemplo sencillo de autenticación.

Listado 6-23 - Estableciendo el estado de autenticación del usuario

class miCuentaActions extends sfActions
{
  public function executeLogin($peticion)

  {
    if ($peticion->getParameter('login') == 'valor')

    {
      $this->getUser()->setAuthenticated(true);
    }

  }
 
  public function executeLogout()
  {
    $this->getUser()->setAuthenticated(false);
  }

}

Las credenciales son un poco más complejas de tratar, ya que se pueden verificar, agregar, quitar y borrar. El listado 6-24 describe los métodos de las credenciales de la clase sfUser.

Listado 6-24 - Manejando las credenciales del usuario en la acción

class miCuentaActions extends sfActions

{
  public function executeEjemploDeCredenciales()
  {
    $usuario = $this->getUser();

 
    // Agrega una o más credenciales
    $usuario->addCredential('parametro');
    $usuario->addCredentials('parametro', 'valor');

 
    // Verifica si el usuario tiene una credencial
    echo $usuario->hasCredential('parametro');                         => true

 
    // Verifica si un usuario tiene una de las credenciales
    echo $usuario->hasCredential(array('parametro', 'valor'));         => true

 
    // Verifica si el usuario tiene ambas credenciales
    echo $usuario->hasCredential(array('parametro', 'valor'), true);   => true

 
    // Quitar una credencial
    $usuario->removeCredential('parametro');
    echo $usuario->hasCredential('parametro');                         => false

 
    // Elimina todas las credenciales (útil en el proceso de logout)
    $usuario->clearCredentials();
    echo $usuario->hasCredential('valor');                             => false

  }
}

Si el usuario tiene la credencial "parametro", entonces ese usuario podrá acceder a las acciones para las cuales el archivo security.yml requiere esa credencial. Las credenciales se pueden utilizar también para mostrar contenido autenticado en una plantilla, como se muestra en el listado 6-25.

Listado 6-25 - Tratando con credenciales de usuario en una plantilla

<ul>
  <li><?php echo link_to('seccion1', 'content/seccion1') ?></li>

  <li><?php echo link_to('seccion2', 'content/seccion2') ?></li>
  <?php if ($sf_user->hasCredential('seccion3')): ?>

  <li><?php echo link_to('seccion3', 'content/seccion3') ?></li>
  <?php endif; ?>

</ul>

Y para el estado de autenticación, las credenciales normalmente se dan a los usuarios durante el proceso de login. Este es el motivo por el que el objeto sfUser normalmente se extiende para añadir métodos de login y de logout, de forma que se pueda establecer el estado de seguridad del usuario de forma centralizada.

La sintaxis YAML utilizada en el archivo security.yml permite restringir el acceso a usuarios que tienen una combinación de credenciales, usando asociaciones de tipo AND y OR. Con estas combinaciones, se pueden definir flujos de trabajo y sistemas de manejo de privilegios muy complejos -- como por ejemplo, un sistema de gestión de contenidos (CMS) cuya parte de gestión sea accesible solo a usuarios con credencial admin, donde los artículos pueden ser editados solo por usuarios con credenciales de editor y publicados solo por aquellos que tienen credencial de publisher. El listado 6-26 muestra este ejemplo.

Listado 6-26 - Sintaxis de combinación de credenciales

editarArticulo:
  credentials: [ admin, editor ]              # admin AND editor
 
publicarArticulo:
  credentials: [ admin, publisher ]           # admin AND publisher

 
gestionUsuarios:
  credentials: [[ admin, superuser ]]         # admin OR superuser

Cada vez que se añade un nuevo nivel de corchetes, la lógica cambia entre AND y OR. Así que se pueden crear combinaciones muy complejas de credenciales, como la siguiente:

credentials: [[root, [supplier, [owner, quasiowner]], accounts]]

             # root OR (supplier AND (owner OR quasiowner)) OR accounts

La validación de los datos de la acción -normalmente los parámetros de la petición- es una tarea repetitiva y tediosa. Symfony incluye un sistema de validación, utilizando métodos de la clase acción.

Se ve en primer lugar un ejemplo. Cuando un usuario hace una petición a miAccion, Symfony siempre busca primero un método llamado validateMiAccion(). Si lo encuentra, Symfony ejecuta ese método. El valor de retorno de esta validación determina el siguiente método que se ejecuta: si devuelve true, entonces se ejecuta el método executeMiAccion(); en otro caso, se ejecuta handleErrorMiAccion(). En el caso de que handleErrorMiAccion() no exista, Symfony busca un método genérico llamado handleError(). Si tampoco existe, simplemente devuelve el valor sfView::ERROR para producir la plantilla miAccionError.php. La Figura 6-2 ilustra este proceso.

Figura 6.2. El proceso de validación

La clave para un correcto funcionamiento de la validación es respetar la convención de nombres para los métodos de la acción:

• validateNombreAccion es el método de validación, que devuelve true o false. Se trata del primer método buscado cuando se solicita la acción NombreAccion. Si no existe, la acción se ejecuta directamente.
• handleErrorNombreAccion es el método llamado cuando el método de validación falla. Si no existe, entonces se muestra la plantilla Error.
• executeNombreAccion es el método de la acción. Debe existir para todoas las acciones.

El listado 6-27 muestra un ejemplo de una acción con métodos de validación. Independientemente de si la validación falla o no falla, en el siguiente ejemplo se ejecuta la plantilla miAccionSuccess.php pero no con los mismos parámetros.

Listado 6-27 - Ejemplo de métodos de validación

class mimoduloActions extends sfActions
{
  public function validateMiAccion($peticion)

  {
    return $peticion->getParameter('id') > 0;
  }

 
  public function handleErrorMiAccion()
  {
    $this->message = "Parámetros no válidos";

 
    return sfView::SUCCESS;
  }
 
  public function executeMiAccion()

  {
    $this->message = "Los parámetros son válidos";
  }
}

Se puede incluir cualquier código en el método validate(). La única condición es que devuelva un valor true o false. Como es un método de la clase sfActions, tiene acceso a los objetos sfRequest y sfUser, que pueden ser realmente útiles para validación de los datos de la petición y del contexto.

Se pueden utilizar este mecanismo para implementar la validación de los formularios (esto es, controlar los valores introducidos por el usuario en un formulario antes de procesarlo), pero se trata de una tarea muy repetitiva para la que Symfony proporciona herramientas automatizadas, como las descritas en el Capítulo 10.

El mecanismo de seguridad puede ser entendido como un filtro, por el que debe pasar cada petición antes de ejecutar la acción. Según las comprobaciones realizadas en el filtro, se puede modificar el procesamiento de la petición --por ejemplo, cambiando la acción ejecutada (default/secure en lugar de la acción solicitada en el caso del filtro de seguridad). Symfony extiende esta idea a clases de filtros. Se puede especificar cualquier número de clases de filtros a ser ejecutadas antes de que se procese la respuesta, y además hacerlo de forma sistemática para todas las peticiones. Se pueden entender los filtros como una forma de empaquetar cierto código de forma similar a preExecute() y postExecute(), pero a un nivel superior (para toda una aplicación en lugar de para todo un módulo).

Symfony de hecho procesa cada petición como una cadena de filtros ejecutados de forma sucesiva. Cuando el framework recibe una petición, se ejecuta el primer filtro (que siempre es sfRenderingFilter). En algún punto, llama al siguiente filtro en la cadena, luego el siguiente, y asi sucesivamente. Cuando se ejecuta el último filtro (que siempre es sfExecutionFilter), los filtros anteriores pueden finalizar, y asi hasta el filtro de sfRenderingFilter. La Figura 6-3 ilustra esta idea con un diagrama de secuencias, utilizando una cadena de filtros simplificada (la cadena real tiene muchos más filtros).

Figura 6.3. Ejemplo de cadena de filtros

Este proceso es la razón de la estructura de la clases de tipo filtro. Todas estas clases extienden la clase sfFilter y contienen un método execute() que espera un objeto de tipo $filterChain como parámetro. En algún punto de este método, el filtro pasa al siguiente filtro en la cadena, llamando a $filterChain->execute(). El listado 6-28 muestra un ejemplo. Por lo tanto, los filtros se dividen en dos partes:

• El código que se encuentra antes de la llamada a $filterChain->execute() se ejecuta antes de que se ejecute la acción.
• El código que se encuentra después de la llamada a $filterChain->execute() se ejecuta después de la acción y antes de producir la vista.

Listado 6-28 - Estructura de la clase filtro

class miFiltro extends sfFilter
{
  public function execute ($filterChain)

  {
    // Código que se ejecuta antes de la ejecución de la acción
    ...
 
    // Ejecutar el siguiente filtro de la cadena
    $filterChain->execute();

 
    // Código que se ejecuta después de la ejecuciñon de la acción y antes de que se genere la vista
    ...
  }
}

La cadena de filtros por defecto se define en el archivo de configurarcion de la aplicación filters.yml, y su contenido se muestra en el listado 6-29. Este archivo lista los filtros que se ejecutan para cada petición.

Listado 6-29 - Cadena de filtros por defecto, en frontend/config/filters.yml

rendering: ~
security:  ~
 
# Normalmente los filtros propios se insertan aqui
 
cache:     ~
common:    ~
execution: ~

Estas declaraciones no tienen parámetros (el caracter tilde, ~, significa null en YAML), porque heredan los parámetros definidos en el núcleo de Symfony. En su núcleo, Symfony define las opciones class y param para cada uno de estos filtros. Por ejemplo, el listado 6-30 muestra los parámetros por defecto para el filtro rendering.

Listado 6-30 - Parámetros por defecto del filtro sfRenderingFilter, en $sf_symfony_lib_dir/config/config/filters.yml

rendering:
  class: sfRenderingFilter   # Clase del filtro
  param:                     # Parámetros del filtro
    type: rendering

Si se deja el valor vacío (~) en el archivo filters.yml de la aplicación, Symfony aplica el filtro con las opciones por defecto definidas en su núcleo.

Se pueden personalizar la cadenas de filtros en varias formas:

• Desactivando algún filtro de la cadena agregando un parámetro enabled: off. Para desactivar por ejemplo el filtro common, que se encarga de añadir los archivos CSS y JavaScript en la cabecera de la página, se añade la siguiente opción:

common:
  enabled: off

• No se deben borrar las entradas del archivo filters.yml para desactivar un filtro ya que Symfony lanzará una excepción.
• Se pueden añadir declaraciones propias en cualquier lugar de la cadena (normalmente después del filtro security) para agregar un filtro propio (como se verá en la próxima sección). En cualquier caso, el filtro rendering debe ser siempre la primera entrada, y el filtro execution debe ser siempre la ultima entrada en la cadena de filtros.
• Redefinir la clase y los parámetros por defecto del filtro por defecto (normalmente para modificar el sistema de seguridad y utilizar un filtro de seguridad propio).

Construir un filtro propio es bastante sencillo. Se debe crear una definición de una clase similar a la demostrada en el listado 6-28, y se coloca en uno de los directorios lib/ del proyecto para aprovechar la carga automática de clases.

Como una acción puede pasar el control o redireccionar hacia otra acción y en consecuencia relanzar toda la cadena de filtros, quizás sea necesario restringir la ejecución de los filtros propios a la primera acción de la petición. El método isFirstCall() de la clase sfFilter retorna un valor booleano con este propósito. Esta llamada solo tiene sentido antes de la ejecución de una acción.

Este concepto se puede entender fácilmente con un ejemplo. El listado 6-31 muestra un filtro utilizado para auto-loguear a los usuarios con una cookie MiSitioWeb, que se supone que se crea en la acción login. Se trata de una forma rudimentaria pero que funciona para incluir la característica Recuérdame de un formulario de login.

Listado 6-31 - Ejemplo de archivo de clase de filtro, en apps/frontend/lib/rememberFilter.class.php

class rememberFilter extends sfFilter
{
  public function execute($filterChain)

  {
    // Ejecutar este filtro solo una vez
    if ($this->isFirstCall())

    {
      // Los filtros no tienen acceso directo a los objetos user y request.
      // Se necesita el contexto para obtenerlos
      $peticion = $this->getContext()->getRequest();
      $usuario  = $this->getContext()->getUser();

 
      if ($peticion->getCookie('MiSitioWeb'))
      {
        // logueado 

        $usuario->setAuthenticated(true);
      }
    }
 
    // Ejecutar el proximo filtro

    $filterChain->execute();
  }
}

En ocasiones, en lugar de continuar con la ejecución de la cadena de filtros, se necesita pasar el control a una acción específica al final de un filtro. sfFilter no tiene un método forward(), pero sfController si, por lo que simplemente se puede llamar al siguiente método:

return $this->getContext()->getController()->forward('mimodulo', 'miAccion');

Crear un filtro no es suficiente para activarlo. Se necesita agregar el filtro propio a la cadena, y para eso, se debe declar la clase del filtro en el archivo filters.yml, localizado en el directorio config/de la aplicación o del módulo, como se muestra en el listado 6-32.

Listado 6-32 - Ejemplo de archivo de activación de filtro, en apps/frontend/config/filters.yml

rendering: ~
security:  ~
 
remember:                 # Los filtros requieren un nombre único
  class: rememberFilter
  param:
    cookie_name: MiSitioWeb
    condition:   %APP_ENABLE_REMEMBER_ME%
 
cache:     ~
common:    ~
execution: ~

Cuando se encuentra activo, el filtro se ejecuta en cada petición. El archivo de configuración de los filtros puede contener una o más definiciones de parámetros en la sección param. La clase filtro puede obtener estos parámetros con el método getParameter(). El listado 6-33 muestra como obtener los valores de los parámetros.

Listado 6-33 - Obteniendo el valor del parámetro, en apps/frontend/lib/rememberFilter.class.php

class rememberFilter extends sfFilter
{
  public function execute($filterChain)

  {
    // ...
 
    if ($request->getCookie($this->getParameter('cookie_name')))

    {
      // ...
    }
 
    // ...
  }
}

El parámetro condition se comprueba en la cadena de filtros para ver si el filtro debe ser ejecutado. Por lo que las declaraciones del filtro propio puede basarse en la configuración de la aplicación, como muestra el listado 6-32. El filtro remeber se ejecuta solo si el archivo app.yml incluye lo siguiente:

all:
  enable_remember_me: on

Los filtros son útiles para repetir cierto código en todas las acciones. Por ejemplo, si se utiliza un sistema remoto de estadísticas, puede ser necesario añadir un trozo de código que realice una llamada a un script de las estadísticas en cada página. Este código se puede colocar en el layout global, pero entonces estaría activo para toda la aplicación. Otra forma es colocarlo en un filtro, como se muestra el listado 6-34, y activarlo en cada módulo.

Listado 6-34 - Filtro para el sistema de estadísticas de Google Analytics

class sfGoogleAnalyticsFilter extends sfFilter

{
  public function execute($filterChain)
  {
    // No se hace nada antes de la acción

    $filterChain->execute();
 
    // Decorar la respuesta con el código de Google Analytics
    $codigoGoogle = '
<script src="http://www.google-analytics.com/urchin.js"  type="text/javascript">

</script>
<script type="text/javascript">
      _uacct="UA-'.$this->getParameter('google_id').'";urchinTracker();
</script>';
    $respuesta = $this->getContext()->getResponse();
    $respuesta->setContent(str_ireplace('</body>', $codigoGoogle.'</body>',$respuesta->getContent()));
   }

}

No obstante, este filtro no es perfecto, ya que no se debería añadir el código de Google si la respuesta no es de tipo HTML.

Otro ejemplo es el de un filtro que cambia las peticiones a SSL si no lo son, para hacer más segura la comunicación, como muestra el Listado 6-35.

Listado 6-35 - Filtro de comunicación segura

class sfSecureFilter extends sfFilter
{
  public function execute($filterChain)

  {
    $contexto = $this->getContext();
    $peticion = $context->getRequest();
    if (!$peticion->isSecure())

    {
      $urlSegura = str_replace('http', 'https', $peticion->getUri());
      return $contexto->getController()->redirect($urlSegura);
      // No se continúa con la cadena de filtros

    }
    else
    {
      // La petición ya es segura, asi que podemos continuar
      $filterChain->execute();
    }

  }
}

Los filtros se utilizan mucho en los plugins, porque permiten extender las características de una aplicación de forma global. El Capítulo 17 incluye más información sobre los plugins, y el wiki del proyecto Symfony (http://trac.symfony-project.org/) también tiene más ejemplos de filtros.

Algunas características de los módulos dependen de la configuración. Para modificarlas, se debe crear un archivo module.yml en el directorio config/ y se deben definir parámetros para cada entorno (o en la sección all: para todos los entornos). El listado 6-36 muestra un ejemplo de un archivo module.yml para el módulo mimodulo.

Listing 6-36 - Configuración del módulo, en apps/frontend/modules/mimodulo/config/module.yml

all:                  # Para todos los entornos
  enabled:            true
  is_internal:        false
  view_class:         sfPHP
  partial_view_class: sf

El parámetro enabled permite desactivar todas las acciones en un módulo. En ese caso, todas las acciones se redireccionan a la acción module_disabled_module/module_disabled_action (tal y como se define en el archivo settings.yml).

El parámetro is_internal permite restringir la ejecución de todas las acciones de un módulo a llamadas internas. Esto es útil por ejemplo para acciones de envío de correos electrónicos que se deben llamar desde otras acciones para enviar mensajes de e-mail, pero que no se deben llamar desde el exterior.

El parámetro view_class define la clase de la vista. Debe heredar de sfView. Sobreescribir este valor permite utilizar otros sistemas de generación de vistas con otros motores de plantillas, como por ejemplo Smarty.

El parámetro partial_view_class define la clase de la vista que se emplea para los elementos parciales de este módulo. La clase indicada debe heredar de sfPartialView.

En Symfony, la capa del controlador esta dividida en dos partes: el controlador frontal, que es el único punto de entrada a la aplicación para un entorno dado, y las acciones, que contienen la lógia de las páginas. Una acción puede elegir la forma en la que se ejecuta su vista, devolviendo un valor correspondiente a una de las constantes de la clase sfView. Dentro de una acción, se pueden manipular los diferentes elementos del contexto, incluidos el objeto de la petición (sfRequest) y el objeto de la sesión del usuario actual (sfUser).

Combinando el poder del objeto de sesión, el objeto acción y las configuraciones de seguridad proporcionan sistema de seguridad completo, con restricciones de acceso y credenciales. Los métodos especiales validate() y handleError() en la acciones permiten gestionar la validación de las peticiones. Y si los métodos preExecute() y postExecute() se diseñan para la reutilización de código dentro de un módulo, los filtros permiten la misma reutilización para toda la aplicación ejecutando código del controlador para cada petición.



La vista se encarga de producir las páginas que se muestran como resultado de las acciones. La vista en Symfony está compuesta por diversas partes, estando cada una de ellas especialmente preparada para que pueda ser fácilmente modificable por la persona que normalmente trabaja con cada aspecto del diseño de las aplicaciones.

• Los diseñadores web normalmente trabajan con las plantillas (que son la presentación de los datos de la acción que se está ejecutando) y con el layout (que contiene el código HTML común a todas las páginas). Estas partes están formadas por código HTML que contiene pequeños trozos de código PHP, que normalmente son llamadas a los diversos helpers disponibles.

• Para mejorar la reutilización de código, los programadores suelen extraer trozos de las plantillas y los transforman en componentes y elementos parciales. De esta forma, el layout se modifica para definir zonas en las que se insertan componentes externos. Los diseñadores web también pueden trabajar fácilmente con estos trozos de plantillas.

• Los programadores normalmente centran su trabajo relativo a la vista en los archivos de configuración YAML (que permiten establecer opciones para las propiedades de la respuesta y para otros elementos de la interfaz) y en el objeto respuesta. Cuando se trabaja con variables en las plantillas, deben considerarse los posibles riesgos de seguridad de XSS (cross-site scripting) por lo que es necesario conocer las técnicas de escape de los caracteres introducidos por los usuarios.

Independientemente del tipo de trabajo, existen herramientas y utilidades para simplificar y acelerar el trabajo (normalmente tedioso) de presentar los resultados de las acciones. En este capítulo se detallan todas estas herramientas.

El Listado 7-1 muestra el código típico de una plantilla. Su contenido está formado por código HTML y algo de código PHP sencillo, normalmente llamadas a las variables definidas en la acción (mediante la instrucción $this->nombre_variable = 'valor';) y algunos helpers.

Listado 7-1 - Plantilla de ejemplo indexSuccess.php

<h1>Bienvenido</h1>
<p>¡Hola de nuevo, <?php echo $nombre ?>!</p>

<ul>¿Qué es lo que quieres hacer?
  <li><?php echo link_to('Leer los últimos artículos', 'articulo/leer') ?></li>
  <li><?php echo link_to('Escribir un nuevo artículo', 'articulo/escribir') ?></li>

</ul>

Como se explica en el Capítulo 4, es recomendable utilizar la sintaxis alternativa de PHP en las plantillas para hacerlas más fáciles de leer a aquellos desarrolladores que desconocen PHP. Se debería minimizar en lo posible el uso de código PHP en las plantillas, ya que estos archivos son los que se utilizan para definir la interfaz de la aplicación, y muchas veces son diseñados y modificados por otros equipos de trabajo especializados en el diseño de la presentación y no de la lógica del programa. Además, incluir la lógica dentro de las acciones permite disponer de varias plantillas para una sola acción sin tener que duplicar el código.

Los helpers son funciones de PHP que devuelven código HTML y que se utilizan en las plantillas. En el listado 7-1, la función link_to() es un helper. A veces, los helpers solamente se utilizan para ahorrar tiempo, agrupando en una sola instrucción pequeños trozos de código utilizados habitualmente en las plantillas. Por ejemplo, es fácil imaginarse la definición de la función que representa a este helper:

<?php echo input_tag('nick') ?>
=> <input type="text" name="nick" id="nick" value="" />

La función debería ser como la que se muestra en el listado 7-2.

Listado 7-2 - Ejemplo de definición de helper

function input_tag($name, $value = null)

{
  return '<input type="text" name="'.$name.'" id="'.$name.'" value="'.$value.'" />';

}

En realidad, la función input_tag() que incluye Symfony es un poco más complicada que eso, ya que permite indicar un tercer parámetro que contiene otros atributos de la etiqueta <input>. Se puede consultar su sintaxis completa y sus opciones en la documentación de la API: http://www.symfony-project.org/api/1_2/

La mayoría de las veces los helpers incluyen cierta inteligencia que evita escribir bastante código:

<?php echo auto_link_text('Por favor, visita nuestro sitio web www.ejemplo.com') ?>
=> Por favor, visita nuestro sitio web <a href="http://www.ejemplo.com">www.ejemplo.com</a>

Los helpers facilitan la creación de las plantillas y producen el mejor código HTML posible en lo que se refiere al rendimiento y a la accesibilidad. Aunque se puede usar HTML normal y corriente, los helpers normalmente son más rápidos de escribir.

Los archivos de Symfony que contienen los helpers no se cargan automáticamente (ya que contienen funciones, no clases). Los helpers se agrupan según su propósito. Por ejemplo el archivo llamado TextHelper.php contiene todas las funciones de los helpers relacionados con el texto, que se llaman "grupo de helpers de Text". De esta forma, si una plantilla va a utilizar un helper, se debe cargar previamente el grupo al que pertenece el helper mediante la función use_helper(). El listado 7-3 muestra una plantilla que hace uso del helper auto_link_text(), que forma parte del grupo Text.

Listado 7-3 - Declarando el uso de un helper

// Esta plantilla utiliza un grupo de helpers específicos
<?php use_helper('Text') ?>
...

<h1>Descripción</h1>
<p><?php echo auto_link_text($descripcion) ?></p>

Por defecto algunos de los helpers están disponibles en las plantillas sin necesidad de ser declarados. Estos helpers pertenecen a los siguientes grupos:

• Helper: se necesita para incluir otros helpers (de hecho, la función use_helper() también es un helper)
• Tag: helper básico para etiquetas y que utilizan casi todos los helpers
• Url: helpers para la gestión de enlaces y URL
• Asset: helpers que añaden elementos a la sección <head> del código HTML y que proporcionan enlaces sencillos a elementos externos (imágenes, archivos JavaScript, hojas de estilo, etc.)
• Partial: helpers que permiten incluir trozos de plantillas
• Cache: manipulación de los trozos de código que se han añadido a la cache
• Form: helpers para los formularios

El archivo settings.yml permite configurar la lista de helpers que se cargan por defecto en todas las plantillas. De esta forma, se puede modificar su configuración si se sabe por ejemplo que no se van a usar los helpers relacionados con la cache o si se sabe que siempre se van a necesitar los helpers relacionados con el grupo Text. Este cambio puede aumentar ligeramente la velocidad de ejecución de la aplicación. Los 4 primeros helpers de la lista anterior (Helper, Tag, Url y Asset) no se pueden eliminar, ya que son obligatorios para que funcione correctamente el mecanismo de las plantillas. Por este motivo ni siquiera aparecen en la lista de helpers estándares.

Algunos helpers se explican en detalle en los siguientes capítulos, en función de la característica para la que han sido creados. El listado 7-4 incluye un pequeña lista de los helpers que más se utilizan y muestra también el código HTML que generan.

Listado 7-4 - Los helpers por defecto más utilizados

// Grupo Helper
<?php use_helper('NombreHelper') ?>

<?php use_helper('NombreHelper1', 'NombreHelper2', 'NombreHelper3') ?>
 
// Grupo Tag
<?php echo tag('input', array('name' => 'parametro', 'type' => 'text')) ?>

<?php echo tag('input', 'name=parametro type=text') ?>  // Sintaxis alternativa para las opciones
=> <input name="parametro" type="text" />

<?php echo content_tag('textarea', 'contenido de prueba', 'name=parametro') ?>
=> <textarea name="parametro">contenido de prueba</textarea>

 
// Grupo Url
<?php echo link_to('Pínchame', 'mimodulo/miaccion') ?>
=> <a href="/ruta/a/miaccion">Pínchame</a>  // Depende del sistema de enrutamiento

 
// Grupo Asset
<?php echo image_tag('miimagen', 'alt=imagen size=200x100') ?>
=> <img src="/images/miimagen.png" alt="imagen" width="200" height="100"/>

<?php echo javascript_include_tag('miscript') ?>
=> <script language="JavaScript" type="text/javascript" src="/js/miscript.js"></script>

<?php echo stylesheet_tag('estilo') ?>
=> <link href="/stylesheets/estilo.css" media="screen" rel="stylesheet" type="text/css" />

Symfony incluye muchos otros helpers y describirlos todos requeriría de un libro entero. La mejor referencia para estudiar los helpers es la documentación de la API, que se puede consultar en http://www.symfony-project.org/api/1_2/, donde todos los helpers incluyen documentación sobre su sintaxis, opciones y ejemplos.

Symfony incluye numerosos helpers que realizan distintas funcionalidades, pero si no se encuentra lo que se necesita, es probable que tengas que crear un nuevo helper. Crear un helper es muy sencillo.

Las funciones del helper (funciones normales de PHP que devuelven código HTML) se deben guardar en un archivo llamado NombreHelper.php, donde Nombre es el nombre del nuevo grupo de helpers. El archivo se debe guardar en el directorio apps/frontend/lib/helper/ (o en cualquier directorio helper/ que esté dentro de cualquier directorio lib/ del proyecto) para que la función use_helper('Nombre') pueda encontrarlo de forma automática y así poder incluirlo en la plantilla.

La plantilla del listado 7-1 no es un documento XHTML válido. Le faltan la definición del DOCTYPE y las etiquetas <html> y <body>. El motivo es que estos elementos se encuentran en otro lugar de la aplicación, un archivo llamado layout.php que contiene el layout de la página. Este archivo, que también se denomina plantilla global, almacena el código HTML que es común a todas las páginas de la aplicación, para no tener que repetirlo en cada página. El contenido de la plantilla se integra en el layout, o si se mira desde el otro punto de vista, el layout decora la plantilla. Este comportamiento es una implementación del patrón de diseño llamado "decorator" y que se muestra en la figura 7-1.

Figura 7.1. Plantilla decorada con un layout

El listado 7-5 muestra el layout por defecto, que se encuentra en el directorio templates/.

Listado 7-5 - Layout por defecto, en miproyecto/apps/frontend/templates/layout.php

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

  <head>
    <?php include_http_metas() ?>
    <?php include_metas() ?>

    <?php include_title() ?>
    <link rel="shortcut icon" href="/favicon.ico" />

  </head>
  <body>
    <?php echo $sf_content ?>
  </body>

</html>

Los helpers utilizados en la sección <head> obtienen información del objeto respuesta y en la configuración de la vista. La etiqueta <body> muestra el resultado de la plantilla. Utilizando este layout, la configuración por defecto y la plantilla de ejemplo del listado 7-1, la vista generada sería la del listado 7-6.

Listado 7-6 - Unión del layout, la configuración de la vista y la plantilla

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <meta name="title" content="symfony project" />

    <meta name="robots" content="index, follow" />
    <meta name="description" content="symfony project" />

    <meta name="keywords" content="symfony, project" />
    <title>symfony project</title>
    <link rel="stylesheet" type="text/css" href="/css/main.css" />

    <link rel="shortcut icon" href="/favicon.ico">
  </head>
  <body>
    <h1>Bienvenido</h1>

    <p>¡Hola de nuevo, <?php echo $nombre ?>!</p>
    <ul>¿Qué es lo que quieres hacer?
      <li><?php echo link_to('Leer los últimos artículos', 'articulo/leer') ?></li>

      <li><?php echo link_to('Escribir un nuevo artículo', 'articulo/escribir') ?></li>
    </ul>

  </body>
</html>

La plantilla global puede ser adaptada completamente para cada aplicación. Se puede añadir todo el código HTML que sea necesario. Normalmente se utiliza el layout para mostrar la navegación, el logotipo del sitio, etc. Incluso es posible definir más de un layout y decidir en cada acción el layout a utilizar. No te preocupes ahora por la forma de incluir archivos de JavaScript y hojas de estilos, ya que se explica en la sección "Configuración de la Vista" más adelante en este capítulo.

Symfony incluye una serie de variables propias en todas las plantillas. Estas variables se pueden considerar atajos que permiten el acceso directo a la información más utilizada en las plantillas, mediante los siguientes objetos internos de Symfony:

• $sf_context: el objeto que representa a todo el contexto (es una instancia de sfContext)
• $sf_request: el objeto petición (es una instancia de sfRequest)
• $sf_params: los parámetros del objeto petición
• $sf_user: el objeto de sesión del usuario actual (es una instancia de sfUser)

En el capítulo anterior se detallaban algunos métodos útiles de los objetos sfRequest y sfUser. En las plantillas se pueden invocar todos esos métodos mediante las variables $sf_request y $sf_user. Por ejemplo, si la petición incluye un parámetro llamado total, desde la plantilla se puede acceder a su valor de la siguiente manera:

// Método largo
<?php echo $sf_request->getParameter('total') ?>

 
// Método corto (atajo)
<?php echo $sf_params->get('total') ?>
 

// Son equivalentes al siguiente código de la acción
echo $peticion->getParameter('total')

Si se combina el poder de los componentes que se han visto anteriormente y las opciones de configuración de la vista, se consigue un modelo de desarrollo de la vista completamente nuevo: el sistema de slots de componentes. Se trata de una alternativa a los slots que se centra en la reutilización y en la separación en capas. De esta forma, los slots de componentes están mucho más estructurados que los slots, pero son un poco más lentos de ejecutar.

Al igual que los slots, los slots de componentes son zonas que se pueden definir en los elementos de la vista. La principal diferencia reside en la forma en la que se decide qué codigo rellena esas zonas. En un slot normal, el código se establece en otro elemento de la vista; en un slot de componentes, el código es el resultado de la ejecución de un componente, y el nombre de ese componente se obtiene de la configuración de la vista. Después de verlos en la práctica, es sencillo entender el comportamiento de los slots de componentes.

Para definir la zona del slot de componentes, se utiliza el helper include_component_slot(). El parámetro de esta función es el nombre que se asigna al slot de componentes. Imagina por ejemplo que el archivo layout.php de la aplicación tiene un lateral de contenidos cuya información depende de la página en la que se muestra. El listado 7-38 muestra como se incluiría este slot de componentes.

Listado 7-38 - Incluir un slot de componentes de nombre lateral

...
<div id="lateral">
  <?php include_component_slot('lateral') ?>
</div>

La correspondencia entre el nombre del slot de componentes y el nombre del propio componente se define en la configuración de la vista. Por ejemplo, se puede establecer el componente por defecto para el slot lateral debajo de la clave components del archivo view.yml de la aplicación. La clave de la opción de configuración es el nombre del slot de componentes; el valor de la opción es un array que contiene el nombre del módulo y el nombre del componente. El listado 7-29 muestra un ejemplo.

Listado 7-39 - Definir el slot de componentes por defecto para lateral, en frontend/config/view.yml

default:
  components:
    lateral:  [mimodulo, default]

De esta forma, cuando se ejecuta el layout, el slot de componentes lateral se rellena con el resultado de ejecutar el método executeDefault() de la clase mimoduloComponents del módulo mimodulo, y este método utiliza la vista del elemento parcial _default.php que se encuentra en modules/mimodulo/templates/.

La configuración en cascada permite redefinir esta opción en cualquier módulo. Por ejemplo, en el módulo user puede ser más útil mostrar el nombre del usuario y el número de artículos que ha publicado. En ese caso, se puede particularizar el slot lateral mediante las siguientes opciones en el archivo view.yml del módulo, como se muestra en el listado 7-40.

Listado 7-40 - Particularizando el slot de componentes lateral, en frontend/modules/user/config/view.yml

all:
  components:
    lateral:  [mimodulo, user]

El listado 7-41 muestra el código del componente necesario para este slot.

Listado 7-41 - Componentes utilizados por el slot lateral, en modules/mimodulo/actions/components.class.php

class mimoduloComponents extends sfComponents
{
  public function executeDefault()

  {
  }
 
  public function executeUser()
  {

    $this->usuario_actual = $this->getUser()->getCurrentUser();
    $c = new Criteria();
    $c->add(ArticlePeer::AUTHOR_ID, $this->usuario_actual->getId());
    $this->numero_articulos = ArticlePeer::doCount($c);
  }

}

El listado 7-42 muestra la vista de estos 2 componentes.

Listado 7-42 - Elementos parciales utilizados por el slot de componentes lateral, en modules/mimodulo/templates/

// _default.php
<p>El contenido de esta zona depende de la página en la que se muestra.</p>

 
// _user.php
<p>Nombre de usuario: <?php echo $usuario_actual->getName() ?></p>

<p><?php echo $numero_articulos ?> artículos publicados</p>

Los slots de componentes se pueden utilizar para añadir en las páginas web las "migas de pan", los menús de navegación que dependen de cada página y cualquier otro contenido que se deba insertar de forma dinámica. Como componentes que son, se pueden utilizar en el layout global y en cualquier plantilla, e incluso en otros componentes. La configuración que indica el componente de un slot siempre se extrae de la configuración de la última acción que se ejecuta.

Para evitar que se utilice un slot de componentes en un módulo determinado, se puede declarar un par módulo/componente vacío, tal y como muestra el listado 7-43.

Listado 7-43 - Deshabilitar un slot de componentes en view.yml

all:
  components:
    lateral:  []

Cuando se insertan datos generados dinámicamente en una plantilla, se debe asegurar la integridad de los datos. Por ejemplo, si se utilizan datos obtenidos mediante formularios que pueden rellenar usuarios anónimos, existe un gran riesgo de que los contenidos puedan incluir scripts y otros elementos maliciosos que se encargan de realizar ataques de tipo XSS (cross-site scripting). Por tanto, se debe aplicar un mecanismo de escape a todos los datos mostrados, de forma que ninguna etiqueta HTML pueda ser peligrosa.

Imagina por ejemplo que un usuario rellena un campo de formulario con el siguiente valor:

<script>alert(document.cookie)</script>

Si se muestran directamente los datos, el navegador ejecuta el código JavaScript introducido por el usuario, que puede llegar a ser mucho más peligroso que el ejemplo anterior que simplemente muestra un mensaje. Por este motivo, se deben aplicar mecanismos de escape a los valores introducidos antes de mostrarlos, para que se transformen en algo como:

<script>alert(document.cookie)</script>

Los datos se pueden escapar manualmente utilizando la función htmlspecialchars() de PHP, pero es un método demasiado repetitivo y muy propenso a cometer errores. En su lugar, Symfony incluye un sistema conocido como mecanismo de escape de los datos que se aplica a todos los datos mostrados mediante las variables de las plantillas. El mecanismo se activa mediante un único parámetro en el archivo settings.yml de la aplicación.

El mecanismo de escape de datos se configura de forma global para toda la aplicación en el archivo settings.yml. El sistema de escape se controla con 2 parámetros: la estrategia (escaping_strategy) define la forma en la que las variables están disponibles en la vista y el método (escaping_method) indica la función que se aplica a los datos.

En principio, lo único necesario para activar el mecanismo de escape es establecer para la opción escaping_strategy el valor on en vez de su valor por defecto off, tal y como muestra el listado 7-44.

Listado 7-44 - Activar el mecanismo de escape, en frontend/config/settings.yml

all:
  .settings:
    escaping_strategy: on
    escaping_method:   ESC_SPECIALCHARS

Esta configuración aplica la función htmlspecialchars() a los datos de todas las variables mostradas. Si se define una variable llamada prueba en la acción con el siguiente contenido:

$this->prueba = '<script>alert(document.cookie)</script>';

Con el sistema de escape activado, al mostrar esta variable en una plantilla, se mostrarán los siguientes datos:

echo $prueba;
=> <script>alert(document.cookie)</script>

Además, todas las plantillas tienen acceso a una variable llamada $sf_data, que es un objeto contenedor que hace referencia a todas las variables a las que se les ha aplicado el mecanismo de escape. Por lo tanto, se puede acceder al valor de la variable prueba mediante la siguiente instrucción:

echo $sf_data->get('prueba');
=> <script>alert(document.cookie)</script>

La variable $sf_data también da acceso a los datos originales o datos en crudo de la variable. Se trata de una opción muy útil por ejemplo cuando la variable contiene código HTML que se quiere incluir directamente en el navegador para que sea interpretado en vez de mostrado (solo se debería utilizar esta opción si se confía plenamente en el contenido de esa variable). Para acceder a los datos originales se puede utilizar el método getRaw().

echo $sf_data->getRaw('prueba');
=> <script>alert(document.cookie)</script>

Si una variable almacena código HTML, cada vez que se necesita el código HTML original, es necesario acceder a sus datos originales, de forma que el código HTML se interprete y no se muestre en el navegador. Por este motivo el layout por defecto utiliza la instrucción $sf_data->getRaw('sf_content') para incluir el contenido de la plantilla, en vez de utilizar directamente el método $sf_content, que provocaría resultados no deseados cuando se activa el mecanismo de escape.

Cuando el valor de la opción escaping_strategy es off, la variable $sf_data también está disponible, pero en este caso siempre devuelve los datos originales de las variables.

Los helpers utilizados en el mecanismo de escape son funciones que devuelven el valor modificado correspondiente al valor que se les pasa. Se pueden utilizar como valor de la opción escaping_method en el archivo settings.yml o para especificar un método concreto de escape para los datos de una vista. Los helpers disponibles son los siguientes:

• ESC_RAW: no modifica el valor original.
• ESC_SPECIALCHARS: aplica la función htmlspecialchars() de PHP al valor que se le pasa.
• ESC_ENTITIES: aplica la función htmlentities() de PHP al valor que se le pasa y utiliza la opción ENT_QUOTES para el estilo de las comillas.
• ESC_JS: modifica un valor que corresponde a una cadena de JavaScript que va a ser utilizada como HTML. Se trata de una opción muy útil para escapar valores cuando se emplea JavaScript para modificar de forma dinámica el contenido HTML de la página.
• ESC_JS_NO_ENTITIES: modifica un valor que va a ser utilizado en una cadena de JavaScript pero no le añade las entidades HTML correspondientes. Se trata de una opción muy útil para los valores que se van a mostrar en los cuadros de diálogo (por ejemplo para una variable llamada miCadena en la instrucción javascript:alert(miCadena);).

No solo las cadenas de caracteres pueden hacer uso del mecanismo de escape, sino que también se puede aplicar a los arrays y los objetos. El mecanismo de escape se aplica en cascada a todos los arrays u objetos. Si la estrategia empleada es on, el listado 7-45 muesta el mecanismo de escape aplicado en cascada.

Listado 7-45 - El mecanismo de escape se puede aplicar a los arrays y los objetos

// Definición de la clase
class miClase
{
  public function pruebaCaracterEspecial($valor = '')

  {
    return '<'.$valor.'>';
  }
}

 
// En la acción
$this->array_prueba = array('&', '<', '>');

$this->array_de_arrays = array(array('&'));
$this->objeto_prueba = new miClase();

 
// En la plantilla
<?php foreach($array_prueba as $valor): ?>
  <?php echo $valor ?>

<?php endforeach; ?>
 => &amp; &lt; &gt;
<?php echo $array_de_arrays[0][0] ?>

 => &amp;
<?php echo $objeto_prueba->pruebaCaracterEspecial('&') ?>

 => &lt;&amp;&gt;

De hecho, el tipo de las variables en la plantilla no es el tipo que le correspondería a la variable original. El mecanismo de escape "decora las variables y las transforma en objetos especiales:

<?php echo get_class($array_prueba) ?>

=> sfOutputEscaperArrayDecorator
<?php echo get_class($objeto_prueba) ?>
=> sfOutputEscaperObjectDecorator

Esta es la razón por la que algunas funciones PHP habituales (como array_shift(), print_r(), etc.) no funcionan en los arrays a los que se ha aplicado el mecanismo de escape. No obstante, se puede seguir accediendo mediante [], se pueden recorrer con foreach y proporcionan el dato correcto al utilizar la función count() (aunque count() solo funciona con la versión 5.2 o posterior de PHP). Como en las plantillas los datos (casi) siempre se acceden en modo solo lectura, la mayor parte de las veces se accede a los datos mediante los métodos que sí funcionan.

De todas formas, todavía es posible acceder a los datos originales mediante el objeto $sf_data. Además, los métodos de los objetos a los que se aplica el mecanismo de escape se modifican para que acepten un parámetro adicional: el método de escape. Así, se puede utilizar un método de escape diferente cada vez que se accede al valor de una variable en una plantilla, o incluso es posible utilizar el helper ESC_RAW para desactivar el sistema de escape para una variable concreta. El listado 7-46 muestra un ejemplo.

Listado 7-46 - Los métodos de los objetos a los que se aplica el mecanismo de escape aceptan un parámetro adicional

<?php echo $objeto_prueba->pruebaCaracterEspecial('&') ?>

=> &lt;&amp;&gt;
// Las siguientes 3 líneas producen el mismo resultado
<?php echo $objeto_prueba->pruebaCaracterEspecial('&', ESC_RAW) ?>

<?php echo $sf_data->getRaw('objeto_prueba')->pruebaCaracterEspecial('&') ?>

<?php echo $sf_data->get('objeto_prueba', ESC_RAW)->pruebaCaracterEspecial('&') ?>

=> <&>

Si se incluyen muchos objetos en las plantillas, el truco de añadir un parámetro adicional a los métodos se utiliza mucho, ya que es el método más rápido de obtener los datos originales al ejecutar el método.

Existen numerosas herramientas y utilidades para manipular la capa correspondiente a la presentación. Las plantillas se pueden construir en pocos segundos, gracias al uso de los helpers. Los layouts, los elementos parciales, los componentes y los slots de componentes permiten aplicar los conceptos de modularidad y reutilización de componentes. La configuración de la vista aprovecha la velocidad de YAML para manejar la mayoría de cabeceras de las páginas. La configuración en cascada evita tener que definir todas las opciones para cada vista. Si una modificación de la presentación requiere el uso de datos dinámicos, se puede realizar la modificación en la acción mediante el objeto sfResponse. Además, la vista puede protegerse ante ataques de tipo XSS gracias al mecanismo de escape de los datos de las variables.

Hasta ahora, la mayor parte de los contenidos se ha dedicado a la construcción de páginas y al procesado de peticiones y respuestas. Sin embargo, la lógica de negocio de las aplicaciones web depende casi siempre en su modelo de datos. El componente que se encarga por defecto de gestionar el modelo en Symfony es una capa de tipo ORM (object/relational mapping) realizada mediante el proyecto Propel (http://propel.phpdb.org/). En las aplicaciones Symfony, el acceso y la modificación de los datos almacenados en la base de datos se realiza mediante objetos; de esta forma nunca se accede de forma explícita a la base de datos. Este comportamiento permite un alto nivel de abstracción y permite una fácil portabilidad.

En este capítulo se explica como crear el modelo de objetos de datos, y la forma en la que se acceden y modifican los datos mediante Propel. Además, se muestra la integración de Propel en Symfony.

Las bases de datos son relacionales. PHP 5 y Symfony están orientados a objetos. Para acceder de forma efectiva a la base de datos desde un contexto orientado a objetos, es necesaria una interfaz que traduzca la lógica de los objetos a la lógica relacional. Como se explicó en el Capítulo 1, esta interfaz se llama ORM (object-relational mapping) o "mapeo de objetos a bases de datos", y está formada por objetos que permiten acceder a los datos y que contienen en sí mismos el código necesario para hacerlo.

La principal ventaja que aporta el ORM es la reutilización, permitiendo llamar a los métodos de un objeto de datos desde varias partes de la aplicación e incluso desde diferentes aplicaciones. La capa ORM también encapsula la lógica de los datos; como por ejemplo, el cálculo de la puntuación de un usuario de un foro en función de las aportaciones que ha realizado al foro y en función del éxito de esas aportaciones. Cuando una página quiere mostrar esa puntuación de un usuario, simplemente invoca un método del modelo de datos, sin preocuparse de cómo se realiza el cálculo. Si el método de cálculo sufre alguna variación, solo es necesario modificar el método que calcula la puntuación en el modelo, sin necesidad de modificar el resto de la aplicación.

La utilización de objetos en vez de registros y de clases en vez de tablas, tiene otra ventaja: permite añadir métodos accesores en los objetos que no tienen relación directa con una tabla. Si se dispone por ejemplo de una tabla llamada cliente con dos campos llamados nombre y apellidos, puede que se necesite un dato llamado NombreCompleto que incluya y combine el nombre y los apellidos. En el mundo orientado a objetos, es tan fácil como añadir un método accesor a la clase Cliente, como se muestra en el listado 8-1. Desde el punto de vista de la aplicación, no existen diferencias entre los atributos Nombre, Apellidos, NombreCompleto de la clase Cliente. Solo la propia clase es capaz de determinar si un atributo determinado se corresponde con una columna de la base de datos.

Listado 8-1 - Los métodos accesores en la clase del modelo permiten ocultar la estructura real de la tabla de la base de datos

public function getNombreCompleto()
{
  return $this->getNombre().' '.$this->getApellidos();

}

Todo el código repetitivo de acceso a los datos y toda la lógica de negocio de los propios datos se puede almacenar en esos objetos. Imagina que se ha definido la clase CarritoCompra en la que se almacenan Productos (que son objetos). Para obtener el precio total del carrito de la compra antes de realizar el pago, se puede crear un método que encapsula el proceso de cálculo, tal y como se muestra en el listado 8-2.

Listado 8-2 - Los métodos accesores ocultan la lógica de los datos

public function getTotal()
{
  $total = 0;
  foreach ($this->getProductos() as $producto)

  {
    $total += $producto->getPrecio() * $producto->getCantidad();
  }

 
  return $total;
}

Existe otra consideración importante que hay que tener en cuenta cuando se crean elementos de acceso a los datos: las empresas que crean las bases de datos utilizan variantes diferentes del lenguaje SQL. Si se cambia a otro sistema gestor de bases de datos, es necesario reescribir parte de las consultas SQL que se definieron para el sistema anterior. Si se crean las consultas mediante una sintaxis independiente de la base de datos y un componente externo se encarga de traducirlas al lenguaje SQL concreto de la base de datos, se puede cambiar fácilmente de una base de datos a otra. Este es precisamente el objetivo de las capas de abstracción de bases de datos. Esta capa obliga a utilizar una sintaxis específica para las consultas y a cambio realiza el trabajo sucio de optimizar y adaptar el lenguaje SQL a la base de datos concreta que se está utilizando.

La principal ventaja de la capa de abstracción es la portabilidad, porque hace posible el cambiar la aplicación a otra base de datos, incluso en mitad del desarrollo de un proyecto. Si se debe desarrollar rápidamente un prototipo de una aplicación y el cliente no ha decidido todavía la base de datos que mejor se ajusta a sus necesidades, se puede construir la aplicación utilizando SQLite y cuando el cliente haya tomado la decisión, cambiar fácilmente a MySQL, PostgreSQL o Oracle. Solamente es necesario cambiar una línea en un archivo de configuración y todo funciona correctamente.

Symfony utiliza Propel como ORM y Propel utiliza PDO (PHP Data Objects) como capa de abstracción de bases de datos. Estos 2 componentes externos han sido desarrollados por el equipo de Propel, y están completamente integrados en Symfony, por lo que se pueden considerar una parte más del framework. Su sintaxis y sus convenciones, que se describen en este capítulo, se han adaptado de forma que difieran lo menos posible de las de Symfony.

Para crear el modelo de objetos de datos que utiliza Symfony, se debe traducir el modelo relacional de la base de datos a un modelo de objetos de datos. Para realizar ese mapeo o traducción, el ORM necesita una descripción del modelo relacional, que se llama "esquema" (schema). En el esquema se definen las tablas, sus relaciones y las características de sus columnas.

La sintaxis que utiliza Symfony para definir los esquemas hace uso del formato YAML. Los archivos schema.yml deben guardarse en el directorio miproyecto/config/.

¿Cómo se traduce la estructura de una base de datos a un esquema? La mejor forma de entenderlo es mediante un ejemplo. En el ejemplo se supone que se tiene una base de datos de un blog con dos tablas: blog_articulo y blog_comentario, con la estructura que se muestra en la figura 8-1.

Figura 8.1. Estructura de tablas de la base de datos del blog

En este caso, el archivo schema.yml debería ser el del listado 8-3.

Listado 8-3 - Ejemplo de schema.yml

propel:
  blog_articulo:
    _attributes:   { phpName: Articulo }
    id:
    titulo:        varchar(255)
    contenido:     longvarchar
    created_at:
  blog_comentario:
    _attributes:   { phpName: Comentario }

    id:
    articulo_id:
    autor:         varchar(255)
    contenido:     longvarchar
    created_at:

Observa como el nombre de la propia base de datos (blog) no aparece en el archivo schema.yml. En su lugar, la base de datos se describe bajo el nombre de una conexión (propel en el ejemplo anterior). El motivo es que las opciones de conexión con la base de datos pueden depender del entorno en el que se está ejecutando la aplicación. Si se accede a la aplicación en el entorno de desarrollo, es posible que se acceda a la base de datos de desarrollo (por ejemplo blog_dev) pero con el mismo esquema que en la base de datos de producción. Las opciones de conexión con la base de datos se especifican en el archivo databases.yml, que se describe más adelante en este capítulo en la sección "Conexiones con la base de datos". El esquema no contiene ningún tipo de opción para la conexión a la base de datos, solo el nombre de la conexión, para mantener la abstracción de la base de datos.

En el archivo schema.yml, la primera clave representa el nombre de la conexión. Puede contener varias tablas, cada una con varias columnas. Siguiendo la sintaxis de YAML, las claves terminan con dos puntos (:) y la estructura se define mediante la indentación con espacios, no con tabuladores.

Cada tabla puede definir varios atributos, incluyendo el atributo phpName (que es el nombre de la clase PHP que será generada para esa tabla). Si no se menciona el atributo phpName para una tabla, Symfony crea una clase con el mismo nombre que la tabla al que se aplica las normas del camelCase.

Las tablas contienen columnas y el valor de las columnas se puede definir de 3 formas diferentes:

• Si no se indica nada, Symfony intenta adivinar los atributos más adecuados para la columna en función de su nombre y de una serie de convenciones que se explican en la sección "Columnas vacías" un poco más adelante en este Capítulo. Por ejemplo, en el listado 8-3 no es necesario definir la columna id. Symfony por defecto la trata como de tipo entero (integer), cuyo valor se auto-incrementa y además, clave principal de la tabla. En la tabla blog_comentario, la columna articulo_id se trata como una clave externa a la tabla blog_articulo (las columnas que acaban en _id se consideran claves externas, y su tabla relacionada se determina automáticamente en función de la primera parte del nombre de la columna). Las columnas que se llaman created_at automáticamente se consideran de tipo timestamp. Para este tipo de columnas, no es necesario definir su tipo. Esta es una de las razones por las que es tan fácil crear archivos schema.yml.
• Si sólo se define un atributo, se considera que es el tipo de columna. Symfony entiende los tipos de columna habituales: boolean, integer, float, date, varchar(tamaño), longvarchar (que se convierte, por ejemplo, en tipo text en MySQL), etc. Para contenidos de texto de más de 256 caracteres, se utiliza el tipo longvarchar, que no tiene tamaño definido (pero que no puede ser mayor que 65KB en MySQL). Los tipos date y timestamp tienen las limitaciones habituales de las fechas de Unix y no pueden almacenar valores anteriores al 1 de Enero de 1970. Como puede ser necesario almacenar fechas anteriores (por ejemplo para las fechas de nacimiento), existe un formato de fechas "anteriores a Unix" que son bu_date and bu_timestamp.
• Si se necesitan definir otros atributos a la columna (por ejemplo su valor por defecto, si es obligatorio o no, etc.), se indican los atributos como pares clave: valor. Esta sintaxis avanzada del esquema se describe más adelante en este capítulo.

Las columnas también pueden definir el atributo phpName, que es la versión modificada de su nombre según las convenciones habituales (Id, Titulo, Contenido, etc) y que normalmente no es necesario redefinir.

Las tablas también pueden definir claves externas e índices de forma explícita, además de incluir definiciones específicas de su estructura para ciertas bases de datos. En la sección "Sintaxis avanzada del esquema" se detallan estos conceptos.

El esquema se utiliza para construir las clases del modelo que necesita la capa del ORM. Para reducir el tiempo de ejecución de la aplicación, estas clases se generan mediante una tarea de línea de comandos llamada propel:build-model.

> php symfony propel:build-model

Al ejecutar ese comando, se analiza el esquema y se generan las clases base del modelo, que se almacenan en el directorio lib/model/om/ del proyecto:

• BaseArticulo.php
• BaseArticuloPeer.php
• BaseComentario.php
• BaseComentarioPeer.php

Además, se crean las verdaderas clases del modelo de datos en el directorio lib/model/:

• Articulo.php
• ArticuloPeer.php
• Comentario.php
• ComentarioPeer.php

Sólo se han definido dos tablas y se han generado ocho archivos. Aunque este hecho no es nada extraño, merece una explicación.

¿Por qué es útil mantener dos versiones del modelo de objetos de datos en dos directorios diferentes?

Puede ser necesario añadir métodos y propiedades personalizadas en los objetos del modelo (piensa por ejemplo en el método getNombreCompleto() del listado 8-1). También es posible que a medida que el proyecto se esté desarrollando, se añadan tablas o columnas. Además, cada vez que se modifica el archivo schema.yml se deben regenerar las clases del modelo de objetos mediante el comando propel-build-model. Si se añaden los métodos personalizados en las clases que se generan, se borrarían cada vez que se vuelven a generar esas clases.

Las clases con nombre Base del directorio lib/model/om/ son las que se generan directamente a partir del esquema. Nunca se deberían modificar esas clases, porque cada vez que se genera el modelo, se borran todas las clases.

Por otra parte, las clases de objetos propias que están en el directorio lib/model heredan de las clases con nombre Base. Estas clases no se modifican cuando se ejecuta la tarea propel:build-model, por lo que son las clases en las que se añaden los métodos propios.

El listado 8-4 muestra un ejemplo de una clase propia del modelo creada la primera vez que se ejecuta la tarea propel:build-model.

Listado 8-4 - Archivo de ejemplo de una clase del modelo, en lib/model/Articulo.php

class Articulo extends BaseArticulo
{
}

Esta clase hereda todos los métodos de la clase BaseArticulo, pero no le afectan las modificaciones en el esquema.

Este mecanismo de clases personalizadas que heredan de las clases base permite empezar a programar desde el primer momento, sin ni siquiera conocer el modelo relacional definitivo de la base de datos. La estructura de archivos creada permite personalizar y evolucionar el modelo.

Articulo y Comentario son clases objeto que representan un registro de la base de datos. Permiten acceder a las columnas de un registro y a los registros relacionados. Por tanto, es posible obtener el título de un artículo invocando un método del objeto Articulo, como se muestra en el listado 8-5.

Listado 8-5 - Las clases objeto disponen de getters para los registros de las columnas

$articulo = new Articulo();

// ...
$titulo = $articulo->getTitulo();

ArticuloPeer y ComentarioPeer son clases de tipo "peer"; es decir, clases que tienen métodos estáticos para trabajar con las tablas de la base de datos. Proporcionan los medios necesarios para obtener los registros de las tablas. Sus métodos devuelven normalmente un objeto o una colección de objetos de la clase objeto relacionada, como se muestra en el listado 8-6.

Listado 8-6 - Las clases "peer" contienen métodos estáticos para obtener registros de la base de datos

// $articulos es un array de objetos de la clase Articulo
$articulos = ArticuloPeer::retrieveByPks(array(123, 124, 125));

La combinación de las clases objeto y las clases "peer" y las versiones básicas y personalizadas de cada una hace que se generen 4 clases por cada tabla del esquema. En realidad, existe una quinta clase que se crea en el directorio lib/model/map/ y que contiene metainformación relativa a la tabla que es necesaria para la ejecución de la aplicación. Pero como es una clase que seguramente no se modifica nunca, es mejor olvidarse de ella.

En Symfony, el acceso a los datos se realiza mediante objetos. Si se está acostumbrado al modelo relacional y a utilizar consultas SQL para acceder y modificar los datos, los métodos del modelo de objetos pueden parecer complicados. No obstante, una vez que se prueba el poder de la orientación a objetos para acceder a los datos, probablemente te gustará mucho más.

En primer lugar, hay que asegurarse de que se utiliza el mismo vocabulario. Aunque el modelo relacional y el modelo de objetos utilizan conceptos similares, cada uno tiene su propia nomenclatura:

Cuando Symfony construye el modelo, crea una clase de objeto base para cada una de las tablas definidas en schema.yml. Cada una de estas clases contiene una serie de constructores y accesores por defecto en función de la definición de cada columna: los métodos new, getXXX() y setXXX() permiten crear y obtener las propiedades de los objetos, como se muestra en el listado 8-7.

Listado 8-7 - Métodos generados en una clase objeto

$articulo = new Articulo();
$articulo->setTitulo('Mi primer artículo');

$articulo->setContenido('Este es mi primer artículo. \n Espero que te guste.');
 
$titulo    = $articulo->getTitulo();

$contenido = $articulo->getContenido();

Para establecer el valor de varios campos a la vez, se puede utilizar el método fromArray(), que también se genera para cada clase objeto, como se muestra en el listado 8-8.

Listado 8-8 - El método fromArray() es un setter múltiple

$articulo->fromArray(array(
  'titulo'   => 'Mi primer artículo',
  'contenido' => 'Este es mi primer artículo. \n Espero que te guste.'

));

La columna articulo_id de la tabla blog_comentario define implícitamente una clave externa a la tabla blog_articulo. Cada comentario está relacionado con un artículo y un artículo puede tener muchos comentarios. Las clases generadas contienen 5 métodos que traducen esta relación a la forma orientada a objetos, de la siguiente manera:

• $comentario->getArticulo(): para obtener el objeto Articulo relacionado
• $comentario->getArticuloId(): para obtener el ID del objeto Articulo relacionado
• $comentario->setArticulo($articulo): para definir el objeto Articulo relacionado
• $comentario->setArticuloId($id): para definir el objeto Articulo relacionado a partir de un ID
• $articulo->getComentarios(): para obtener los objetos Comentario relacionados

Los métodos getArticuloId() y setArticuloId() demuestran que se puede utilizar la columna articulo_id como una columna normal y que se pueden indicar las relaciones manualmente, pero esto no es muy interesante. La ventaja de la forma orientada a objetos es mucho más evidente en los otros 3 métodos. El listado 8-9 muestra como utilizar los setters generados.

Listado 8-9 - Las claves externas se traducen en un setter especial

$comentario = new Comentario();

$comentario->setAutor('Steve');
$comentario->setContenido('¡Es el mejor artículo que he leído nunca!');
 
// Añadir este comentario al anterior objeto $articulo

$comentario->setArticulo($articulo);
 
// Sintaxis alternativa
// Solo es correcta cuando el objeto artículo ya 
// ha sido guardado anteriormente en la base de datos
$comentario->setArticuloId($articulo->getId());

El listado 8-10 muestra como utilizar los getters generados automáticamente. También muestra como encadenar varias llamadas a métodos en los objetos del modelo.

Listado 8-10 - Las claves externas se traducen en getters especiales

// Relación de "muchos a uno"
echo $comentario->getArticulo()->getTitulo();
 => Mi primer artículo

echo $comentario->getArticulo()->getContenido();
 => Este es mi primer artículo.
    Espero que te guste.
 
// Relación "uno a muchos"

$comentarios = $articulo->getComentarios();

El método getArticulo() devuelve un objeto de tipo Articulo, que permite utilizar el método accesor getTitulo(). Se trata de una alternativa mucho mejor que realizar la unión de las tablas manualmente, ya que esto último necesitaría varias líneas de código (empezando con la llamada al método $comment->getArticuloId()).

La variable $comentarios del listado 8-10 contiene un array de objetos de tipo Comentario. Se puede mostrar el primer comentario mediante $comentarios[0] o se puede recorrer la colección entera mediante foreach ($comentarios as $comentario).

Al utilizar el constructor new se crea un nuevo objeto, pero no un registro en la tabla blog_articulo. Si se modifica el objeto, tampoco se reflejan esos cambios en la base de datos. Para guardar los datos en la base de datos, se debe invocar el método save() del objeto.

$articulo->save();

El ORM de Symfony es lo bastante inteligente como para detectar las relaciones entre objetos, por lo que al guardar el objeto $articulo también se guarda el objeto $comentario relacionado. También detecta si ya existía el objeto en la base de datos, por lo que el método save() a veces se traduce a una sentencia INSERT de SQL y otras veces se traduce a una sentencia UPDATE. La clave primaria se establece de forma automática al llamar al método save(), por lo que después de guardado, se puede obtener la nueva clave primaria del objeto mediante $articulo->getId().

Si lees los comentarios que insertan los usuarios en tus artículos, puede que te desanimes un poco para seguir publicando cosas en Internet. Si además no captas la ironía de los comentarios, puedes borrarlos fácilmente con el método delete(), como se muestra en el listado 8-11.

Listado 8-11 - Borrar registros de la base de datos mediante el método delete() del objeto relacionado

foreach ($articulo->getComentarios() as $comentario)

{
  $comentario->delete();
}

Si se conoce la clave primaria de un registro concreto, se puede utilizar el método retrieveByPk() de la clase peer para obtener el objeto relacionado.

$articulo = ArticuloPeer::retrieveByPk(7);

El archivo schema.yml define el campo id como clave primaria de la tabla blog_articulo, por lo que la sentencia anterior obtiene el artículo cuyo id sea igual a 7. Como se ha utilizado una clave primaria, solo se obtiene un registro; la variable $articulo contiene un objeto de tipo Articulo.

En algunos casos, la clave primaria está formada por más de una columna. Es esos casos, el método retrieveByPK() permite indicar varios parámetros, uno para cada columna de la clave primaria.

También se pueden obtener varios objetos a la vez mediante sus claves primarias, invocando el método retrieveByPKs(), que espera como argumento un array de claves primarias.

Cuando se quiere obtener más de un registro, se debe utilizar el método doSelect() de la clase peer correspondiente a los objetos que se quieren obtener. Por ejemplo, para obtener objetos de la clase Articulo, se llama al método ArticuloPeer::doSelect().

El primer parámetro del método doSelect() es un objeto de la clase Criteria, que es una clase para definir consultas simples sin utilizar SQL, para conseguir la abstracción de base de datos.

Un objeto Criteria vacío devuelve todos los objetos de la clase. Por ejemplo, el código del listado 8-12 obtiene todos los artículos de la base de datos.

Listado 8-12 - Obtener registros mediante Criteria con el método doSelect() (Criteria vacío)

$c = new Criteria();
$articulos = ArticuloPeer::doSelect($c);

 
// Genera la siguiente consulta SQL
SELECT blog_articulo.ID, blog_articulo.TITLE, blog_articulo.CONTENIDO,
       blog_articulo.CREATED_AT
FROM   blog_articulo;

Para las selecciones más complejas de objetos, se necesitan equivalentes a las sentencias WHERE, ORDER BY, GROUP BY y demás de SQL. El objeto Criteria dispone de métodos y parámetros para indicar todas estas condiciones. Por ejemplo, para obtener todos los comentarios escritos por el usuario Steve y ordenados por fecha, se puede construir un objeto Criteria como el del listado 8-13.

Listado 8-13 - Obtener registros mediante Criteria con el método doSelect() (Criteria con condiciones)

$c = new Criteria();

$c->add(ComentarioPeer::AUTOR, 'Steve');
$c->addAscendingOrderByColumn(ComentarioPeer::CREATED_AT);

$comentarios = ComentarioPeer::doSelect($c);
 
// Genera la siguiente consulta SQL
SELECT blog_comentario.ARTICULO_ID, blog_comentario.AUTOR, blog_comentario.CONTENIDO,
       blog_comentario.CREATED_AT
FROM   blog_comentario
WHERE  blog_comentario.autor = 'Steve'
ORDER BY blog_comentario.CREATED_AT ASC;

Las constantes de clase que se pasan como parámetros a los métodos add() hacen referencia a los nombres de las propiedades. Su nombre se genera a partir del nombre de las columnas en mayúsculas. Por ejemplo, para indicar la columna contenido de la tabla blog_articulo, se utiliza la constante de clase llamada ArticuloPeer::CONTENIDO.

La tabla 8-1 compara la sintaxis de SQL y del objeto Criteria.

Tabla 8-1 - Sintaxis de SQL y del objeto Criteria

El listado 8-14 muestra otro ejemplo del uso de Criteria con condiciones múltiples. En el ejemplo se obtienen todos los comentarios del usuario Steve en los artículos que contienen la palabra enjoy y además, ordenados por fecha.

Listado 8-14 - Otro ejemplo para obtener registros mediante Criteria con el método doSelect() (Criteria con condiciones)

$c = new Criteria();
$c->add(ComentarioPeer::AUTOR, 'Steve');

$c->addJoin(ComentarioPeer::ARTICULO_ID, ArticuloPeer::ID);
$c->add(ArticuloPeer::CONTENIDO, '%enjoy%', Criteria::LIKE);

$c->addAscendingOrderByColumn(ComentarioPeer::CREATED_AT);
$comentarios = ComentarioPeer::doSelect($c);
 

// Genera la siguiente consulta SQL
SELECT blog_comentario.ID, blog_comentario.ARTICULO_ID, blog_comentario.AUTOR,
       blog_comentario.CONTENIDO, blog_comentario.CREATED_AT
FROM   blog_comentario, blog_articulo
WHERE  blog_comentario.AUTOR = 'Steve'
       AND blog_articulo.CONTENIDO LIKE '%enjoy%'
       AND blog_comentario.ARTICULO_ID = blog_articulo.ID
ORDER BY blog_comentario.CREATED_AT ASC

De la misma forma que el lenguaje SQL es sencillo pero permite construir consultas muy complejas, el objeto Criteria permite manejar condiciones de cualquier nivel de complejodad. Sin embargo, como muchos programadores piensan primero en el código SQL y luego lo traducen a las condiciones de la lógica orientada a objetos, es difícil comprender bien el objeto Criteria cuando se utiliza las primeras veces. La mejor forma de aprender es mediante ejemplos y aplicaciones de prueba. El sitio web del proyecto Symfony esá lleno de ejemplos de cómo construir objetos de tipo Criteria para todo tipo de situaciones.

Además del método doSelect(), todas las clases peer tienen un método llamado doCount(), que simplemente cuenta el número de registros que satisfacen las condiciones pasadas como parámetro y devuelve ese número como un entero. Como no se devuelve ningún objeto, no se produce el proceso de hydrating y por tanto el método doCount() es mucho más rápido que doSelect().

Las clases peer también incluyen métodos doDelete(), doInsert() y doUpdate() (todos ellos requieren como parámetro un objeto de tipo Criteria). Estos métodos permiten realizar consultas de tipo DELETE, INSERT y UPDATE a la base de datos. Se pueden consultar las clases peer generadas automáticamente para descubrir más detalles de estos métodos de Propel.

Por último, si solo se quiere obtener el primer objeto, se puede reemplazar el método doSelect() por doSelectOne(). Es muy útil cuando se sabe que las condiciones de Criteria solo van a devolver un resultado, y su ventaja es que el método devuelve directamente un objeto en vez de un array de objetos.

A veces, no es necesario obtener los objetos, sino que solo son necesarios algunos datos calculados por la base de datos. Por ejemplo, para obtener la fecha de creación de todos los artículos, no tiene sentido obtener todos los artículos y después recorrer el array de los resultados. En este caso es preferible obtener directamente el resultado, ya que se evita el proceso de hydrating.

Por otra parte, no deberían utilizarse instrucciones PHP de acceso a la base de datos, porque se perderían las ventajas de la abstracción de bases de datos. Lo que significa que se debe evitar el ORM (Propel) pero no la abstracción de bases de datos (PDO).

Para realizar consultas a la base de datos con PDO, es necesario realizar los siguientes pasos:

1. Obtener la conexión con la base de datos.
2. Construir la consulta.
3. Crear una sentencia con esa consulta.
4. Iterar el result set que devuelve la ejecución de la sentencia.

Aunque lo anterior puede parecer un galimatías, el código del listado 8-15 es mucho más explícito.

Listado 8-15 - Consultas SQL personalizadas con PDO

$conexion = Propel::getConnection();
$consulta = 'SELECT MAX(%s) AS max FROM %s';
$consulta = sprintf($consulta, ArticuloPeer::CREATED_AT, ArticuloPeer::TABLE_NAME);

$sentencia = $conexion->prepare($consulta);
$sentencia->execute();
$resultset = $sentencia->fetch(PDO::FETCH_OBJ);

$max = $resultset->max;

Al igual que sucede con las selecciones realizadas con Propel, las consultas con PDO son un poco complicadas de usar al principio. Los ejemplos de las aplicaciones existentes y de los tutoriales pueden ser útiles para descubrir la forma de hacerlas.

Normalmente, cuando una tabla tiene una columna llamada created_at, se utiliza para almacenar un timestamp de la fecha de creación del registro. La misma idea se aplica a las columnas updated_at, cuyo valor se debe actualizar cada vez que se actualiza el propio registro.

La buena noticia es que Symfony reconoce estos nombres de columna y se ocupa de actualizar su valor de forma automática. No es necesario establecer manualmente el valor de las columnas created_at y updated_at; se actualizan automáticamente, tal y como muestra el listado 8-16. Lo mismo se aplica a las columnas llamadas created_on y updated_on.

Listado 8-16 - Las columnas created_at y updated_at se gestionan automáticamente

$comentario = new Comentario();

$comentario->setAutor('Steve');
$comentario->save();
 
// Muestra la fecha de creación
echo $comentario->getCreatedAt();
 => [fecha de la operación INSERT de la base de datos]

Además, los getters de las columnas de fechas permiten indicar el formato de la fecha como argumento:

echo $comentario->getCreatedAt('Y-m-d');

 public function executeMuestraArticulosPopularesParaEtiqueta($peticion)

 {
   $etiqueta = EtiquetaPeer::retrieveByName($peticion->getParameter('etiqueta'));
   $this->foward404Unless($etiqueta);
   $this->articulos = $etiqueta->getArticulosPopulares(10);
 }

Aunque el modelo de datos es independiente de la base de datos utilizada, es necesario utilizar una base de datos concreta. La información mínima que necesita Symfony para realizar peticiones a la base de datos es su nombre, las credenciales para acceder (usuario, contraseña) y el tipo de base de datos. Las opciones de conexión se pueden configurar pasando un DSN (data source name) a la tarea configure:database:

> php symfony configure:database "mysql://login:password@localhost/blog"

Los datos de conexión dependen del entorno de ejecución. Se pueden definir diferentes opciones para los entornos prod, dev y test y para cualquier otro entorno de la aplicación utilizando la opción env:

> php symfony --env=prod configure:database "mysql://login:password@localhost/blog"

Cada aplicación también puede redefinir esta configuración, lo que es útil cuando se quiere disponer de diferentes políticas de seguridad para el frontal y para la parte de administración de la aplicación. De esta forma, es posible disponer de diferentes usuarios de base de datos con privilegios diferentes para cada aplicación:

> php symfony --app=frontend configure:database "mysql://login:password@localhost/blog"

En cada entorno también es posible definir varias conexiones diferentes. Cada conexión siempre hace referencia al esquema de datos del mismo nombre. El nombre de la conexión por defecto es propel, que hace referencia al esquema de datos llamado propel (por ejemplo el del listado 8-3). La opción name permite crear una nueva conexión:

> php symfony --name=otraconexion configure:database "mysql://login:password@localhost/blog"

Las opciones de conexión con la base de datos también se pueden establecer manualmente en el archivo databases.yml que se encuentra en el directorio config/. El listado 8-17 muestra un ejemplo de ese archivo y el listado 8-18 muestra el mismo ejemplo con la notación extendida.

Listado 8-17 - Opciones abreviadas de conexión con la base de datos

all:
  propel:
    class:          sfPropelDatabase
    param:
      dsn:          mysql://login:password@localhost/blog

Listado 8-18 - Ejemplo de opciones de conexión con la base de datos, en miproyecto/config/databases.yml

prod:
  propel:
    param:
      hostspec:           mi_servidor_datos
      usuarioname:           mi_nombre_usuario
      password:           xxxxxxxxxx
 
all:
  propel:
    class:                sfPropelDatabase
    param:
      phptype:            mysql     # fabricante de la base de datos
      hostspec:           localhost
      database:           blog
      usuarioname:           login
      password:           passwd
      port:               80

      encoding:           utf8      # Codificación utilizada para crear la tabla
      persistent:         true      # Utilizar conexiones persistentes

Los valores permitidos para el parámetro phptype corresponden a los tipos de bases de datos soportados por PDO:

• mysql
• mssql
• pgsql
• sqlite
• oracle

Los parámetros hostspec, database, usuarioname y password son las opciones típicas para conectar con una base de datos (servidor, base de datos, nombre de usuario y contraseña).

Si se utiliza una base de datos de tipo SQLite, el parámetro hostspec debe indicar la ruta al archivo de base de datos. Si por ejemplo se guarda la base de datos del blog en el archivo data/blog.db, las opciones del archivo databases.yml serán las del listado 8-19.

Listado 8-19 - Opciones de conexión con una base de datos SQLite utilizando la ruta al archivo como host

all:
  propel:
    class:          sfPropelDatabase
    param:
      phptype:      sqlite
      database:     %SF_DATA_DIR%/blog.db

Los métodos del modelo que se generan automáticamente están muy bien, pero no siempre son suficientes. Si se incluye lógica de negocio propia, es necesario extender el modelo añadiendo nuevos métodos o redefiniendo algunos de los existentes.

Los nuevos métodos se pueden añadir en las clases vacías del modelo que se generan en el directorio lib/model/. Se emplea $this para invocar a los métodos del objeto actual y self:: para invocar a los métodos estáticos de la clase actual. No se debe olvidar que las clases personalizadas heredan los métodos de las clases Base del directorio lib/model/om/.

Por ejemplo, en el objeto Articulo generado en el listado 8-3, se puede añadir un método mágico de PHP llamado __toString() de forma que al mostrar un objeto de la clase Articulo se muestre su título, tal y como se indica en el listado 8-20.

Listado 8-20 - Personalizar el modelo, en lib/model/Articulo.php

class Articulo extends BaseArticulo
{
  public function __toString()

  {
    return $this->getTitulo();  // getTitulo() se hereda de BaseArticulo
  }

}

También se pueden extender las clases peer, como por ejemplo para obtener todos los artículos ordenados por fecha de creación, tal y como muestra el listado 8-21.

Listado 8-21 - Personalizando el modelo, en lib/model/ArticuloPeer.php

class ArticuloPeer extends BaseArticuloPeer

{
  public static function getTodosOrdenadosPorFecha()
  {
    $c = new Criteria();
    $c->addAscendingOrderByColumn(self::CREATED_AT);
    return self::doSelect($c);
  }

}

Los nuevos métodos están disponibles de la misma forma que los métodos generados automáticamente, tal y como muestra el listado 8-22.

Listado 8-22 - El uso de métodos personalizados del modelo es idéntico al de los métodos generados automáticamente

foreach (ArticuloPeer::getTodosOrdenadosPorFecha() as $articulo)

{
  echo $articulo;   // Se llama al método mágico __toString()
}

Si alguno de los métodos generados automáticamente en las clases Base no satisfacen las necesidades de la aplicación, se pueden redefinir en las clases personalizadas. Solamente es necesario mantener el mismo número de argumentos para cada método.

Por ejemplo, el método $articulo->getComentarios() devuelve un array de objetos Comentario, sin ningún tipo de ordenamiento. Si se necesitan los resultados ordenados por fecha de creación siendo el primero el comentario más reciente, se puede redefinir el método getComentarios(), como muestra el listado 8-23. Como el método getComentarios() original (guardado en lib/model/om/BaseArticulo.php) requiere como argumentos un objeto de tipo Criteria y una conexión, la nueva función debe contener esos mismos parámetros.

Listado 8-23 - Redefiniendo los métodos existentes en el modelo, en lib/model/Articulo.php

public function getComentarios($criteria = null, $con = null)

{
  if (is_null($criteria))
  {
    $criteria = new Criteria();
  }

  else
  {
    // Los objetos se pasan por referencia en PHP5, por lo que se debe clonar
    // el objeto original para no modificarlo
    $criteria = clone $criteria;
  }

  $criteria->addDescendingOrderByColumn(ComentarioPeer::CREATED_AT);
 
  return parent::getComentarios($criteria, $con);

}

El método personalizado acaba llamando a su método padre en la clase Base, lo que se considera una buena práctica. No obstante, es posible saltarse completamente la clase Base y devolver el resultado directamente.

Algunas de las modificaciones que se realizan en el modelo son genéricas y por tanto se pueden reutilizar. Por ejemplo, los métodos que hacen que un objeto del modelo sea reordenable o un bloqueo de tipo optimistic en la base de datos para evitar conflictos cuando se guardan de forma concurrente los objetos se pueden considerar extensiones genéricas que se pueden añadir a muchas clases.

Symfony encapsula estas extensiones en "comportamientos" (del inglés behaviors). Los comportamientos son clases externas que proporcionan métodos extras a las clases del modelo. Las clases del modelo están definidas de forma que se puedan enganchar estas clases externas y Symfony extiende las clases del modelo mediante sfMixer (el Capítulo 17 contiene los detalles).

Para habilitar los comportamientos en las clases del modelo, se debe modificar una opción del archivo config/propel.ini:

propel.builder.AddBehaviors = true     // El valor por defecto es false

Symfony no incluye por defecto ningún comportamiento, pero se pueden instalar mediante plugins. Una vez que el plugin se ha instalado, se puede asignar un comportamiento a una clase mediante una sola línea de código. Si por ejemplo se ha instalado el plugin sfPropelParanoidBehaviorPlugin en la aplicación, se puede extender la clase Articulo con este comportamiento añadiendo la siguiente línea de código al final del archivo Articulo.class.php:

sfPropelBehavior::add('Articulo', array(
  'paranoid' => array('column' => 'deleted_at')

));

Después de volver a generar el modelo, los objetos de tipo Articulo que se borren permanecerán en la base de datos, aunque será invisibles a las consultas que hacen uso de los métodos del ORM, a no ser que se deshabilite temporalmente el comportamiento mediante sfPropelParanoidBehavior::disable().

Desde la versión 1.1 de Symfony también es posible declarar los comportamientos directamente en el archivo schema.yml, incluyéndolos bajo la clave _behaviors (ver listado 8-34 más adelante).

La lista de plugins de Symfony disponible en el wiki incluye numerosos comportamientos http://trac.symfony-project.org/wiki/SymfonyPlugins#Behaviors. Cada comportamiento tiene su propia documentación y su propia guía de instalación.

Un archivo schema.yml puede ser tan sencillo como el mostrado en el listado 8-3. Sin embargo, los modelos relacionales suelen ser complejos. Este es el motivo por el que existe una sintaxis extendida del esquema para que se pueda utilizar en cualquier caso.

Se pueden definir atributos específicos para las conexiones y las tablas, tal y como se muestra en el listado 8-24. Estas opciones se establecen bajo la clave _attributes.

Listado 8-24 - Atributos de las conexiones y las tablas

propel:
  _attributes:   { noXsd: false, defaultIdMethod: none, package: lib.model }

  blog_articulo:
    _attributes: { phpName: Articulo }

Si se quiere validar el esquema antes de que se genere el código asociado, se debe desactivar en la conexión el atributo noXSD. La conexión también permite que se le indique el atributo defaultIdMethod. Si no se indica, se utilizará el método nativo de generación de IDs --por ejemplo, autoincrement en MySQL o sequences en PostgreSQL. El otro valor permitido es none.

El atributo package es como un namespace; indica la ruta donde se guardan las clases generadas automáticamente. Su valor por defecto es lib/model/, pero se puede modificar para organizar el modelo en una estructura de subpaquetes. Si por ejemplo no se quieren mezclar en el mismo directorio las clases del núcleo de la aplicación con las clases de un sistema de estadísticas, se pueden definir dos esquemas diferentes con los paquetes lib.model.business y lib.model.stats.

Ya se ha visto el atributo de tabla phpName, que se utiliza para establecer el nombre de la clase generada automáticamente para manejar cada tabla de la base de datos.

Las tablas que guardan contenidos adaptados para diferentes idiomas (es decir, varias versiones del mismo contenido en una tabla relacionada, para conseguir la internacionalización) también pueden definir dos atributos adicionales (explicados detalladamente en el Capítulo 13), tal y como se muestra en el listado 8-25.

Listado 8-25 - Atributos para las tablas de internacionalización

propel:
  blog_articulo:
    _attributes: { isI18N: true, i18nTable: db_group_i18n }

// En config/business-schema.yml
propel:
  blog_articulo:
    _attributes: { phpName: Articulo }

  id:
  titulo: varchar(50)

// En config/stats-schema.yml
propel:
  estadisticas_visita:
    _attributes: { phpName: Visita }
  id:
  recurso: varchar(100)

  created_at:

# En config/business-schema.yml
propel:
  blog_articulo:
    _attributes: { phpName: Articulo, package: lib.model.business }

  id:
  titulo: varchar(50)

# En config/stats-schema.yml
propel_bis:
  estadisticas_visita:
    _attributes: { phpName: Visita, package: lib.model.stat }
  id:
  recurso: varchar(100)

  created_at:

La sintaxis básica ofrece dos posibilidades: dejar que Symfony deduzca las características de una columna a partir de su nombre (indicando un valor vacío para esa columna) o definir el tipo de columna con uno de los tipos predefinidos. El listado 8-26 muestra estas 2 opciones.

Listado 8-26 - Atributos básicos de columna

propel:
  blog_articulo:
    id:                 # Symfony se encarga de esta columna
    titulo: varchar(50)  # Definir el tipo explícitamente

Se pueden definir muchos más aspectos de cada columna. Si se definen, se utiliza un array asociativo para indicar las opciones de la columna, tal y como muestra el listado 8-27.

Listado 8-27 - Atributos avanzados de columna

propel:
  blog_articulo:
    id:       { type: integer, required: true, primaryKey: true, autoIncrement: true }
    name:     { type: varchar(50), default: foobar, index: true }

    group_id: { type: integer, foreignTable: db_group, foreignReference: id, onDelete: cascade }

Los parámetros de las columnas son los siguientes:

• type: Tipo de columna. Se puede elegir entre boolean, tinyint, smallint, integer, bigint, double, float, real, decimal, char, varchar(tamano), longvarchar, date, time, timestamp, bu_date, bu_timestamp, blob y clob.
• required: valor booleano. Si vale true la columna debe tener obligatoriamente un valor.
• default: el valor por defecto.
• primaryKey: valor booleano. Si vale true indica que es una clave primaria.
• autoIncrement: valor booleano. Si se indica true para las columnas de tipo integer, su valor se auto-incrementará.
• sequence: el nombre de la secuencia para las bases de datos que utilizan secuencias para las columnas autoIncrement (por ejemplo PostgreSQL y Oracle).
• index: valor booleano. Si vale true, se construye un índice simple; si vale unique se construye un índice único para la columna.
• foreignTable: el nombre de una tabla, se utiliza para crear una clave externa a otra tabla.
• foreignReference: el nombre de la columna relacionada si las claves externas se definen mediante foreignTable.
• onDelete: determina la acción que se ejecuta cuando se borra un registro en una tabla relacionada. Si su valor es setnull, la columna de la clave externa se establece a null. Si su valor es cascade, se borra el registro relacionado. Si el sistema gestor de bases de datos no soporta este comportamiento, el ORM lo emula. Esta opción solo tiene sentido para las columnas que definen una foreignTable y una foreignReference.
• isCulture: valor booleano. Su valor es true para las columnas de tipo culture en las tablas de contenidos adaptados a otros idiomas (más detalles en el Capítulo 13).

Además de los atributos de columna foreignTable y foreignReference, es posible añadir claves externas bajo la clave _foreignKeys: de cada tabla. El esquema del listado 8-28 crea una clave externa en la columna usuario_id, que hace referencia a la columna id de la tabla blog_usuario.

Listado 8-28 - Sintaxis alternativa para las claves externas

propel:
  blog_articulo:
    id:
    titulo:     varchar(50)
    usuario_id: { type: integer }

    _foreignKeys:
      -
        foreignTable: blog_usuario
        onDelete:     cascade
        references:
          - { local: usuario_id, foreign: id }

La sintaxis alternativa es muy útil para las claves externas múltiples y para indicar un nombre a cada clave externa, tal y como muestra el listado 8-29.

Listado 8-29 - La sintaxis alternativa de las claves externas aplicada a una clave externa múltiple

_foreignKeys:
  mi_clave_externa:
    foreignTable:  db_usuario
    onDelete:      cascade
    references:
      - { local: usuario_id, foreign: id }

      - { local: post_id, foreign: id }

Además del atributo de columna index, es posible añadir claves índices bajo la clave _indexes: de cada tabla. Si se quieren crean índices únicos, se debe utilizar la clave _uniques:. En las columnas que requieren un tamaño, por ejemplo por ser columnas de texto, el tamaño del índice se indica entre paréntesis, de la misma forma que se indica el tamaño de cualquier columna. El listado 8-30 muestra la sintaxis alternativa para los índices.

Listado 8-30 - Sintaxis alternativa para los índices y los índices únicos

propel:
  blog_articulo:
    id:
    titulo:            varchar(50)
    created_at:
    _indexes:
      mi_indice:      [titulo(10), usuario_id]

    _uniques:
      mi_otro_indice: [created_at]

La sintaxis alternativa solo es útil para los índices que se construyen con más de una columna.

Cuando Symfony se encuentra con una columna sin ningún valor, utiliza algo de magia para determinar su valor. El listado 8-31 muestra los detalles del tratamiento de las columnas vacías.

Listado 8-31 - Los detalles deducidos para las columnas vacías en función de su nombre

// Las columnas vacías llamadas "id" se consideran claves primarias
id:         { type: integer, required: true, primaryKey: true, autoIncrement: true }
 
// Las columnas vacías llamadas "XXX_id" se consideran claves externas
loquesea_id:  { type: integer, foreignTable: db_loquesea, foreignReference: id }

 
// Las columnas vacías llamadas created_at, updated at, created_on y updated_on
// se consideran fechas y automáticamente se les asigna el tipo "timestamp"
created_at: { type: timestamp }
updated_at: { type: timestamp }

Para las claves externas, Symfony busca una tabla cuyo phpName sea igual al principio del nombre de la columna; si se encuentra, se utiliza ese nombre de tabla como foreignTable.

Symfony permite internacionalizar los contenidos mediante tablas relacionadas. De esta forma, cuando se dispone de contenido que debe ser internacionalizado, se guarda en 2 tablas distintas: una contiene las columnas invariantes y otra las columnas que permiten la internacionalización.

Todo lo anterior se considera de forma implícita cuando en el archivo schema.yml se dispone de una tabla con el nombre cualquiernombre_i18n. Por ejemplo, el esquema que muestra el listado 8-32 se completa automáticamente con los atributos de columna y de tabla necesarios para que funcione el mecanismo de internacionalización. De forma interna, Symfony entiende ese listado como si se hubiera escrito tal y como se muestra en el listado 8-33. El Capítulo 13 explica en detalle la internacionalización.

Listado 8-32 - Mecanismo i18n implícito

propel:
  db_group:
    id:
    created_at:
 
  db_group_i18n:
    name:        varchar(50)

Listado 8-33 - Mecanismo i18n explícito

propel:
  db_group:
    _attributes: { isI18N: true, i18nTable: db_group_i18n }
    id:
    created_at:
 
  db_group_i18n:
    id:       { type: integer, required: true, primaryKey: true, foreignTable: db_group, foreignReference: id, onDelete: cascade }

    culture:  { isCulture: true, type: varchar(7), required: true, primaryKey: true }
    name:     varchar(50)

Los comportamientos son plugins que modifican el modelo de datos para añadir nuevas funcionalidades a las clases de Propel. El capítulo 17 explica los comportamientos en detalle. Desde la versión 1.1 de Symfony también es posible definir los comportamientos directamente en el esquema. Para ello, se añade su nombre y sus opciones bajo la clave _behaviors de cada tabla. El listado 8-34 muestra un ejemplo que extiende la clase BlogArticulo con el comportamiento llamado paranoid.

Listado 8-34 - Declarando los comportamientos

propel:
  blog_articulo:
    titulo:         varchar(50)
    _behaviors:
      paranoid:     { column: deleted_at }

En realidad, el formato de schema.yml es propio de Symfony. Cuando se ejecuta un comando que empieza por propel-, Symfony transforma ese archivo en otro archivo llamado generated-schema.xml, que es el tipo de archivo que necesita Propel para realizar sus tareas sobre el modelo.

El archivo schema.xml contiene la misma información que su equivalente en formato YAML. Por ejemplo, el listado 8-3 se convierte en el archivo XML del listado 8-35.

Listado 8-35 - Ejemplo de schema.xml, que se corresponde con el listado 8-3

<?xml version="1.0" encoding="UTF-8"?>

 <database name="propel" defaultIdMethod="native" noXsd="true" package="lib.model">

    <table name="blog_articulo" phpName="Articulo">
      <column name="id" type="integer" required="true" primaryKey="true" autoIncrement="true" />

      <column name="titulo" type="varchar" size="255" />

      <column name="contenido" type="longvarchar" />
      <column name="created_at" type="timestamp" />

    </table>
    <table name="blog_comentario" phpName="Comentario">
      <column name="id" type="integer" required="true" primaryKey="true" autoIncrement="true" />

      <column name="articulo_id" type="integer" />
      <foreign-key foreignTable="blog_articulo">

        <reference local="articulo_id" foreign="id"/>
      </foreign-key>
      <column name="autor" type="varchar" size="255" />

      <column name="contenido" type="longvarchar" />
      <column name="created_at" type="timestamp" />

    </table>
 </database>

La descripción del formato schema.xml se puede consultar en la documentación y la sección "Getting started" del sitio web del proyecto Propel (http://propel.phpdb.org/docs/usuario_guide/chapters/appendices/AppendixB-SchemaReference.html).

El formato del esquema en YAML se diseñó para que los esquemas fueran fáciles de leer y escribir, pero su inconveniente es que los esquemas más complejos no se pueden describir solamente con un archivo schema.yml. Por otra parte, el formato XML permite describir completamente el esquema, independientemente de su complejidad e incluye la posibilidad de incluir opciones propias de algunas bases de datos, herencia de tablas, etc.

Symfony también puede trabajar con esquemas escritos en formato XML. Así que no es necesario utilizar el formato YAML propio de Symfony si el esquema es demasiado complejo, si ya dispones de un esquema en formato XML o si estás acostumbrado a trabajar con la sintaxis XML de Propel. Solamente es necesario crear el archivo schema.xml en el directorio config/ del proyecto y construir el modelo.

La desventaja de utilizar un ORM es que se debe definir la estructura de datos 2 veces: una para la base de datos y otra para el modelo de objetos. Por suerte, Symfony dispone de utilidades de línea de comandos para generar uno en función del otro, de modo que se evita duplicar el trabajo.

Si se crea la aplicación escribiendo el archivo schema.yml, Symfony puede generar las instrucciones SQL que crean las tablas directamente a partir del modelo de datos en YAML. Para generarlas, se ejecuta el siguiente comando desde el directorio raíz del proyecto:

> php symfony propel:build-sql

El anterior comando crea un archivo lib.model.schema.sql en el directorio miproyecto/data/sql/. El código SQL generado se optimiza para el sistema gestor de bases de datos definido en el parámetro phptype del archivo propel.ini.

Se puede utilizar directamente el archivo schema.sql para construir la base de datos. Por ejemplo, en MySQL se puede ejecutar lo siguiente:

> mysqladmin -u root -p create blog
> mysql -u root -p blog < data/sql/lib.model.schema.sql

El código SQL generado también es útil para reconstruir la base de datos en otro entorno o para cambiar de sistema gestor de bases de datos. Si el archivo propel.ini define las opciones de conexión correctas con la base de datos, el comando php symfony propel:insert-sql se encarga de crear automáticamente las tablas.

Symfony puede utilizar la capa de acceso a bases de datos proporcionada por Propel para generar un archivo schema.yml a partir de una base de datos existente, gracias a la introspección (que es la capacidad de las bases de datos para determinar la estructura de las tablas que la forman). Se trata de una opción muy útil cuando se hace ingeniería inversa o si se prefiere trabajar primero en la base de datos antes de trabajar con el modelo de objetos.

Para construir el modelo, el archivo databases.yml del proyecto debe apuntar a la base de datos correcta y debe tener todas las opciones de conexión. Después, se ejecuta el comando propel:build-schema:

> php symfony propel:build-schema

Se genera un nuevo archivo schema.yml a partir de la estructura de la base de datos y se almacena en el directorio config/. Ahora se puede construir el modelo a partir de este esquema.

El comando para generar el esquema es bastante potente y es capaz de añadir diversa información relativa a la base de datos en el esquema. Como el formato YAML no soporta este tipo de información sobre la base de datos, se debe generar un esquema en formato XML para poder incluirla. Para ello, solo es necesario añadir el argumento xml a la tarea build-schema:

> php symfony propel:build-schema --xml

En vez de generar un archivo schema.yml, se crea un archivo schema.xml que es totalmente compatible con Propel y que contiene toda la información adicional. No obstante, los esquemas XML generados suelen ser bastante profusos y difíciles de leer.

// Base classes are autoloaded in symfony
// Set this to true to use include_once statements instead
// (Small negative impact on performance)
propel.builder.addIncludes = false
 
// Generated classes are not commented by default
// Set this to true to add comments to Base classes
// (Small negative impact on performance)

propel.builder.addComentarios = false
 
// Behaviors are not handled by default
// Set this to true to be able to handle them
propel.builder.AddBehaviors = false

Symfony utiliza Propel como ORM y PDO (PHP Data Objects) como la capa de abstracción de bases de datos. De esta forma, en primer lugar se debe describir el esquema relacional de la base de datos en formato YAML antes de generar las clases del modelo de objetos. Después, durante la ejecución de la aplicación, se utilizan los métodos de las clases objeto y clases peer para acceder a la información de un registro o conjunto de registros. Se puede redefinir y ampliar el modelo fácilmente añadiendo métodos a las clases personalizadas. Las opciones de conexión se definen en el archivo databases.yml, que puede definir más de una conexión. La línea de comandos contiene tareas especiales que evitan tener que definir la estructura de la base de datos más de una vez.

La capa del modelo es la más compleja del framework Symfony. Una de las razones de esta complejidad es que la manipulación de datos es una tarea bastante intrincada. Las consideraciones de seguridad relacionadas con el modelo son cruciales para un sitio web y no deberían ignorarse. Otra de las razones es que Symfony se ajusta mejor a las aplicaciones medianas y grandes en un entorno empresarial. En ese tipo de aplicaciones, las tareas automáticas proporcionadas por el modelo de Symfony suponen un gran ahorro de tiempo, por lo que merece la pena el tiempo dedicado a aprender su funcionamiento interno.

Así que no dudes en dedicar algo de tiempo a probar los objetos y métodos del modelo para entenderlos completamente. La recompensa será la gran solidez y escalabilidad de las aplicaciones desarrolladas.



Los enlaces y las URL requieren de un tratamiento especial en cualquier framework para aplicaciones web. El motivo es que la definición de un único punto de entrada a la aplicación (mediante el controlador frontal) y el uso de helpers en las plantillas, permiten separar completamente el funcionamiento y el aspecto de las URL. Este mecanismo se conoce como "enrutamiento" (del inglés "routing"). El enrutamiento no es solo una utilidad curiosa, sino que es una herramienta muy útil para hacer las aplicaciones web más fáciles de usar y más seguras. En este capítulo se detalla la forma de manejar las URL en las aplicaciones de Symfony:

• Qué es y como funciona el sistema de enrutamiento
• Cómo utilizar helpers de enlaces en las plantillas para enlazar URL salientes
• Cómo configurar las reglas de enrutamiento para modificar el aspecto de las URL

Además, se incluyen una serie de trucos para mejorar el rendimiento del sistema de enrutamiento y para añadirle algunos toques finales.

El enrutamiento es un mecanismo que reescribe las URL para simplificar su aspecto. Antes de poder comprender su importancia, es necesario dedicar unos minutos al estudio de las URL de las aplicaciones

Cuando el usuario realiza una acción, las URL se encargan de enviar la información desde el navegador hasta el servidor. Las URL tradicionales incluyen la ruta hasta el script del servidor y algunos parámetros necesarios para completar la petición, como se muestra en el siguiente ejemplo:

http://www.ejemplo.com/web/controlador/articulo.php?id=123456&codigo_formato=6532

La URL anterior incluye información sobre la arquitectura de la aplicación y sobre su base de datos. Normalmente, los programadores evitan mostrar la estructura interna de la aplicación en la interfaz (las páginas por ejemplo se titulan "Perfil personal" y no "QZ7.65"). Desvelar detalles internos de la aplicación en la URL no solo contradice esta norma, sino que tiene otras desventajas:

• Los datos técnicos que se muestran en las URL son una fuente potencial de agujeros de seguridad. En el ejemplo anterior, ¿qué sucede si un usuario malicioso modifica el valor del parámetro id? ¿Supone este caso que la aplicación ofrece una interfaz directa a la base de datos? ¿Qué sucedería si otro usuario probara otros nombres de script, como por ejemplo admin.php? En resumen, las URL directas permiten jugar de forma directa y sencilla con una aplicación y es casi imposible manejar su seguridad.
• Las URL complejas son muy difíciles de leer y hoy en día las URL no solo aparecen en la barra de direcciones. También suelen aparecer cuando un usuario pasa el ratón por encima de un enlace y también en los resultados de búsqueda. Cuando los usuarios buscan información, es más útil proporcionarles URL sencillas y fáciles de entender y no URL complejas como las que se muestran en la figura 9.1

Figura 9.1. Las URL aparecen en muchos lugares, como por ejemplo los resultados de búsqueda

• Si se modifica una URL (porque cambia el nombre del script o el de alguno de sus parámetros), se deben modificar todos los enlaces a esa URL. De esta forma, las modificaciones en la estructura del controlador son muy pesadas y costosas, lo que contradice la filosofía del desarrollo ágil de aplicaciones.

La situación podría ser incluso mucho peor si Symfony no utilizara un controlador frontal; es decir, si la aplicación contiene varios scripts accesibles desde el exterior, como por ejemplo:

http://www.ejemplo.com/web/galeria/album.php?nombre=mis%20vacaciones
http://www.ejemplo.com/web/weblog/publico/post/listado.php
http://www.ejemplo.com/web/general/contenido/pagina.php?nombre=sobre%20nosotros

En este caso, los programadores deben hacer coincidir la estructura de las URL y la estructura del sistema de archivos, por lo que su mantenimiento se convierte en una pesadilla cuando cualquiera de las dos estructuras se modifica.

Una de las ideas del sistema de enrutamiento es utilizar las URL como parte de la interfaz. Las aplicaciones trasladan información al usuario mediante el formateo de las URL y el usuario puede utilizar las URL para acceder a los recursos de la aplicación.

Lo anterior es posible en las aplicaciones Symfony porque la URL que se muestra al usuario no tiene que guardar obligatoriamente relación con la instrucción del servidor necesaria para completar la petición. En su lugar, la URL está relacionada con el recurso solicitado, y su aspecto puede configurarse libremente. En Symfony es posible por ejemplo utilizar la siguiente URL y obtener los mismos resultados que la primera URL mostrada en este capítulo:

http://www.ejemplo.com/articulos/economia/2006/sectores-actividad.html

Este tipo de URL tiene muchas ventajas:

• Las URL tienen significado y ayudan a los usuarios a decidir si la página que se cargará al pulsar sobre un enlace contiene lo que esperan. Un enlace puede contener detalles adicionales sobre el recurso que enlaza. Esto último es especialmente útil para los resultados de los buscadores. Además, muchas veces las URL aparecen sin que se mencione el título de su página (por ejemplo cuando se copian las URL en un mensaje de email) por lo que en ese caso deberían contener su propio significado. La figura 9-2 muestra una URL sencilla y fácil de entender.

Figura 9.2. Las URL pueden incluir información adicional sobre una página, como por ejemplo su fecha de publicación

• Las URL que aparecen en los documentos impresos son más fáciles de escribir y de recordar. Si la dirección del sitio web de una empresa se muestra en una tarjeta de visita con un aspecto similar a http://www.ejemplo.com/controlador/web/index.jsp?id=ERD4, probablemente no reciba muchas visitas.
• La URL se puede convertir en una especie de línea de comandos, que permita realizar acciones u obtener información de forma intuitiva. Este tipo de aplicaciones son las que más rápidamente utilizan los usuarios más avanzados.

// Listado de resultados: se puede añadir una nueva etiqueta para restringir los resultados
http://del.icio.us/tag/symfony+ajax
// Página de perfil de usuario: se puede modificar el nombre para obtener otro perfil
http://www.askeet.com/user/francois

• Se puede modificar el aspecto de la URL y el del nombre de la acción o de los parámetros de forma independiente y con una sola modificación. En otras palabras, es posible empezar a programar la aplicación y después modificar el aspecto de las URL sin estropear completamente la aplicación.
• Aunque se modifique la estructura interna de la aplicación, las URL pueden mantener su mismo aspecto hacia el exterior. De esta forma, las URL se convierten en persistentes y pueden ser añadidas a los marcadores o favoritos.
• Cuando los motores de búsqueda indexan un sitio web, suelen tratar de forma diferente (incluso saltándoselas) a las páginas dinámicas (las que acaban en .php, .asp, etc.) Así que si se formatean las URL de esta forma, los buscadores creen que están indexando contenidos estáticos, por lo que generalmente se obtiene una mejor indexación de las páginas de la aplicación.
• Son más seguras. Cualquier URL no reconocida se redirige a una página especificada por el programador y los usuarios no pueden navegar por el directorio raíz del servidor mediante la prueba de diferentes URL. La razón es que no se visualiza el nombre del script utilizado o el de sus parámetros.

La relación entre las URL mostradas al usuario y el nombre del script que se ejecuta y de sus parámetros está gestionada por el sistema de enrutamiento, que utiliza patrones que se pueden modificar mediante la configuración de la aplicación.

Symfony desasocia las URL externas y las URI utilizadas internamente. La correspondencia entre las dos es responsabilidad del sistema de enrutamiento. Symfony simplifica este mecanismo utilizando una sintaxis para las URI internas muy similar a la de las URL habituales. El listado 9-1 muestra un ejemplo.

Listado 9-1 - URL externas y URI internas

// Sintaxis de las URI internas
<modulo>/<accion>[?parametro1=valor1][&parametro2=valor2][&parametro3=valor3]...

// Ejemplo de URI interna que nunca se muestra al usuario
articulo/permalink?ano=2006&tema=economia&titulo=sectores-actividad

// Ejemplo de URL externa que se muestra al usuario
http://www.ejemplo.com/articulos/economia/2006/sectores-actividad.html

El sistema de enrutamiento utiliza un archivo de configuración especial, llamado routing.yml, en el que se pueden definir las reglas de enrutamiento. Si se considera la regla mostrada en el listado 9-2, se define un patrón cuyo aspecto es articulos/*/*/* y que también define el nombre de cada pieza que forma parte de la URL.

Listado 9-2 - Ejemplo de regla de enrutamiento

articulo_segun_titulo:
  url:    articulos/:tema/:ano/:titulo.html
  param:  { module: articulo, action: permalink }

Todas las peticiones realizadas a una aplicación Symfony son analizadas en primer lugar por el sistema de enrutamiento (que es muy sencillo porque todas las peticiones se gestionan mediante un único controlador frontal). El sistema de enrutamiento busca coincidencias entre la URL de la petición y los patrones definidos en las reglas de enrutamiento. Si se produce una coincidencia, las partes del patrón que tienen nombre se transforman en parámetros de la petición y se juntan a los parámetros definidos en la clave param:. El listado 9-3 muestra su funcionamiento.

Listado 9-3 - El sistema de enrutamiento interpreta las URL de las peticiones entrantes

// El usuario escribe (o pulsa) sobre esta URL externa
http://www.ejemplo.com/articulos/economia/2006/sectores-actividad.html

// El controlador frontal comprueba que coincide con la regla articulo_segun_titulo
// El sistema de enrutamiento crea los siguientes parámetros de la petición
  'module'  => 'articulo'
  'action'  => 'permalink'
  'tema'    => 'economia'
  'ano'     => '2006'
  'titulo'  => 'sectores-actividad'

Después, la petición se pasa a la acción permalink del módulo articulo, que dispone de toda la información necesaria en los parámetros de la petición para obtener el artículo solicitado.

El mecanismo de enrutamiento también funciona en la otra dirección. Para mostrar las URL en los enlaces de una aplicación, se debe proporcionar al sistema de enrutamiento la información necesaria para determinar la regla que se debe aplicar a cada enlace. Además, no se deben escribir los enlaces directamente con etiquetas <a> (ya que de esta forma no se estaría utilizando el sistema de enrutamiento) sino con un helper especial, tal y como se muestra en el listado 9-4.

Listado 9-4 - El sistema de enrutamiento formatea las URL externas mostradas en las plantillas

// El helper url_for() transforma una URI interna en una URL externa
<a href="<?php echo url_for('articulo/permalink?tema=economia&ano=2006&titulo=sectores-actividad') ?>">pincha aquí</a>
 
// El helper reconoce que la URI cumple con la regla articulo_segun_titulo
// El sistema de enrutamiento crea una URL externa a partir de el

 => <a href="http://www.ejemplo.com/articulos/economia/2006/sectores-actividad.html">pincha aquí</a>
 
// El helper link_to() muestra directamente un enlace
// y evita tener que mezclar PHP y HTML
<?php echo link_to(

  'pincha aqui',
  'articulo/permalink?tema=economia&ano=2006&titulo=sectores-actividad'
) ?>
 
// Internamente link_to() llama a url_for(), por lo que el resultado es el mismo
 => <a href="http://www.ejemplo.com/articulos/economia/2006/sectores-actividad.html">pincha aquí</a>

De forma que el enrutamiento es un mecanismo bidireccional y solo funciona cuando se utiliza el helper link_to() para mostrar todos los enlaces.

Antes de adentrarse en el funcionamiento interno del sistema de enrutamiento, se debe aclarar una cuestión importante. En los ejemplos mostrados en las secciones anteriores, las URI internas no incluyen el controlador frontal (index.php o frontend_dev.php). Como se sabe, es el controlador frontal y no otros elementos de la aplicación, el que decide el entorno de ejecución. Por este motivo, todos los enlaces deben ser independientes del entorno de ejecución y el nombre del controlador frontal nunca aparece en las URI internas.

Además, tampoco se muestra el nombre del script PHP en las URL generadas en los ejemplos anteriores. La razón es que, por defecto, las URL no contienen el nombre de ningún script de PHP en el entorno de producción. El parámetro no_script_name del archivo settings.yml controla la aparición del nombre del controlador frontal en las URL generadas. Si se establece su valor a off, como se muestra en el listado 9-5, las URL generadas por los helpers incluirán el nombre del script del controlador frontal en cada enlace.

Listado 9-5 - Mostrando el nombre del controlador frontal en las URL, en apps/frontend/config/settings.yml

prod:
  .settings:
    no_script_name:  off

Ahora, las URL generadas tienen este aspecto:

http://www.ejemplo.com/index.php/articulos/economia/2006/sectores-actividad.html

En todos los entornos salvo en el de producción, el parámetro no_script_name tiene un valor igual a off por defecto. Si se prueba la aplicación en el entorno de desarrollo, el nombre del controlador frontal siempre aparece en las URL.

http://www.ejemplo.com/frontend_dev.php/articulos/economia/2006/sectores-actividad.html

En el entorno de producción, la opción no_script_name tiene el valor de on, por lo que las URL solo muestran la información necesaria para el enrutamiento y son más sencillas para los usuarios. No se muestra ningún tipo de información técnica.

http://www.ejemplo.com/articulos/economia/2006/sectores-actividad.html

¿Cómo sabe la aplicación el nombre del script del controlador frontal que tiene que ejecutar? En este punto es donde comienza la reescritura de URL. El servidor web se puede configurar para que se llame siempre a un mismo script cuando la URL no indica el nombre de ningún script.

En el servidor web Apache se debe tener activado previamente el módulo mode_rewrite. Todos los proyectos de Symfony incluyen un archivo llamado .htaccess que añade las opciones necesarias para el mod_rewrite de Apache en el directorio web/. El contenido por defecto de este archivo se muestra en el listado 9-6.

Listado 9-6 - Reglas de reescritura de URL por defecto para Apache, en miproyecto/web/.htaccess

<IfModule mod_rewrite.c>
  RewriteEngine On

  # we skip all files with .something
  RewriteCond %{REQUEST_URI} \..+$
  RewriteCond %{REQUEST_URI} !\.html$
  RewriteRule .* - [L]

  # we check if the .html version is here (caching)
  RewriteRule ^$ index.html [QSA]
  RewriteRule ^([^.]+)$ $1.html [QSA]
  RewriteCond %{REQUEST_FILENAME} !-f

  # no, so we redirect to our front web controller
  RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>

El servidor web analiza la estructura de las URL entrantes. Si la URL no contiene ningún sufijo y no existe ninguna versión cacheada de la página disponible (el Capítulo 12 detalla el sistema de cache), la petición se redirige al script index.php.

No obstante, el directorio web/ de un proyecto Symfony lo comparten todas las aplicaciones y todos los entornos de ejecución del proyecto. Por este motivo, es habitual que exista más de un controlador frontal en el directorio web. Por ejemplo, si un proyecto tiene dos aplicaciones llamadas frontend y backend y dos entornos de ejecución llamados dev y prod, el directorio web/ contiene 4 controladores frontales:

index.php         // frontend en prod
frontend_dev.php  // frontend en dev
backend.php       // backend en prod
backend_dev.php   // backend en dev

Las opciones de mod_rewrite solo permiten especificar un script por defecto. Si se establece el valor on a la opción no_script_name de todas las aplicaciones y todos los entornos, todas las URL se interpretan como si fueran peticiones al controlador frontal de la aplicación frontend en el entorno de producción (prod). Esta es la razón por la que en un mismo proyecto, solo se pueden aprovechar del sistema de enrutamiento una aplicación y un entorno de ejecución concretos.

Debido al sistema de enrutamiento, es conveniente utilizar los helpers de enlaces en las plantillas en vez de etiquetas <a> normales y corrientes. Más que una molestia, el uso de estos helpers debe verse como un método sencillo de mantener la aplicación limpia y muy fácil de mantener. Además, los helpers de enlaces incluyen una serie de utilidades y atajos que no es recomendable desaprovechar.

En secciones anteriores ya se ha mostrado el helper link_to(). Se utiliza para mostrar enlaces válidos según XHTML y requiere de 2 parámetros: el elemento que va a mostrar el enlace y la URI interna del recurso al que apunta el enlace. Si en vez de un enlace se necesita un botón, simplemente se utiliza el helper button_to(). Los formularios también disponen de un helper para controlar el valor del atributo action. El siguiente capítulo explica los formularios en detalle. El listado 9-7 muestra algunos ejemplos de helpers de enlaces.

Listado 9-7 - Helpers de enlaces para las etiquetas <a>, <input> y <form>

// Enlace simple de texto
<?php echo link_to('Mi artículo', 'articulo/ver?titulo=Economia_en_Francia') ?>

 => <a href="/url/con/enrutamiento/a/Economia_en_Francia">Mi artículo</a>
 
// Enlace en una imagen
<?php echo link_to(image_tag('ver.gif'), 'articulo/ver?titulo=Economia_en_Francia') ?>

 => <a href="/url/con/enrutamiento/a/Economia_en_Francia"><img src="/images/ver.gif" /></a>
 
// Boton
<?php echo button_to('Mi artículo', 'articulo/ver?titulo=Economia_en_Francia') ?>

 => <input value="Mi artículo" type="button" onclick="document.location.href='/url/con/enrutamiento/a/Economia_en_Francia';" />
 
// Formulario

<?php echo form_tag('articulo/ver?titulo=Economia_en_Francia') ?>
 => <form method="post" action="/url/con/enrutamiento/a/Economia_en_Francia" />

Los helpers de enlaces aceptan URI internas y también URL absolutas (las que empiezan por http:// y para las que no se aplica el sistema de enrutamiento) y URL internas a una página (también llamadas anclas). Las aplicaciones reales suelen construir sus URI internas en base a una serie de parámetros dinámicos. El listado 9-8 muestra ejemplos de todos estos casos.

Listado 9-8 - URL que admiten los helpers de enlaces

// URI interna
<?php echo link_to('Mi artículo', 'articulo/ver?titulo=Economia_en_Francia') ?>

 => <a href="/url/con/enrutamiento/a/Economia_en_Francia">Mi artículo</a>
 
// URI interna con parámetros dinámicos
<?php echo link_to('Mi artículo', 'articulo/ver?titulo='.$articulo->getTitulo()) ?>

 
// URI interna con anclas (enlaces a secciones internas de la página)
<?php echo link_to('Mi artículo', 'articulo/ver?titulo=Economia_en_Francia#seccion1') ?>
 => <a href="/url/con/enrutamiento/a/Economia_en_Francia#seccion1">Mi artículo</a>

 
// URL absolutas
<?php echo link_to('Mi artículo', 'http://www.ejemplo.com/cualquierpagina.html') ?>
 => <a href="http://www.ejemplo.com/cualquierpagina.html">Mi artículo</a>

Como se explicó en el Capítulo 7, los helpers aceptan como argumento opciones adicionales, que se pueden indicar en forma de array asociativo o en forma de cadena de texto. Los helpers de enlaces también aceptan este tipo de opciones, como muestra el listado 9-9.

Listado 9-9 - Los helpers de enlaces aceptan opciones adicionales

// Opciones adicionales como array asociativo
<?php echo link_to('Mi artículo', 'articulo/ver?titulo=Economia_en_Francia', array(

  'class'  => 'miclasecss',
  'target' => '_blank'
)) ?>

 
// Opciones adicionales como cadena de texto (producen el mismo resultado)
<?php echo link_to('Mi artículo', 'articulo/ver?titulo=Economia_en_Francia','class=miclasecss target=_blank') ?>

 => <a href="/url/con/enrutamiento/a/Economia_en_Francia" class="miclasecss" target="_blank">Mi artículo</a>

También se pueden utilizar otras opciones específicas de Symfony llamadas confirm y popup. La primera muestra una ventana JavaScript de confirmación al pinchar en el enlace y la segunda opción abre el destino del enlace en una nueva ventana, como se muestra en el listado 9-10.

Listado 9-10 - Opciones confirm y popup en los helpers de enlaces

<?php echo link_to('Borrar elemento', 'item/borrar?id=123', 'confirm=¿Estás seguro?') ?>

 => <a onclick="return confirm('¿Estás seguro?');"
       href="/url/con/enrutamiento/a/borrar/123.html">Borrar elemento</a>
 
<?php echo link_to('Añadir al carrito', 'carritoCompra/anadir?id=100', 'popup=true') ?>

 => <a onclick="window.open(this.href);return false;"
       href="/url/con/enrutamiento/a/carritoCompra/anadir/id/100.html">Añadir al carrito</a>
 
<?php echo link_to('Añadir al carrito', 'carritoCompra/anadir?id=100', array(

  'popup' => array('popupWindow', 'width=310,height=400,left=320,top=0')
)) ?>

 => <a onclick="window.open(this.href,'popupWindow','width=310,height=400,left=320,top=0');return false;"
       href="/url/con/enrutamiento/a/carritoCompra/anadir/id/100.html">Añadir al carrito</a>

Estas opciones también se pueden combinar entre si.

En ocasiones, los programadores web utilizan peticiones GET para realizar acciones más propias de una petición POST. Si se considera por ejemplo la siguiente URL:

http://www.ejemplo.com/index.php/carritoCompra/anadir/id/100

Este tipo de petición modifica los datos de la aplicación, ya que añade un elemento al objeto que representa el carrito de la compra y que se almacena en la sesión del servidor o en una base de datos. Si los usuarios añaden esta URL a los favoritos de sus navegadores o si la URL se cachea o es indexada por un buscador, se pueden producir problemas en la base de datos y en las métricas del sitio web. En realidad, esta petición debería tratarse como una petición de tipo POST, ya que los robots que utilizan los buscadores no hacen peticiones POST para indexar las páginas.

Symfony permite transformar una llamada a los helpers link_to() o button_to() en una petición POST. Solamente es necesario añadir la opción post=true, tal y como se muestra en el listado 9-11.

Listado 9-11 - Convirtiendo un enlace en una petición POST

<?php echo link_to('Ver carrito de la compra', 'carritoCompra/anadir?id=100', 'post=true') ?>

 => <a onclick="f = document.createElement('form'); document.body.appendChild(f);
                f.method = 'POST'; f.action = this.href; f.submit();return false;"
       href="/carritoCompra/anadir/id/100.html">Ver carrito de la compra</a>

La etiqueta <a> resultante conserva el atributo href, por lo que los navegadores sin soporte de JavaScript, como por ejemplo los robots que utilizan los buscadores, utilizan el enlace normal con la petición GET. Asi que es posible que se deba restringir la acción para que solamente responda a las peticiones de tipo POST, que se puede realizar añadiendo por ejemplo la siguiente instrucción al principio de la acción:

$this->forward404Unless($this->getRequest()->isMethod('post'));

Esta opción no se debe utilizar en los enlaces que se encuentran dentro de los formularios, ya que genera su propia etiqueta <form>.

Se trata de una buena práctica definir como peticiones POST los enlaces que realizan acciones que modifican los datos.

Las variables que se pasan como parámetro a link_to() se transforman en patrones según las reglas del sistema de enrutamiento. Si no existe en el archivo routing.yml ninguna regla que coincida con la URI interna, se aplica la regla por defecto que transforma modulo/accion?clave=valor en /modulo/accion/clave/valor, como se muestra en el listado 9-12.

Listado 9-12 - Regla de enrutamiento por defecto

<?php echo link_to('Mi artículo', 'articulo/ver?titulo=Economia_en_Francia') ?>

=> <a href="/articulo/ver/titulo/Economia_en_Francia">Mi artículo</a>

Si quieres utilizar la sintaxis de las peticiones GET (para pasar los parámetros de la petición en la forma ?clave=valor) se deben indicar los parámetros en la opción query_string.

Si se utilizan enlaces que tienen una parte correspondiente a las anclas se pueden producir conflictos. Por ello, el nombre del ancla se debe indicar en la opción anchor en vez de añadirlo directamente a la URL. Todos los helpers de enlaces aceptan estas opciones, tal y como se muestra en el listado 9-13.

Listado 9-13 - Forzando el uso de variables tipo GET con la opción query_string

<?php echo link_to('Mi artículo', 'articulo/ver', array(
  'query_string' => 'titulo=Economia_en_Francia',
  'anchor' => 'seccion_dentro_de_la_pagina'

)) ?>
=> <a href="/articulo/ver?titulo=Economia_en_Francia#seccion_dentro_de_la_pagina">Mi artículo</a>

Las URL con los parámetros en forma de variables GET se pueden interpretar por los scripts en el lado del cliente y por las variables $_GET y $_REQUEST en el lado del servidor.

<?php echo image_tag('prueba', 'alt=Prueba') ?>

<?php echo image_tag('prueba.gif', 'title=Prueba') ?>
<?php echo image_tag('/mis_imagenes/prueba.gif', 'alt_title=Prueba') ?>

 => <img href="/images/prueba.png" alt="Prueba" />
    <img href="/images/prueba.gif" title="Prueba" />

    <img href="/mis_imagenes/prueba.gif" alt="Prueba" title="Prueba" />

<?php echo image_tag('prueba', 'size=100x20')) ?>
 => <img href="/images/prueba.png" width="100" height="20"/>

Los helpers de enlaces y de contenidos estáticos generan rutas relativas por defecto. Para forzar el uso de rutas absolutas, se debe asignar el valor true a la opción absolute, como muestra el listado 9-14. Esta técnica es muy útil cuando se deben incluir enlaces en mensajes de email, canales RSS o respuestas de una API.

Listado 9-14 - Utilizando URL absolutas en vez de relativas

<?php echo url_for('articulo/ver?titulo=Economia_en_Francia') ?>

 => '/url/con/enrutamiento/a/Economia_en_Francia'
<?php echo url_for('articulo/ver?titulo=Economia_en_Francia', true) ?>

 => 'http://www.ejemplo.com/url/con/enrutamiento/a/Economia_en_Francia'
 
<?php echo link_to('economía', 'articulo/ver?titulo=Economia_en_Francia') ?>

 => <a href="/url/con/enrutamiento/a/Economia_en_Francia">economía</a>
<?php echo link_to('economía', 'articulo/ver?titulo=Economia_en_Francia','absolute=true') ?>

 => <a href=" http://www.ejemplo.com/url/con/enrutamiento/a/Economia_en_Francia">economía</a>
 
// Lo mismo sucede con los helpers de contenidos estáticos
<?php echo image_tag('prueba', 'absolute=true') ?>

<?php echo javascript_include_tag('miscript', 'absolute=true') ?>

<?php echo mail_to('midireccion@midominio.com', 'contacto') ?>
 => <a href="mailto:midireccion@midominio.com">contacto</a>

<?php echo mail_to('midireccion@midominio.com', 'contacto', 'encode=true') ?>
 => <a href="&#109;&#x61;... &#111;&#x6d;">&#x63;&#x74;... e&#115;&#x73;</a>