Para probar esta nueva versión de forma rápida, basta con bajarnos el archivo comprimido y descomprimirlo en el directorio web de nuestro servidor Apache (redordad que esta no es una forma segura de desplegar una aplicación en Apache) y si cumplimos todos los requisitos se nos mostrará una bonita página de bienvenida accediendo a: http://localhost/Symfony/web/app_dev.php/:

En esta nueva versión, tenemos una demo básica “Hola Mundo”:

y un configurador gráfico de la base de datos:

Si queremos iniciarnos con este framework, lo más fácil es echar una ojeada al Quick Tour (aquí lo tenéis en castellano, cortesía de Francisco Belmonte Ruiz), que comienza con la descarga del Sandbox, un pequeño proyecto con el típico “Hola Mundo”.

Para ponernos a trabajar es necesario tener una versión de PHP superior a la 5.3.2 (en mi caso he instalado la última versión de WampServer2). Si trabajáis en Windows, recordad poner la ruta al ejecutable de PHP en el Path para poder ejecutar los comandos desde la consola. Y para ser más productivos, seguiremos utilizando NetBeans como IDE de desarrollo. De momento Netbeans no trae incorporado el soporte a Symfony2 como sí hacía con la versión anterior, pero no notaremos mucha diferencia salvo que tendremos que salir del IDE para ejecutar los comandos por consola, tan sólo tenemos que crear un nuevo proyecto desde el código fuente existente del Sandbox y ya podremos ponernos a trabajar.

Para acostumbrarnos a las buenas prácticas desde un principio, es aconsejable que nos familiaricemos con dos herramientas vitales para el desarrollo: Git (echa un vistazo a esta documentación) y PHPUnit (que además podremos integrarlo en Netbeans). Si ya venías utilizando Subversion para el versionado de código y Lime para la realización de las pruebas automáticas, el cambio no te supondrá demasiado esfuerzo y si nunca habías utilizado herramientas de este estilo, ¿a qué estabas esperando?

Ya tenemos nuestro entorno preparado para ser lo más productivos posibles desde el primer día, así que lo mejor será que empecemos a estudiar algunos de los conceptos clave de nuestro nuevo framework. Desde mi punto de vista, lo más destacable de Symfony2 es su nueva arquitectura con la organización en Bundles (echa un vistazo a esta página) y el contenedor de inyección de dependencias (DIC, aquí puedes introducirte al este concepto). Si dominamos estos dos conceptos, el desarrollo con Symfony2 se nos hará mucho más sencillo.

Y para el final dejo otras dos de las características que van a dar un salto de calidad (tanto en rendimiento como en productividad) a nuestros desarrollos: Twig y Doctrine2.

Twig es un motor de plantillas que es el que se va a utilizar por defecto en Symfony2, aunque siempre tendremos la posibilidad de seguir utilizando nuestras plantillas en PHP. Si vamos a trabajar con Netbeans sería interesante que asocies la extensión .twig con el tipo de archivos HTML para que te funcione el resaltador de sintaxis.

Por su parte, Doctrine2 es la nueva versión del ORM que ya se convirtió en el preferido por los desarrolladores de Symfony en su versión anterior.

Esto es todo, de aquí al 5 de Marzo hay muchas cosas que aprender, ¿no te parece?

Sin embargo, esto no impide que el aprendizaje del framework por cuenta propia sea una tarea que requiere mucho esfuerzo y dedicación. Por ello, poder realizar un curso en el que te ofrezcan una documentación menos técnica y más pedagógica con un tutor que te oriente y te resuelva las dudas es una gran oportunidad para muchos, y es lo que nos ofrece la plataforma Aula Mentor con el curso de reciente creación “Diseño de aplicaciones web con Symfony”.

¿Qué es Aula Mentor?

Aula Mentor es un sistema de formación abierta, libre y a través de Internet promovido por el Ministerio de Educación. Aula Mentor se caracteriza por su flexibilidad, ya que los cursos son completamente online y podemos marcarnos nuestro propio ritmo (podemos terminar en 2 meses o en 10, según el tiempo que queramos dedicar).

