Facultad de Informática – U.N.L.P.

Taller de Symfony – Octubre 2007

Clase 1

1. Que temas veremos

● Instalación de Symfony: (sandbox, PEAR)

○ Windows: Variables de entorno

○ Configuración Web Server

● Iniciando la aplicación

○ Creación del proyecto “blog”

○ Creación de una aplicación “front”

○ Análisis de la estructura generada

○ Módulos y Acciones

● Modelo de datos de la aplicación

○ Configuración: schema.yml, schema.xml, propel.ini, databases.yml

○ Generación del modelo: Comandos

○ Inspeccionar el modelo: Getters y Setters. Agregando Nueva funcionalidad.

● Entornos de ejecución: Producción, Desarrollo, Testing

● Primeros pasos

○ Modulo y acción por defecto: settings.yml

○ Configuración general de la vista: view.yml

○ Layout de la aplicación

■ Partial's: Header, Footer, Menú

2. Desarrollo

2.1. Instalación
Los únicos requisitos para instalar y trabajar con Symfony son los de disponer de
un servidor web, cualquier versión de PHP 5 y una consola de comandos del sistema
operativo. Cumplidos los requisitos anteriores, Symfony se puede instalar de varias
formas.
 Si sólo queremos probar el framework lo más rápido posible, se puede utilizar el
“sandbox”, que es un archivo comprimido (se entrega en el cd del taller) que contiene
todos los archivos del framework. Este archivo se descomprime en la carpeta principal del
servidor y ya se puede acceder al framework vía:
http://localhost/sf_sandbox
Sin embargo, el método preferido de instalación de Symfony es mediante PEAR, ya
que es tan sencillo como instalar el “sandbox”, funciona igual de bien en cualquier sistema
operativo y se instala en menos de 1 minuto. Lo primero que debemos hacer es instalar
PEAR, para ello ejecutamos:
En linux:
apt-get install php-pear
En Windows
go-pear.bat
Una vez que PEAR se encuentra correctamente instalado, solamente es necesario
ejecutar los siguientes comandos:
pear channel-discover pear.symfony-project.com
pear install symfony/symfony
Este ultimo método es el preferido por los programadores porque es el más fácil de
actualizar y permite que todos los proyectos desarrollados con Symfony compartan la
misma versión del framework. Para el desarrollo del taller, vamos a considerar tener
instalado el framework mediante PEAR.
Para el caso de que se instale en Windows, es recomendable agregar a la variable
de ambiente PATH la ruta donde instalamos PHP, dado que en ese mismo directorio
contaremos con el comando pear.bat y symfony.bat, siendo este ultimo necesario para
trabajar con nuestro proyecto Symfony.
Una buena práctica cuando se desarrollan aplicaciones web consiste en crear un
servidor virtual por cada proyecto. Symfony también recomienda lo mismo para cada
proyecto.
De esta forma, se puede acceder a nuestro proyecto mediante una URL sencilla
como:
http://blog/
en lugar de:
http://localhost/blog
http://localhost/sf_sandbox/blog
o cualquier otra URL más larga.
Para crear el servidor virtual, se configura un nuevo VirtualHost en Apache:
En Linux:
<VirtualHost *:80>
ServerName blog
DocumentRoot "/home/proyectos/blog/web"
DirectoryIndex index.php

Alias /sf /php/pear/data/symfony/web/sf

 <Directory "/php/pear/data/symfony/web/sf">
AllowOverride All
Allow from All
</Directory>

<Directory "/home/proyectos/blog/web">
AllowOverride All
Allow from All
</Directory>
</VirtualHost>

En Windows:
<Directory "c:/wamp/php/pear/data/symfony/web/sf">
Allow from All
</Directory>
<VirtualHost *:80>
ServerName blog
DocumentRoot "c:/wamp/www/prueba/web"
DirectoryIndex index.php
Alias /sf "c:/wamp/php/pear/data/symfony/web/sf"
<Directory "c:/wamp/www/prueba/web">
AllowOverride All
Order deny,allow
Allow from all
</Directory>
</VirtualHost>

