Mi intención era hacer un pequeño resumen de cada una de las charlas, pero siguiendo la máxima del framework de no reinventar la rueda os invito a que leáis la crónica de mi cada vez más admirado Javier Eguiluz (su charla sobre Symfony2 fue magistral).

En cada una de las charlas se mostraron unas diapositivas y se grabó el audio, por lo que pronto podremos ver colgadas en internet todas las charlas, una vez más en el blog de Symfony.es.

Me gustaría agradecer el esfuerzo realizado por David Castelló para organizar estas jornadas, creo que puede sentirse muy orgulloso del resultado.

Y ya un poco al margen de las jornadas en sí mismas, pues decir que me lo he pasado genial, 5 días en Castellón con sol y playa.

Para acabar, dejo los vídeos de cada una de las charlas para que las podáis ver con detenimiento:

• Introducción a Symfony
• El ORM Doctrine
• Domesticando las vistas
• Admin generator
• Arquitectura y diseño de un entorno de desarrollo
• Caso práctico I: voota.es
• Caso práctico II: Symfony en CETA-CIEMAT
• Domesticando los formularios
• Plugins, no reinventes la rueda
• MongoDB y symfony
• Symfony, cloud computing y web escalables
• Symfony2

Lo único que tenemos que hacer es crear un directorio que se llame sfXSLTransformerPlugin y crear allí la estructura de directorios que necesitamos, es decir, la carpeta config con el archivo settings.yml, la carpeta lib/helper donde incluiremos nuestro helper XSLHelper.php, la carpeta modules donde estará nuestro módulo de prueba y la carpeta web/xsl donde se encontrará nuestra hoja de estilos XSL.

El archivo settings.yml contendrá el siguiente código:

[css]
all:
.settings:
standard_helpers: [XSL]
xsl_doc: sfXSLTransformerPlugin/xsl/collection.xsl
[/css]

El plugin quedaría así. Para instalarlo en cualquier proyecto, sólo tenemos que descargarlo y descomprimirlo en el directorio plugins. Después, en el ProjectConfiguration.class.php habilitamos el plugin:

[php]
$this->enablePlugins(‘sfDoctrinePlugin’, ‘sfXSLTransformerPlugin’);
[/php]

Con esto ya podríamos usar el plugin. Si queremos verlo en funcionamiento en el módulo de prueba, sólo tenemos que habilitar este módulo en el settings.yml:

[css]
all:
.settings:
enabled_modules: [prueba]
[/css]

Limpiamos la caché y ejecutamos la tarea plugin:publish-assets (para que los archivos de la carpeta web del plugin se publiquen en la carpeta web del proyecto) y listo.

Evidentemente, la hoja de estilos XSL que viene por defecto en el plugin no nos sirve de mucho, ya que en nuestro proyecto querremos utilizar nuestra propia hoja de estilos. Podríamos editar la hoja de estilos del plugin, pero no es una buena práctica editar los archivos de un plugin, ya que si lo actualizásemos se sobreescribirían nuestros cambios. Así que lo que tenemos que hacer es crear nuestra propia hoja de estilos en el directorio web/xsl de nuestro proyecto y después editar el archivo settings.yml (el de nuestra aplicación, no el del plugin):

[css]
all:
.settings:
xsl_doc: xsl/mi_hoja_de_estilos.xsl
[/css]

Una vez que tenemos realizado nuestro plugin, podemos subirlo a un repositorio subversion para poder llevar un control de versiones y poder actualizarlo estemos donde estemos. Por ejemplo, en Google Code se puede crear de forma gratuita un repositorio de subversion. Si tenemos instalado Tortoise en nuestro equipo, hacer un checkout del proyecto, añadir archivos al repositorio y realizar un commit es bastante intuitivo (para subir cambios al repositorio tenemos que tener permisos, por lo que se nos pedirá una contraseña que podremos encontrar en la página de configuración del proyecto de Google Code). Nuestro plugin está subido en http://osukaru-plugins.googlecode.com/svn/trunk/sfXSLTransformerPlugin.

