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

Vamos a analizar primero el nuevo producto de Apple. Cuando adquieres un nuevo producto lo primero que tienes que tener claro es saber qué estás comprando. Con el iPad no queda claro, hace muchas cosas, algunas de forma excelente, pero si yo tuviese que elegir una de sus características en las que probablemente sea (o tenga el potencial para serlo) el líder del mercado indiscutiblemente creo que diría que es un navegador web portátil. No hay aparato en el mundo que me permita navegar por internet de una forma tan rápida, cómoda y eficaz. Una vez que sabemos lo que hemos comprado, vemos que además podemos contar con todas las aplicaciones de la AppStore, que podremos ver películas o escuchar música, leer libros electrónicos, etc. El aparato es simplemente espectacular, al igual que otros productos de Apple, pero hay que recordar que sin una función principal que consiga que lo use diariamente no sería para tanto (si el iPhone no fuese un teléfono o el iTouch no fuese un reproductor de música, dudo mucho que hubiesen vendido nada). Entonces, si aceptamos que es un navegador web portátil, ¿por qué no soporta Flash?

Sin duda, esta característica hace que la experiencia web del usuario se vea limitada (muy limitada). Si he pagado en torno a 500 euros por un aparato que me va a permitir navegar por internet sin tener que levantarme de la cama, que no pueda acceder a todos los contenidos flash realmente supone un fastidio. Flash hace que la experiencia del usuario web sea enriquecida de una manera espectacular. Flash se utiliza en muchas páginas para reproducir vídeo porque hasta hace bien poco era la manera más óptima de hacerlo, pero Flash no es un reproductor multimedia, es mucho más que eso. Aún así, aunque ahora se pueda reproducir vídeo de forma más eficiente, muchas páginas siguen usando Flash y no tienen por qué plantearse cambiar (¿es Apple quien se tiene que adaptar al mundo o es el mundo el que se tiene que adaptar a Apple?). Pero además de los vídeos (que no es poco), ¿qué más nos perdemos? Hay muchas más cosas que aunque se podrían hacer de otra forma, están hechas en Flash y muchas otras que si no existiese Flash, simplemente no existirían. Voy a poner como ejemplos cosas que yo utilizo, pero hay tantas más…

En primer lugar, uso Google Analitycs para consultar las estadísticas de mi blog, y los gráficos están hechos en Flash. Como en mi trabajo soy un profesional de Oracle, necesito consultar el Metalink, que está hecho en Flex (Flash). Ahora estoy organizando mi boda, ya que me caso en Septiembre, y uso una web (Wedtool) que me permite organizar el evento y crear la página web de la boda: está hecha en Flex (Flash). Mientras escribo esto, estoy escuchando música con mi cuenta de GrooveShark (más Flash). Tengo mi cuenta de Facebook y a veces mis amigos juegan a algún jueguecito que está hecho en Flash y consiguen que me termine enganchando (aunque sé que hay juegos mejores en otras tecnologías, pero el hecho es ese). FarmVille tiene más de 80 millones de usuarios, que se dice pronto, y aunque un juego de tanto éxito pueda plantearse sacar versiones que se adpaten al iPad, no todos los jueguecitos podrán o querrán hacerlo. Suelo leer la prensa deportiva, y tanto en Marca como en Mundo Deportivo los vídeos aún están en Flash, la sección de Última Hora de Marca que se actualiza sóla en tiempo real está en Flash y el nuevo juego de Futbolín Virtual de Marca está hecho en Flash. Si voy a apostar en MiApuesta o Bet&Win, la mayoría de contenidos (sobretodo los que son LIVE) están en Flash. A veces leo revistas o prensa en YouKioske, pero está en Flash. Si voy a Google Maps y quiero situarme en algún sitio con su espectacular Street View, me vuelvo a topar con Flash. Y además, hay empresas muy serias, como Codeoscopic, que hacen un trabajo fantástico con esta tecnología (visiten su web sólo para comprobar que la experiencia de usuario no tiene nada que ver con la web convencional). Y por no mencionar la cantidad de publicidad que hay en banners hechos en Flash, que aunque al usuario le parezcan molestos no creo que se lo parezca a los patrocinadores. O Intros muy chulas en páginas web. Hay muchas más empresas y muchas más aplicaciones que podría mencionar, pero todo lo que aquí he relatado lo uso de manera habitual (diariamente la mayoría), ¿de verdad me puede compensar comprar un iPad? ¿Y a vosotros, no usáis Flash para nada?

La gente que intenta desprestigiar Flash nos presentan a HTML 5, pero ¿qué es HTML 5? ¿viene a sustituir a Flash? ¿viene siquiera a competir con él? Yo veo HTML 5 y me parece genial, es una evolución de HTML 4 que consigue que una web tenga muchísimo más sentido semántico. Me proporciona nuevas etiquetas para contenidos concretos (cabecera, pie, contenido multimedia, etc.) y me proporciona una etiqueta Canvas donde se podrá dibujar. Sin duda es una buena evolución, por ejemplo facilitará la labor de los buscadores por lo que los usuarios podrán buscar contenido de una forma mucho más restrictiva y eficiente. También nos va a permitir reproducir vídeo (y otros contenidos multimedia) de una forma más convincente que Flash. Pero que sustituya a Flash en este aspecto no significa que venga a destronar a Flash, que junto con CSS 3 y javascript (AJAX) podamos hacer muchas cosas (sólo hay que ver las posibilidades que nos cuenta Apple), algunas mejor incluso que Flash, no significa nada más que eso, son tecnologías para crear RIAs (Rich Internet Applications) y hay programadores tanto en un bando como en otro (¿acaso no se programa tanto en Java como en .NET o PHP?). Y Steve Jobs se equivoca mucho si piensa que Flash va a desaparecer. Sólo miren la cantidad de páginas que ni siquiera siguen el estándar HTML 4 o XHTML (vale, son una chapuza de páginas, pero las hay) y se darán cuenta de que el mundo no cambia ante nada, y lo mismo que los programadores de webs intentamos que nuestros contenidos se vean igual en todas las plataformas posibles (está claro que intentaremos que también en el iPad) los fabricantes (y los desarrolladores de los navegadores web) tienen que conseguir que los usuarios puedan ver la mayor cantidad de contenidos, porque si no, no están ofreciendo un buen producto.