El valor de la directiva DocumentRoot es la ruta completa hasta el directorio web

dentro del proyecto. El Alias /sf definido es necesario para que se vean las imágenes,
JavaScripts y CSS del propio framework (que se utilizan en el entorno de desarrollo) y
debe contener la ruta completa hasta el directorio web/sf dentro del directorio en el que
se ha instalado Symfony.
Antes de poder acceder al proyecto mediante la dirección
http://blog
es necesario editar el archivo /etc/hosts (si utilizamos Linux) o
c:\WINDOWS\system32\drivers\etc\hosts (si utilizamos Windows) para indicar
que blog es un nombre que realmente hace referencia al propio ordenador de desarrollo:
127.0.0.1 localhost
127.0.0.1 blog
2.2. Iniciando la Aplicación
Symfony divide los proyectos web en aplicaciones y módulos. En el taller,
llamaremos al proyecto blog. Dentro de un proyecto, se pueden definir diferentes
aplicaciones, todas ellas compartiendo el mismo modelo de datos y un mismo nombre de
dominio.
Todos los proyectos web habituales suelen estar formados por una parte pública a
la que acceden los usuarios y una parte de administración con la que los responsables del
sitio manejan su funcionamiento y gestionan sus contenidos.
La parte pública (llamada normalmente frontend, por su nombre en inglés) sería
una aplicación del proyecto y la parte de administración (llamada normalmente backend)
sería otra aplicación distinta dentro del mismo proyecto. Para el taller, solo trabajemos con
una parte publica, por lo que crearemos una aplicación a nuestro proyecto que se llame
frontend.

Además, cada aplicación se puede dividir en varios módulos. Cada módulo suele
corresponderse con una tabla de la base de datos, aunque no es obligatorio que así sea.
Los módulos de nuestro taller los iremos definiendo a medida que avancemos, pero
podemos considerar que vamos a tener al menos los siguientes: articulo y comentario.
Lo primero que debemos hacer es crear un directorio donde vamos a trabajar (el
indicado en el virtual host configurado en la sección de instalación) con nuestro proyecto,
luego inicializamos el proyecto, para eso ejecutamos desde una consola y parados en el
directorio antes creado:
symfony init-project blog
Luego, creamos nuestra aplicación frontend, para ello ejecutamos:
symfony init-app frontend

Además, crearemos un primer modulo, al que llamaremos default y que iremos

trabajando. Para esto, ejecutamos:
symfony init-module frontend default
 Luego de haber ejecutado los comandos anteriores, Symfony nos creara la
siguiente estructura de directorios:

Aplicaciones de nuestro proyecto

Aplicación frontend

Módulos de la aplicación frontend

Acciones del modulo default

Templates (“vistas”) de las acciones 
del modulo default

Templates (“vistas”) o Layout para la 
aplicación frontend

Cache de archivos

Archivos de configuración para todo 
el proyecto

Clases comunes a todo el proyecto 
(inclusive modelo) 

Directorio que sera para parte web de 
nuestras aplicaciones: index.php, JS, 
CSS, imagenes, etc.
 Si todo esta correctamente configurado, al acceder a la dirección con nuestro
navegador:
http://blog
se muestra la página de bienvenida por defecto de Symfony:

2.3. Modelo de Datos
Una vez creada la estructura básica del proyecto, se definen las opciones de
conexión con la base de datos y se crea el esquema que representa el modelo de datos
del proyecto. Las opciones de conexión se definen en el archivo de configuración
config/databases.yml, en el que se deben descomentar todas sus líneas eliminando
el carácter # que se incluye por defecto al principio de cada línea:
all:
propel:
class: sfPropelDatabase
param:
dsn: mysql://root:contrasena@localhost/blog
Los archivos de configuración de Symfony utilizan el formato YAML, el preferido por
todos los frameworks modernos, en vez del tradicional y más aburrido formato XML.
La única opción que se debe modificar es el dsn que define las opciones de
conexión con la base de datos. Symfony permite utilizar bases de datos de tipo SQLite,
MySQL, PostgreSQL, Oracle y SQL Server. Cambiar de base de datos sólo requiere
modificar la opción dsn, ya que el resto de la aplicación funciona igual de bien con
cualquier sistema gestor de base de datos.
La palabra all significa que estas opciones de conexión se utilizan en todos los
entornos de ejecución, que analizaremos más adelante. La palabra propel es el nombre
que se le da a esta conexión con la base de datos. Propel también es el nombre de una
herramienta externa incluida en Symfony.
También es necesario configurar el archivo config/propel.ini, que contiene
parámetros de configuración de Propel. En especial, solo vamos a configurar los
siguientes valores:
...........
propel.database = mysql
propel.database.createUrl = mysql://root:pass@localhost
propel.database.url = mysql://root:pass@localhost/blog
............
aquí le indicamos a Propel que tipo de base de datos utilizamos, cual es el dsn de la base
de datos, en caso de contar ya con la misma y cual es el dsn de donde debería crearla, en
caso de contar con el esquema y querer generarla a partir de este (a continuación
veremos los comandos para estos pasos).
Propel es un ORM, lo que significa que, gracias a Propel, se puede trabajar con
una base de datos sin utilizar instrucciones SQL. Para crear, obtener, modificar o borrar
datos de la base de datos, no es necesario escribir ni una sola sentencia SQL, ya que se
puede trabajar directamente con objetos, como veremos en el desarrollo del taller.
Una vez definida la conexión con la base de datos, se crea en el archivo
config/schema.yml el esquema de la base de datos que representa el modelo de
datos del proyecto (en la carpeta de material para el taller de esta clase se puede
encontrar este archivo completo):
propel:
articulo:
_attributes: { phpName: Articulo }
id:
titulo: varchar(50)
contenido: longvarchar
usuario_id:
created_at:
comentario:
_attributes: { phpName: Comentario }
id:
articulo_id:
autor: varchar(255)
contenido: longvarchar
created_at:
.............

Este archivo describe el siguiente modelo de datos:

donde:
● Un articulo es escrito por un usuario.
● Los comentarios corresponden a un articulo y pueden o no ser realizados por un
usuario.
● Un usuario puede tener 0..n credenciales

El esquema (schema.yml) define la estructura de tablas y columnas de la base de

datos del proyecto. Entre las opciones que puede definir para cada tabla, se encuentra la
opción phpName, que indica el nombre de la clase PHP utilizada para manejar cada tabla.
Las columnas se definen mediante su nombre y el tipo de dato que almacena.
El tipo de dato no es obligatorio, ya que en algunos casos, Symfony es capaz de
deducirlo a partir del nombre de la columna. Si por ejemplo una columna se llama id, salvo
que se le indique lo contrario, Symfony supone que es la clave primaria de la tabla y, por
tanto, que es de tipo entero, que no puede tomar valores null y que su valor se
autoincrementa.
Si una columna se llama xxxxxx_id, Symfony supone que es una clave externa
que hace referencia a la tabla xxxxxxx (se puede utilizar el valor indicado en el atributo
phpName).
Otras columnas “mágicas” son created_at y updated_at. Si una columna se llama
created_at, Symfony la considera de tipo “fecha y hora” y cada vez que se crea un registro
en la tabla, Symfony se encarga de asignarle el valor correcto de forma automática. La
columna updated_at también se considera de tipo “fecha y hora” y su valor se actualiza
automáticamente cada vez que se modifica el registro de la base de datos.
El esquema definido es independiente del sistema gestor de base de datos, por lo
que si en cualquier momento del desarrollo del proyecto se decide cambiar de MySQL a
SQLite o de PostgreSQL a Oracle, sólo se deben modificar las opciones de conexión del
archivo config/databases.yml.
Por otra parte, el comando:
symfony propel-build-sql
genera el archivo data/sql/lib.model.schema.sql que contiene las sentencias
SQL que permiten crear la base de datos en función del esquema planteado.
Si antes de empezar el proyecto Symfony ya dispones de una base de datos,
puedes hacer el trabajo inverso: generar el esquema y luego las clases PHP a partir de
una base de datos existente. Para ellos, ejecutamos el siguiente comando:
symfony propel-build-schema