Si quisieramos distribuir nuestro plugin desde el sitio web del proyecto Symfony tendríamos un poco más de trabajo, ya que deberíamos crearlo como un paquete PEAR, escribir el archico package.xml, el archivo README (con sintáxis Markdown) y el archivo LICENSE y después crearnos una cuenta de usuario en Symfony y crear allí nuestro plugin.

Lo que podemos hacer es que las vistas generen XML y después en el layout transformamos este XML en XHTML mediante nuestra hoja de estilos XSL.

Vamos a utilizar el mismo ejemplo que en el post anterior. Lo primero que haremos es crear una carpeta xsl dentro del directorio web. Ahora metemos ahí los archivos de ejemplo (collection.xsl y collection.xml). En el layout, en el lugar que queramos (total, es sólo para probar) incrustamos el código de ejemplo:
[php]
$xslDoc = new DOMDocument();
$xslDoc->load(“xsl/collection.xsl”);

$xmlDoc = new DOMDocument();
$xmlDoc->load(“xsl/collection.xml”);

$proc = new XSLTProcessor();
$proc->importStylesheet($xslDoc);
echo $proc->transformToXML($xmlDoc);
?>
[/php]
Si ahora ejecutamos nuestro proyecto veremos que la transformación se realiza correctamente. Pero esto no es lo que queríamos, ya que estamos cargando el XML de ejemplo directamente desde un archivo y lo que queremos es cogerlo de una vista. Bien, creemos entonces un nuevo módulo y en el indexSuccess.php metamos el XML de ejemplo. Ahora sólo tenemos que cambiar el código de ejemplo del layout y utilizar la función loadXML y la variable $sf_content:
[php]
$xslDoc = new DOMDocument();
$xslDoc->load(“xsl/collection.xsl”);

$xmlDoc = new DOMDocument();
$xmlDoc->loadXML($sf_content);

$proc = new XSLTProcessor();
$proc->importStylesheet($xslDoc);
echo $proc->transformToXML($xmlDoc);
?>
[/php]
Con esto ya hemos conseguido lo que queríamos, aunque es un poco engorroso poner todo ese trozo de código en el layout, así que podemos crear un helper que nos ayude a simplificar la tarea. Para ello, dentro de la carpeta lib (por ejemplo, dentro de la aplicación frontend) creamos un nuevo directorio helper y dentro de él nuestro helper XSLHelper.php que contendrá el siguiente código:
[php]
function XSLTransform($xmlString)
{
$xslDoc = new DOMDocument();
$xslDoc->load(“xsl/collection.xsl”);

$xmlDoc = new DOMDocument();
$xmlDoc->loadXML($xmlString);

$proc = new XSLTProcessor();
$proc->importStylesheet($xslDoc);

return $proc->transformToXML($xmlDoc);
}
?>
[/php]
Ahora en nuestro layout sólo tenemos que poner el siguiente código:
[php]


?>
[/php]
Y si queremos simplificar aún más, podemos hacer que nuestro nuevo helper se cargue por defecto y así no tener que incluirlo manualmente. Para ello, en el archivo settings.yml dentro de la carpeta config de nuestra aplicación frontend lo incluimos en una lista de helpers por defecto:
[css]
all:
.settings:
standard_helpers: [XSL]
[/css]
Así, en nuestro layout ya sólo tendremos que escribir:
[php]

