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_sandboxSin 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-pearEn 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.compear install symfony/symfonyEste 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/bloghttp://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 blogDocumentRoot "c:/wamp/www/prueba/web"DirectoryIndex index.phpAlias /sf "c:/wamp/php/pear/data/symfony/web/sf"<Directory "c:/wamp/www/prueba/web">

AllowOverride AllOrder deny,allowAllow 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://bloges 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 localhost127.0.0.1 blog

2.2. Iniciando la AplicaciónSymfony 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 blogLuego, 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

Archivos de configuración para todo el proyecto

Directorio que sera para parte web de nuestras aplicaciones: index.php, JS, CSS, imagenes, etc.

Acciones del modulo default

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

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

Clases comunes a todo el proyecto (inclusive modelo) 

Cache de archivos

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 DatosUna 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/blogLos 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 = mysqlpropel.database.createUrl = mysql://root:pass@localhostpropel.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:

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:

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”.

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.phpPara acceder a la aplicación frontend en el entorno de desarrollo, se utiliza la URL:

http://blog/frontend_dev.phpCuando 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-cacheo, la versión resumida

symfony cc

2.5. Primeros PasosPor 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

MENU

Contenido

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