Cada 2 meses (aproximadamente) tendremos una convocatoria para realizar el examen de certificación, que será presencial, y que podremos realizar en cualquiera de las aulas dispuestas para ello distribuidas a lo largo de toda la geografía española y de latinoamérica. También podremos acudir a estas aulas en cualquier otro momento para utilizar el material y los equipos que hacen falta para el curso si así lo requerimos.

Para formalizar la matrícula únicamente tenemos que abonar el importe de los dos primeros meses (son 22€ por mes) y acudir a alguna de las aulas para rellenar los impresos correspondientes y recibir las claves para acceder a la plataforma. Si transcurridos los 2 meses no se ha completado el curso y se quiere renovar, sólo hay que hacer un nuevo ingreso (esta vez sólo de un mes) y solicitar la renovación.

¿Qué aprenderé en el curso?

Para conseguir los objetivos propuestos se ha optado por un planteamiento completamente práctico en el que se está “picando código” funcional desde el principio del curso, que estará compuesto de 10 unidades.

En la unidad 1 se da una visión general a todo lo que conlleva realizar una aplicación web y los beneficios de una buena arquitectura y unas buenas prácticas, además de enumerar las ventajas que nos reportará Symfony para este propósito.

En la unidad 2, sin utilizar symfony para nada, se desarrollará una sencilla aplicación web en PHP. El objetivo de esta unidad es mostrar como se puede organizar el código para que siga los planteamientos del patrón de diseño Modelo – Vista – Controlador (MVC), gracias al cual separamos completamente la lógica de negocio de la presentación de la información. Es importante comprender los fundamentos de esta organización ya que symfony, como se verá más adelante, la utiliza en su implementación. Además en esta unidad se introducen los conceptos de controlador frontal, acción, plantilla y layout, ampliamente usados en el resto del curso.

En la unidad 3 se hará una presentación panorámica de symfony, exponiendo los conceptos fundamentales. En esta unidad se volverá a escribir, esta vez utilizando symfony, la aplicación de la unidad 2. Dicho ejercicio ayudará a realizar la presentación del framework a la vez que servirá como referencia de los conceptos de base.

En la unidad 4 se planteará el análisis de una aplicación, que aún siendo concebida con criterios pedagógicos, es suficientemente amplia como para ser considerada una aplicación profesional. Se trata de un gestor documental y su desarrollo nos servirá como vehículo para penetrar al interior de symfony durante el resto del curso.

En las siguientes unidades se construyen progresivamente las distintas funcionalidades de la aplicación analizada en la unidad 4. Cada unidad incide sobre algún aspecto fundamental de symfony.

En la unidad 5 se profundizará en el concepto de modelo y de capa de abstracción de acceso a datos (ORM4). Aquí se tratan con bastante profundidad los aspectos relacionados con el acceso a bases datos.

En la unidad 6 se describe el mecanismo para el manejo de la sesión de usuario en el servidor que proporciona symfony, mediante el cual se trata la seguridad a los niveles de autentificación y autorización. En esta unidad se construye un procedimiento para que los usuarios inicien sesión en la aplicación que puede ser reutilizado en cualquier otra aplicación web construida con symfony.

En la unidad 7 se profundiza en la arquitectura MVC de symfony. Esta unidad ofrece un buen número de detalles, tanto del controlador como de la vista, mediante los cuales se enriquecen las aplicaciones web desarrolladas con symfony.

En la unidad 8 se presenta el fabuloso framework de formularios de symfony. Este sistema, por sí solo, constituye una poderosa herramienta para la definición de formularios y la validación de los datos que son enviados en las peticiones HTTP al servidor web. También se estudian los formularios que son generados automáticamente por symfony para la gestión de cada una de las tablas de la base de datos.

En la unidad 9 se construye completamente y de manera automática la parte de administración de la aplicación analizada en el tema 4. Además se construye un plugin con el fin de reutilizar código.

Por último, la unidad 10 presenta los conceptos de internacionalización y enrutamiento y la manera en que symfony los trata.

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

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