?>
[/php]
Bien, ahora sólo nos quedaría solucionar un pequeño problema de la forma más elegante que se nos ocurra, y es que la hoja de estilos XSL con la que realizaremos las transformaciones la hemos puesto directamente en la función de nuestro helper. Podríamos incluir un nuevo parámetro en nuestra función para especificar la hoja de estilos, pero esto no sería muy ágil si hacemos muchas llamadas al helper y en un futuro cambiamos de nombre o de ruta la hoja de estilos, así que lo mejor sería que pudiésemos obtener este dato de un archivo de configuración, por ejemplo del settings.yml. Lo que tenemos que hacer es definir una constante en ese archivo:
[css]
all:
xsl_doc: xsl/collection.xsl
[/css]
Y después utilizar la clase sfConfig de Symfony para recuperar el valor en nuestro helper:
[php]
function XSLTransform($xmlString)
{
$xslDoc = new DOMDocument();
$xslDoc->load(sfConfig::get(‘sf_xsl_doc’));

$xmlDoc = new DOMDocument();
$xmlDoc->loadXML($xmlString);

$proc = new XSLTProcessor();
$proc->importStylesheet($xslDoc);

return $proc->transformToXML($xmlDoc);
}
?>
[/php]

Relaciones 1:1 transparentes en Doctrine

• Lo primero que tenemos que hacer es instalar el plugin en nuestro proyecto. Podemos ejecutar la tarea de instalación:
  symfony plugin:install sfDoctrineGuardPlugin
  para lo que tenemos que tener instalado PEAR, pero como últimamente PEAR y yo no nos hablamos, pues vamos a descargarnos el paquete y lo descomprimimos en la carpeta plugins de nuestro proyecto (lo renombramos quitándole la numeración de la versión: sfDoctrineGuarPlugin).
• Ahora activamos el plugin en el archivo config/ProjectConfiguration.class.php de nuestro proyecto:
  [php]
  class ProjectConfiguration extends sfProjectConfiguration
  {
  public function setup()
  {
  $this->enablePlugins(array(
  ‘sfDoctrinePlugin’,
  ‘sfDoctrineGuardPlugin’,
  ‘…’
  ));
  }
  }
  [/php]
• Reconstruimos el modelo y actualizamos la base de datos:
  symfony doctrine:build --all

Ahora ya tenemos el plugin instalado. Lo siguiente que vamos a hacer es cargar los datos de prueba (que consisten en un usuario administrador):

• Copiamos el fichero plugins/sfDoctrineGuardPlugin/data/fixtures/fixtures.yml.sample en data/fixtures/sfGuard.yml y cargamos los datos:
  symfony doctrine:data-load

Bien, ya sólo nos queda habilitar los módulos que vayamos a utilizar y configurarlos correctamente.

• En el frontend, abrimos el archivo settings.yml y añadimos el módulo sfGuardAuth y lo configuramos:
  [css]
  all:
  .settings:
  enabled_modules: [default, sfGuardAuth]
  login_module: sfGuardAuth
  login_action: signin
  secure_module: sfGuardAuth
  secure_action: secure
  [/css]
• Editamos la clase myUser.class.php para cambiar la clase de la que hereda:
  [php]
  class myUser extends sfGuardSecurityUser
  {
  }
  [/php]
• Opcionalmente podemos cambiar el archivo routing.yml añadiendo la siguiente configuración al comienzo del archivo:
  [css]
  sf_guard_signin:
  url: /login
  param: { module: sfGuardAuth, action: signin }

  sf_guard_signout:
  url: /logout
  param: { module: sfGuardAuth, action: signout }

  sf_guard_password:
  url: /request_password
  param: { module: sfGuardAuth, action: password }
  [/css]

• En el archivo security.yml podemos asegurar los módulos que queramos o la aplicación completa:
  [css]
  default:
  is_secure: true
  [/css]

Y ya está!!! Ahora si accedemos a cualquier módulo de la aplicación y no estamos autentificados nos pedirá el usuario y el password:

Para el backend podemos habilitar los módulos sfGuardGroup, sfGuardPermission, sfGuardUser que nos permitirán manejar usuarios, grupos y permisos.

[shell]pear uninstall symfony/symfony[/shell]

y posteriormente instalar la versión 1.4:

[shell]pear install symfony/symfony-1.4.0[/shell]

Como elegimos Netbeans 6.8 con soporte para Symfony como IDE para desarrollar nuestros proyectos no tenemos nada más que hacer, ya que ahora Netbeans utilizará la nueva instalación de Symfony a la hora de crear un nuevo proyecto. Entre otras cosas, veremos que al crear un nuevo proyecto ya no tenemos que habilitar el plugin para usar Doctrine, ya que éste es el que viene activado por defecto.

