Con un poco de retraso publicamos el resumen de la última reunión del año 2011 del grupo de desarrolladores de Symfony:

1. Permitir la carga asíncrona de contenidos en el cliente mediante la etiqueta {% render %} de Twig (ver PR #2865) se ha propuesto mediante una pull request la posibilidad de añadir soporte para cargar trozos de página de forma asíncrona mediante JavaScript. Se decide que la idea es buena, pero la implementación no. El problema es que se está reinventando la rueda, ya que existe una tecnología buena y probada que hace esto muy bien: hinclude.js. Se trata del equivalente de ESI para la parte del cliente. Se decide probar la integración de hinclude.js dentro del core de Symfony2. Si el resultado es bueno y no ensucia demasiado su código o las plantillas, se incorporará. Ver PR #2903 para conocer los detalles de la integración.

2. Añadir los métodos Kernel::terminate() y HttpKernel::terminate() para ejecutar código después de enviar la respuesta al usuario (ver PR #2791) la propuesta se acepta sin mucha discusión, ya que se considera algo realmente útil. No es algo que pueda sustituir a Gearman o RabbitMQ, pero puede venir muy bien en acciones puntuales con un procesamiento pesado o complejo y para la que no merece la pena o no se pueden instalar las herramientas anteriores.

3. Renombrado el método equals() a isSameUser() en la interfaz UserInterface (ver PR #2669) durante la reunión se volvió a discutir una vez más sobre el famoso método equals() de la interfaz UserInterface. El problema es que este nombre entra en conflicto con otras librerías (sobre todo con Propel) y según algunos no refleja realmente su propósito: este método no sólo comprueba que el usuario que te pasan sea el mismo, sino que también hay que comprobar si sigue siendo válido desde el punto de vista de la autenticación. Se proponen como alternativas:

• isSameUser()
• equalsUser()
• isSameAs()
• isSameAsValidAutenticatedUser()
• isStillConsideredAsValidForAuthentication()

Antes de que a alguien se le ocurrieran métodos con nombres todavía más largos, se propone eliminar el método equals() de la interfaz. ¿Por qué tienen los programadores que comprobar si el usuario es el mismo y sigue siendo válido? Que lo haga Symfony2 automáticamente y si quiero hacer cosas avanzadas, ya crearé una clase o implementaré una interfaz especial. Ver PR #2927 para los detalles de la nueva implementación.

Como siempre, también puedes leer los logs completos de la reunión para conocer los detalles discutidos para cada punto del orden del día.

Ayer se celebró una nueva reunión del grupo de desarrolladores de Symfony y estas son las decisiones que se tomaron:

1. Permitir que las configuraciones definidas con TreeBuilder puedan añadir mensajes de documentación (detalles).

Si buscas en el código fuente de tu aplicación Symfony2, encontrarás decenas de archivos llamados Configuration.php. Estos archivos definen las opciones de configuración de diferentes servicios. Antes del lanzamiento de Symfony2 se decidió definir así la configuración porque en teoría serviría para generar automáticamente la documentación sobre las opciones de configuración de Symfony2.

Lo único que se consiguió es complicar la definición de los archivos de configuración a cambio de nada. Ahora se retoma la idea de definir un método llamado setInfo() que permita documentar cada una de las opciones incluidas. Cuando todos los archivos lo implementen, se podrá generar toda la documentación con un solo comando. Muy sencillo y siempre actualizado.

El cambio propuesto se acepta por unanimidad.

2. Coordinar el traspaso del bundle de DoctrineBundle al proyecto Doctrine

En la anterior reunión se decidió que tanto Doctrine como Propel deberían desarrollar y mantener sus bundles. Este cambio no será retrocompatible porque la ruta de muchas clases va a cambiar. Benjamin Eberlei se ofrece a empezar mañana mismo con la transición.

3. Cambiar el nombre del método equals() de UserInterface

Los responsables de Propel piden cambiar el nombre porque les causa problemas de compatibilidad con sus interfaces. Se decide cambiar el nombre del método no para complacer a Propel, sino porque a casi nadie le gusta ese nombre. Se opta por cambiarlo a isSameUser().

4. Mejorar los mensajes flash (detalles)

En la anterior reunión también se habló de este tema y se decidió que no se iba a cambiar nada. Así que esta semana han vuelto a hablar de lo mismo. Actualmente cada mensaje flash se define con una clave y un mensaje. La clave, que debe ser única en la misma petición, se puede elegir libremente. Aún así, la mayoría utilizan valores como “info”, “error”, “warning”, etc.

El problema es que si en una misma petición se generan por ejemplo varios mensajes flash de tipo “info”, en vez de mostrarlos todos, sólo se muestra el último, ya que como todos utilizan la misma clave, se machacan unos a otros. Se propone eliminar la clave y utilizar en su lugar categorías. Así se pueden definir y mostrar varios mensajes diferentes en una misma categoría.

Antes de que se tomara una decisión, varios programadores empiezan a discutir sobre si es mejor o no crear un FlashBag() y sobre si la nueva funcionalidad debe incluirse en el componente HttpFoundation, Session o FrameworkBundle. Fabien y otros programadores importantes abandonan la reunión antes de que se tome una decisión.

Otros

• Fabien vuelve a decir que no cree que la próxima versión 2.1 sea la de soporte largo durante 5 años.
• Fabien también asegura que no hay ninguna fecha prevista de lanzamiento de 2.1, pero que podría ser antes de final de año.
• Lukas Smith también quería hablar sobre integración continua, pero como no da tiempo a discutirlo, lo deja para la lista de correo. Leer mensaje sobre Integración Continua con Symfony2.

Como siempre, también puedes leer los logs completos de la reunión para conocer los detalles discutidos para cada punto del orden del día.

Ayer se celebró una nueva reunión del grupo de desarrolladores de Symfony y estas son las decisiones que se tomaron:

• Mejorar los mensajes flash (detalles): algún desarrollador propone extender los mensajes flash para que incluyan un parámetro que permita indicar la categoría a la que pertenecen (error, información, etc.) Fabien defiende con vehemencia que eso es innecesario,  que el primer parámetro del método setFlash() se puede usar como categoría y que los mensajes flash son sólo para mostrar un mensaje en la próxima petición. Lukas Smith sugiere que “como ahora mismo los mensajes flash no sirven para mucho, mejor eliminarlos”. Después de este brillante comentario, se da por zanjada la discusión y se decide dejar los mensajes flash como están.
• Cómo hacer el soporte de ORM en Symfony 2.1 (detalles): se está preparando el terreno para que los proyectos Symfony2 puedan utilizar indistintamente Propel 2 o Doctrine2. Se decide que los bundles de cada ORM salgan del repositorio de código principal de Symfony2. Así que en los próximos días se eliminará el bundle de Doctrine. Cada organización (Propel y Doctrine) se encargará de desarrollar y mantener su propio bundle. Symfony2 se encargará de mantener los bridges, que sólo contienen el código que unen estos bundles con el resto de bundles y con Symfony2. También se apunta la posibilidad de crear una distribución de Symfony2 para Propel y otra para Doctrine.
• Extender la sección providers del archivo de configuración de seguridad (detalles): se decide seguir adelante con los cambios y mejoras propuestas en ese pull request, aunque esto supone que habrá que modificar la configuración de seguridad al actualizar a Symfony 2.1. Fabien dice que no importa porque el componente de seguridad está marcado como no estable.
• Cómo hacer que más gente utilice los componentes de Symfony2: Fabien dice que ya tiene pensada la nueva documentación que se va a escribir para cada componente. Todavía no ha empezado a escribirla, pero estima que podría estar lista para final de año. Algunos desarrolladores le sugieren que mientras tanto cree por lo menos un buen archivo README para cada componente con enlaces útiles. Fabien dice que mejor esperar a la documentación.

Además, durante la reunión Fabien dijo que no estaba completamente seguro de marcar la versión 2.1 de Symfony2 como versión LTS (cinco años de soporte garantizado). Quizás haya que esperar entonces a Symfony 2.2.

Como siempre, también puedes leer los logs completos de la reunión para conocer los detalles discutidos para cada punto del orden del día.

La versión 1.4.x de Symfony es la base de miles de aplicaciones web en todo el mundo, por eso los creadores de Symfony no la descuidan ni siquiera ahora que están completamente centrados en Symfony2.

Según su changelog, la nueva versión 1.4.15 corrige siete errores, siendo el más importante el error que impedía a las tareas relacionadas con Propel tener en cuenta si la aplicación tenía configuradas varias conexiones con bases de datos.

Como siempre, para actualizar tu versión de Symfony:

• Si usas el sandbox, te lo tienes que bajar otra vez.
• Si lo has instalado mediante el archivo comprimido de Symfony, te lo tienes que bajar otra vez desde www.symfony-project.org/installation/1_4 y debes descomprimirlo en el mismo directorio dentro de tu proyecto.
• Si lo has instalado mediante PEAR, ejecuta el comando  pear upgrade symfony/symfony-1.4.15
• Si lo instalas mediante Subversion, ejecuta el comando  svn checkout http://svn.symfony-project.com/tags/RELEASE_1_4_15/

Independientemente de cómo lo actualices, no olvides borrar la caché de cada proyecto después de la actualización mediante los siguientes comandos:

Si utilizas Doctrine:

$ php symfony doctrine:build --all-classes
$ php symfony cache:clear

Si utilizas Propel:

$ php symfony propel:build --all-classes
$ php symfony cache:clear

Fuente: symfony 1.4.15 released

Propel, el ORM favorito de gran parte de la comunidad Symfony, renace de sus cenizas y anuncia una próxima versión Propel2 muy potente. Aunque hace unos meses se anunció que esta nueva versión se basaría en Doctrine2, ahora todo vuelve a cambiar y Propel2 se basará definitivamente en Propel 1.6.x.

Los principales cambios ya anunciados son los siguientes:

• Sólo será compatible con PHP 5.3.
• Todo el código incluirá namespaces que seguirán el formato del estándar PSR-0 (el mismo de Symfony2)
• Será necesario hacer uso de un autoloader y la mayoría apuestan por usar el componente ClassLoader de Symfony2
• Se van a añadir nuevas excepciones propias (Propel sólo tiene dos por el momento).
• Se elimina (¡por fin!) el uso de Phing para los comandos de consola y se sustituye por el componente Console de Symfony2.
• Ya no se generarán clases de tipo Peer para cada clase del modelo.
• Se incluirá un nuevo sistema de logs seguramente basado en el componente Monolog de Symfony2.
• Se utilizará Twig para generar el código de las plantillas PHP de las clases del modelo.
• No se incluirá soporte para NoSQL.