Una vez definido el esquema, Symfony es capaz de generar el modelo de objetos

automáticamente. Para ello, ejecutamos el siguiente comando:
symfony propel-build-model
El modelo es generado bajo el directorio lib/model, donde se crean las clases PHP
que se representan el modele de datos:
 Clases “Base”. Contienen la lógica Se 
regeneran cada vez que armamos el 
modelo. Nunca debemos modificarlas.

Clases que podemos modificar para 
extender el modelo. Solo se generan 
una vez.  Extienden a las clases “Base”.

Symfony separa al modelo en dos conjuntos de clases. Un conjunto que vamos a

llamar “Clases Base” que contienen la lógica de los objetos en función del modelo. Estas
clases son generadas cada vez que armamos el modelo por lo que no debemos escribir o
modificar código en las mismas. Estas clases son almacenadas bajo el directorio
lib/modelo/om y los archivos correspondientes comienzan con el nombre Base.
El otro conjunto de clases se crean bajo el directorio lib/model y extienden a las
clases base. Estas son generadas una única vez y son las que debemos utilizar si
queremos modificar / agregar funcionalidad de nuestro modelo.
Por ejemplo, vamos a modificar la clase “Usuario” de manera de modificar la lógica
del método “setPassword” para encriptar la contraseña utilizando el algoritmo MD5. Para
ello, abrimos el archivo Usuario.php y agregamos lo siguiente:
 public function setPassword($v)
{
parent::setPassword(md5($v));

Las clases que representan el modelo, cuentan con los getters y setters para cada
columna, así como métodos que permiten:
● save() : salvar el objeto a la base de datos (nueva fila si el objeto es nuevo o
modificar si el objeto ya correspondía con una).
● isNew(): saber si el objeto es nuevo y aún no fue guardado.
● isModified(): saber si el objeto esta modificado.
● delete(): para borrar de la base de datos.
● etc.
Existe un conjunto de clases llamadas “Peer”, que contienen lógica para acceder a
la base de datos (salvar, borrar, seleccionar). Estas clases no se instancian sino que
contienen un conjunto de métodos estáticos, como por ejemplo:
● doSelect($criteria) : ejecutar un select sobre el la tabla a la que corresponde en
función del criterio que reciben como parámetro.
● doDelete($criteria): ejecutar un delete sobre la base en función del criterio que
reciben como parámetro.
● retrieveByPk($id): retorna el objeto correspondiente con clave $id.
● etc.
y un conjunto de constantes que representan las diferentes columnas de la tabla que
representas, por ejemplo:
● UsuarioPeer::USERNAME
● ArticuloPeer: TITULO
● etc.
Para ver un ejemplo, agreguemos a nuestra clase UsuarioPeer un método que nos
permite obtener un usuario dado el username o null si no existe. Para ello, agregamos el
siguiente método en el archivo UsuarioPeer.php:
public static function retrieveByUsername($us)
{
$c = new Criteria();
$c->add(UsuarioPeer::USERNAME,$us);
return UsuarioPeer::doSelectOne($c);
}
En el ejemplo, aparece la utilización de un objeto Criteria. Este, nos permite
escribir consultas a la base de datos, respetando un modelo de objetos y sin tener la
necesidad de escribir código SQL. A lo largo del taller vamos a ir viendo mas ejemplos del
mismo. También cuentan con un anexo en la carpeta material_adicional/documentos
del cd del taller (es recomendable tener leído este anexo para la clase 2).
2.4. Entornos de ejecución 
Las aplicaciones Symfony se pueden ejecutar en diferentes entornos, todos ellos
compartiendo el mismo código PHP pero diferenciándose en la configuración utilizada.
Cuando se crea una aplicación, Symfony crea por defecto tres entornos: producción
(prod), pruebas (test) y desarrollo (dev). Además de estos entornos iniciales, se pueden
crear todos los entornos adicionales que se consideren necesarios.
Lo que diferencia un entorno de otro son las opciones con las que se ejecuta la
aplicación. En el entorno de desarrollo, Symfony registra en el archivo de log todos los
mensajes que se producen y desactiva la caché, para que todos los cambios en la
configuración de la aplicación tengan un efecto inmediato. En el entorno de producción,
sólo se guardan en el archivo de log los mensajes de error y la caché se activa para
mejorar el rendimiento de la aplicación.
La definición de varios entornos permite utilizar una base de datos cuando se
desarrolla la aplicación y otra base de datos diferente cuando la aplicación se encuentra
en el servidor de producción. En los archivos de configuración, todas las opciones que se
indican bajo la palabra dev: tienen efecto en el entorno de desarrollo, las opciones bajo
prod: se utilizan en el entorno de producción y las opciones bajo all: son utilizadas en
todos los entornos en los que se ejecuta la aplicación. Por ejemplo, podemos configurar el
archivo config/databases.yml de la siguiente forma:
prod:
propel:
class: sfPropelDatabase
param:
dsn: mysql://user:pass@localhost/blog_prod

all:
propel:
class: sfPropelDatabase
param:
dsn: mysql://root:pass@localhost/blog
en el cual, nuestra base de datos en producción es diferente a la base utilizada en
desarrollo (por defecto, indicada bajo la directiva all:).
Las aplicaciones Symfony utilizan un patrón de diseño conocido como “controlador
frontal”, que consiste en utilizar un único punto de entrada a cada aplicación.
Concretamente, todas las peticiones que realiza el usuario se controlan mediante un único
script de PHP, que se encarga de redirigir las peticiones a cada módulo y acción
correspondientes en cada caso.
Symfony crea en el directorio web del proyecto dos controladores frontales para
cada nueva aplicación. El controlador frontal de desarrollo se denomina
nombreAplicacion + _dev.php, por lo que en lo que venimos creando al momento
del taller, Symfony creo el controlador frontend_dev.php. El controlador frontal de
producción de la primera aplicación creada (en este ejemplo, la aplicación frontend) se
denomina index.php y el del resto de aplicaciones se llaman igual que la aplicación (por
ejemplo, backend.php).
 De esta forma, para acceder a la aplicación frontend en el entorno de producción,
se utiliza la URL:
http://blog/index.php
Para acceder a la aplicación frontend en el entorno de desarrollo, se utiliza la URL:
http://blog/frontend_dev.php
Cuando se accede a una aplicación en el entorno de desarrollo, cualquier cambio
que se haya realizado en su configuración tiene efecto inmediato. Sin embargo, el entorno
de producción utiliza la caché de configuración, por lo que debe borrarse esta caché cada
vez que se quiera acceder en producción y que se tengan en cuenta los cambios
realizados. Para borrar la caché, se utiliza el comando:
symfony crear-cache
o, la versión resumida
symfony cc

2.5. Primeros Pasos
Por ultimo, durante esta clase, analizaremos algunos archivos de configuración de
la aplicación y escribiremos nuestra primer acción que sera la pagina de bienvenida al
blog.
Los archivos de configuración de la aplicación se encuentran dentro de la carpeta
apps/frontend/config.
Como primer instancia analizaremos el archivo apps/frontend/config/view.yml.
En este se indican parámetros referentes a la vista de la aplicación, como pueden ser: el
titulo de la pagina, los archivos de estilo que se quieren incluir así como los de de
JavaScript y el Layout por defecto que tendrá la pagina de la aplicación.

Nota: Recordar que la vista final del resultado de una acción esta formado por el
template de la acción embebido en el layout de la aplicación:

Por ejemplo, nuestro archivo se vería de la siguiente forma:

default:
http_metas:
content-type: text/html

metas:
title: Blog del taller de Symfony
 robots: blog, symfony
description: Taller para aprender Symfony
keywords: log, symfony
language: es

stylesheets: [main, style_1]

javascripts: [ ]

has_layout: on
layout: layout

El parámetro stylesheets es un arreglo con archivos css que se desean incluir en

el layout. Vamos a agregar un archivo para mejorar nuestro blog: style_1.css (se
encuentra dentro de la carpeta clase_1 del cd). Este archivo debemos colocarlo en la
carpeta web/css.
El archivo de estilos que se les entrega hace uso de tres imágenes (que se
encuentran en la carpeta clase_1 del cd, con nombres: img01.gif, img02.gif y img03.gif).
Estas debemos copiarlas dentro de la carpeta web/images .
El parámetro layout indica que archivo representa el layout y el mismo se debe
encontrar en la carpeta apps/frontend/templates con la extensión PHP:

Ahora modificaremos el layout para incluir un header, un footer, y un menú

estructurados de la siguiente forma:
Header
M
E
Contenido
N
U
Footer

Para esto, haremos uso de “Partials”, una herramienta con la que cuenta Symfony y con
la cual podemos dividir nuestra vista en diferentes archivos de manera de poder
“modularizar” regiones de nuestra vista, haciendo estas regiones reusables y mas fáciles
de mantener. El nombre de los archivos “Partials” deben comenzar con un guión bajo (_).
Así, por ejemplo, vamos a crear los archivos: _header.php, _footer.php y _menu.php
dentro del directorio apps/frontend/templates:

Modificamos el archivo apps/frontend/templates/_header.php:

<div id="header">
<h1> Taller de Symfony </h1>
<h2> Este es el header de nuestro blog </h2>
</div>

Modificamos el archivo apps/frontend/templates/_footer.php:

<div id="footer">
<h1> Taller de Symfony </h1>
<h2> Este es el footer de nuestro blog </h2>
</div>

Modificamos el archivo apps/frontend/templates/_menu.php:

<?php use_helper('I18N'); ?>
<div id="menu">
<ul>
<li>
<?php echo link_to(__('Inicio'),'default/index');?>
</li>
</ul>
</div>
en este ultimo ejemplo, se utiliza un helper para escribir el link a una acción de nuestra
aplicación (en la próxima clase se vera mas sobre helpers).
Por ultimo, modificamos el archivo apps/frontend/templates/layout.php para
incluir los tres partials y dar el formato esperado a nuestra pagina, para ello cambiamos el
body de la pagina por el siguiente código:
 <?php include_partial('global/header');?>

<?php include_partial('global/menu');?>

<div id="content">
<?php echo $sf_data->getRaw('sf_content') ?>
</div>

<?php include_partial('global/footer');?>

Las funciones include_partial indican que se debe incluir un archivo partial (la
palabra clave global indican que los partials están en la carpeta templates de la
aplicación.
El llamado $sf_data->getRaw('sf_content') debe incluirse siempre ya que lo que
indica es que se debe imprimir el resultado de la acción que se esta llamando.
Ahora indicaremos cual es nuestro modulo y acción por defecto si no se indica otra,
para ello descomentaremos las siguientes lineas del archivo
apps/frontend/config/settings.yml:
all:
.actions:
default_module: default
default_action: index
#
# error_404_module: default
# error_404_action: error404
#
# login_module: default
# login_action: login
#
# secure_module: default
# secure_action: secure
con las demás lineas iremos trabajando en las próximas clases.
Luego, iremos al archivo
apps/frontend/modules/default/actions/action.class.php que contiene la lógica de las
diferentes acciones del modulo default y modificaremos la acción index de la siguiente
manera:
public function executeIndex()
{
$this->mensaje="Bievenidos al Blog del taller de Symfony";
return sfView::SUCCESS; //Valor por defecto.
}

En esta acción la variable $mensaje es salvada de manera de poder ser accesible desde
el template de la acción.
Nota: Recordar que todas las acciones en Symfony comienzan con la palabra “execute”

Por ultimo, modificaremos el template de la acción index de manera de mostrar el

mensaje que seteamos en la misma. Para ello modificamos el archivo
apps/frontend/modules/default/templates/indexSuccess.php:
<?php echo $mensaje; ?>

Nota: Recordar que los templates de las acciones se llaman como la acción, por ejemplo
index, seguido del resultado de la acción, por ejemplo Success. Por ejemplo, si la acción
retorna sfView::ERROR deberíamos tener un template que se llame indexError.php