Para instalar XDebug debemos ir a a la página oficial, descargar los archivos necesarios y seguir las instrucciones de instalación. En nuestro caso estamos trabajando bajo Windows y con PHP 5.3 , por lo que nos tendremos que descargar la dll correspondiente y colocarla en algún lugar de nuestro disco duro (por ejemplo bajo el directorio ext de la instalación de PHP). Ahora sólo tenemos que editar el archivo php.ini de la instalación de PHP 5.3 y añadir la siguiente línea al final:

zend_extension="(ruta completa a php5.3.0)\ext\php_xdebug-2.0.5-5.3-vc6.dll"

Ahora sólo tenemos que asegurarnos de que la ruta al ejecutable php.exe está incluida en la variable de entorno Path y ya podemos ejecutar la tarea test:coverage.

1. Añadir un host virtual que escuche por un puerto determinado.
2. Añadir un host virtual que tenga un nombre dedicado de dominio.

Para la primera opción simplemente tenemos que añadir las siguientes líneas al archivo httpd.conf:
[xml]
NameVirtualHost 127.0.0.1:8080

Listen 127.0.0.1:8080

<VirtualHost 127.0.0.1:8080>
DocumentRoot “(1)”
DirectoryIndex index.php
<Directory “(1)”>
AllowOverride All
Allow from All
</Directory>

Alias /sf “(2)”
<Directory “(2)”>
AllowOverride All
Allow from All
</Directory>
</VirtualHost>
[/xml]
Donde (1) es la ruta de la carpeta web de nuestro proyecto symfony y (2) es la ruta de la carpeta web/sf en nuestra instalación de symfony.

Con esto, ya podríamos acceder a nuestro proyecto en nuestro navegador mediante http://localhost:8080/index.php.

Sin embargo, si somos administradores del equipo, es mucho más interesante acceder mediante un nombre de dominio dedicado. Para ello, basta eliminar la declaración Listen y añadir la declaración ServerName al VirtualHost:
[xml]
NameVirtualHost 127.0.0.1:80

<VirtualHost 127.0.0.1:80>
ServerName nombreproyecto.localhost
DocumentRoot “(1)”
DirectoryIndex index.php
<Directory “(1)”>
AllowOverride All
Allow from All
</Directory>

Alias /sf “(2)”
<Directory “(2)”>
AllowOverride All
Allow from All
</Directory>
</VirtualHost>
[/xml]
Después tenemos que acceder al fichero hosts que se encuentra en “C:\WINDOWS\system32\drivers\etc\” y añadir la línea:
[xml]
127.0.0.1 nombreproyecto.localhost
[/xml]
(¡OJO! Si tenemos Windows Vista o Windows 7, para editar el archivo hosts tendremos que ejecutar nuestro editor de textos como administradores).

Ahora podemos acceder a nuestro proyecto mediante http://nombreproyecto.localhost/index.php.

Si además hemos activado el módulo mod_rewrite en nuestro servidor Apache (descomentando la línea correspondiente en el archivo httpd.conf), entonces únicamente tendremos que teclear http://nombreproyecto.localhost.

Una vez que hemos realizado la configuración en Apache, sólo nos queda ir a las propiedades de nuestro proyecto en Netbeans y añadir el Project URL dentro de la opción Run Configuration para que cuando ejecutemos el proyecto (F6) se abra el navegador con la URL que acabamos de configurar.

Si hemos hecho realizado la instalación de Symfony mediante PEAR, al ir a Options>Tools>PHP>Symfony veremos que  el recuadro “Symfony script” viene informado con la ruta \bin\php\php5.3.0\symfony. Ahora ya podemos crear un nuevo proyecto PHP en donde elegirimos a Symfony como framework.

[shell]pear config-set http_proxy http://user:pass@domain:port[/shell]