¿Y por qué Apple no permite habilitar el uso de Flash como opción de usuario advirtiendo de los riesgos? Admitir que el uso de Flash puede colgar el iPad es admitir las limitaciones tecnológicas del producto que estás vendiendo (no conozco muchos aparatos con 1 Ghz de RAM que se cuelguen con Flash), decir que con Flash se acaba antes la batería es una obviedad (¿reproduciendo películas en HD no se acaba antes la batería que viendo webs de texto plano?) y decir que hay agujeros de seguridad es inexacto, todas las tecnologías tienen o pueden tener agujeros de seguridad, lo que Apple quiere decir es que no se puede hacer responsable de esos agujeros de seguridad en el momento que existan (Adobe corrije los posibles fallos de seguridad que van existiendo muy rápidamente). No hay duda de que los verdaderos motivos de Apple son económicos, no le interesa ni le apetece vender un aparato fabricado por ellos para ganar dinero con sus aplicaciones para que vengan otros a reventarle el negocio con otras aplicaciones. A mí me parece que viéndolo desde ese ángulo, puede ser una decisión empresarial aceptable, pero el que paga las consecuencias es el usuario, o sea, nosotros, y a la larga, cuando el usuario esté descontento, lo empezarán a pagarlo ellos también.

Consecuencia: Yo no me voy a comprar un iPad, pero tomar la decisión de comprarlo o no comprarlo no es motivo para desacreditar productos y especificaciones tan buenos como el iPad, Flash y HTML 5.

La virtualización en VirtualBox es realmente sencilla y muy potente. La instalación de VirtualBox no tiene ningún problema, simplemente lo descargamos de la página web y lo instalamos siguiendo los pasos del asistente.

Una vez tenemos VirtualBox instalado en nuestro sistema, jugar con él es bastante intuitivo. Para nuestro propósito únicamente tenemos que crear una nueva máquina virtual (elegimos el S.O. adecuado, creamos el disco duro, etc.), montar la ISO de Ubuntu en la unidad de CD/DVD y arrancar la máquina. Una vez hecho esto, seguimos los pasos de instalación de Ubuntu. Después instalaremos Guest Additions que es un paquete especial de software que forma parte de VirtualBox y que debe instalarse en cada una de las máquinas virtuales para mejorar el rendimiento y añadir nuevas funciones (integración del cursor del ratón, mejor soporte de vídeo, carpetas compartidas, etc.). Para ello sólo tenemos que descargar y montar la imagen VBoxGuestAdditions.iso (esto lo automatiza VirtualBox desde el menú Dispositivos–>Instalar Guest Additions…) y ejecutar el autorun.sh (si es que no se inicia automáticamente).

Una vez que ya tenemos nuestra máquina virtual lista para darle el uso que deseemos podemos hacer una cosa más: clonar el disco duro virtual. De esta forma podremos crear una nueva máquina virtual sin tener que volver a instalar el sistema operativo, las guest additions y los programas básicos que siempre instalamos.

El siguiente paso es poder acceder a los ficheros y directorios del sistema anfitrión. Para ello (y con la máquina virtual apagada) sólo tenemos que ir al apartado de “Carpetas compartidas” de la configuración de VirtualBox y crear las carpetas compartidas que deseemos, con la opción de hacerlas permanentes y también de sólo lectura.

Una vez hecho esto, tenemos que montar la carpeta compartida dentro de nuestro sistema de Ubuntu. Supongamos que le hemos dado el nombre vBox a la carpeta compartida y que vamos a montar dicha carpeta en /media/compartida. Las instrucciones para realizar esto son:

[shell]
sudo mkdir /media/compartida
sudo mount -t vboxsf VBox /media/compartida
[/shell]

Y si queremos tener montado este directorio cada vez que iniciemos nuestra máquina virtual, tendremos que editar el archivo fstab:

[shell]
sudo vim /etc/fstab
[/shell]

Y añadirle una línea:

[shell]
VBox /media/compartida vboxsf rw,gid=1000,uid=1000,auto 0 0
[/shell]

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]

Y ahora lo que me pregunto es lo siguiente: ¿será sencillo realizar eso mismo en PHP? Bueno, la respuesta es que sí (no entro a valorar si es la forma más correcta de desarrollar una aplicación web). Lo único que tenemos que hacer es habilitar la extensión php_xsl (si trabajamos en Windows basta con descomentar la línea extension=php_xsl.dll en nuestro php.ini).

Podemos probar con este ejemplo y con sus respctivos archivos xml y xsl.

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.