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.

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.

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

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

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.

Para ello se acaba de publicar la versión estable de Propel 1.6, la última que se publicará de la rama 1.X. A pesar de que la lista de novedades de Propel 1.6 es casi inacabable, esta nueva versión es completamente retrocompatible con las versiones 1.4 y 1.5.

Las principales novedades de Propel 1.6 son las siguientes:

• Migraciones. Si añades o eliminas tablas y columnas en tu base de datos, Propel se encargará de hacer los cambios necesarios para que la aplicación siga funcionando bien y sin perder información.
• Nuevos comportamientos. Doctrine2 ha eliminado todos los comportamientos, pero Propel cada vez tiene más. Los últimos son Versionable (que permite guardar una versión para cada cambio en un objeto) y i18n (para hacer aplicaciones multi-idioma sin depender de lo que ofrezca cada framework).
• Importación y exportación de información en los formatos XML, YAML, JSON y CSV.
• Tipos de columna avanzados. Se han añadido los tipos enum, array y object.

Puedes ver otras novedades destacadas en el post del blog oficial de Propel y en la extensa documentación oficial de Propel 1.6.

Si programas aplicaciones con symfony 1.4, ya puedes utilizar Propel 1.6 mediante el plugin sfPropel15Plugin (que no te confunda el nombre, porque este el plugin bueno para utilizar Propel 1.6). Si programas con Symfony2, debes utilizar el bundle PropelBundle.

Por otra parte, el desarrollo de Propel 2 ya ha comenzado y puedes seguir su evolución mediante su repositorio oficial en github: https://github.com/fzaninotto/Propel2

Fuente: Propel 1.6 is Released

• Migraciones, algo que ya tenía Doctrine desde hace mucho tiempo y se echaba en falta en Propel
• Nuevos behaviors o comportamientos (versionable, realmente espectacular e I18n para internacionalización). Curiosamente, la nueva versión 2.0 de Doctrine ha eliminado todos los behaviors
• Importación y volcado de información a XML/YAML/JSON/CSV
• Soporte de esquemas/namespaces de SQL (sólo para MySQL, PostgreSQL y Microsoft SQL Server)
• Nuevos tipos de columna avanzados ENUM, OBJECT y ARRAY

Como siempre que se trata de Propel, la calidad del trabajo realizado es altísima: todas las nuevas características son retrocompatibles, incluyen tests unitarios y están completamente documentadas.

Para utilizar Propel 1.6 en tus aplicaciones Symfony, debes hacer uso del plugin sfPropel15Plugin. Puedes leer la guía de instalación de sfPropel15Plugin en el propio repositorio de Propel.

Fuente: Get Ready For Propel 1.6: The Beta 1 Is Released.

Nada más lejos de la realidad: Propel seguirá vivo y dando que hablar en el mundo de los ORM por mucho tiempo. Para sorpresa de todos, en la reunión se anunció que Propel 2 será una capa por encima de Doctrine 2.

Como ya sabes, Doctrine 2 está formado por dos partes:

• DBAL: una capa que abstrae todas las operaciones de bajo nivel sobre las bases de datos. Esta capa es la encargada de convertir las operaciones sobre datos en sentencias SQL especialmente adaptadas a la base de datos utilizada.
• ORM: esta capa es la que permite manipular la información de la base de datos mediante objetos. Esta parte de Doctrine es la más conocida y utilizada por los programadores. En Symfony esta parte es la que tiene relación con el esquema, las entidades, las consultas y el lenguaje DQL.

Propel 2 utilizará toda la capa DBAL y partes de la capa ORM de Doctrine 2 para su funcionamiento interno. Externamente Propel continuará utilizando el patrón ActiveRecord, lo que significa que va a ser muy parecido a Propel 1 y por tanto, muy diferente a Doctrine. Simplificándolo mucho, Propel 2 será Doctrine por dentro y Propel 1 por fuera.

Por otra parte, Propel 2 requerirá PHP 5.3, será compatible con Propel 1 en todo lo posible, su código se pasa a Github y el gran François Zaninotto ha decidido finalmente liderar el proyecto. Si quieres conocer todos los detalles, puedes leer el log de toda la reunión del IRC y también puedes seguir a François Zaninotto en Github para enterarte de todo el código nuevo que se publique.

Fuente: Propel2 Will Be an ActiveRecord Implementation Based On Doctrine2

• News of the Symfony2 world (Fabien Potencier):
  • Ha sido la sesión más floja, ya que simplemente ha recapitulado las últimas noticias relacionadas con Symfony2.
  • Se ha centrado especialmente en los componentes más recientes (CssSelector, DomCrawler, Browser, Finder).
• Symfony2 meets Propel 1.5 (François Zaninotto):
  • En primer lugar se han mostrado las últimas novedades de Propel 1.5. François ha aprovechado para darle un buen repaso a Doctrine y ha demostrado que Propel, lejos de estar muerto, está más vivo que nunca.
  • François recalca que las mejores características de Propel son las Model Queries, la Concrete Table Inheritance y el aggregate_column behavior.
  • Respecto a la integración de Propel con Symfony2, va por buen camino pero faltan todavía muchas cosas por hacer: definir esquemas en YAML, integración con la barra de depuración web, integración con los formularios y con el admin generator.
  • Principales razones para utilizar Propel en vez de Doctrine 2: es rápido, sigue el patrón ActiveRecord y ya está disponible de forma estable.
• Symfony and Doctrine (Jonathan Wage):
  • Jonathan apenas ha mencionado a Propel, salvo para decir que la filosofía de Doctrine es completamente diferente al ActiveRecord y que eso está bien porque en su opinión “ActiveRecord is flawed”.
  • La parte del ORM ya no tiene código mágico, todo es explícito.
  • Se ha presentado el bundle de Doctrine para MongoDB y la gran similitud entre el ODM y el ORM. Esto facilitará la transición del SQL a filosofías NoSQL.
  • La otra gran novedad de Doctrine 2 será la completa renovación de las migraciones (totalmente integradas en Symfony mediante el DoctrineMigrationsBundle).
• Unit & Functional Tets (Fabien Potencier):
  • Fabien cree que utilizar herramientas estándar es lo correcto, por lo que Symfony utilizará a partir de ahora PHPUnit
  • A continuación ha hablado de buenas prácticas para las pruebas y ha concluido con las pruebas funcionales.
  • Symfony2 podrá lanzar pruebas en paralelo gracias al componente que permite crear forked PHP processes.
  • A Fabien le han vuelto a preguntar por Sismo, el servidor de integración continua que utiliza Symfony y que ha creado el propio Fabien. Harto de que la gente no sea capaz de entender la frase “no hay fecha prevista para publicar Sismo como software libre”, Fabien ha dicho que “deberíamos hacer como si Sismo no existiera”.
• The new form framework (Bernhard Schussek):
  • El componente de los formularios ha sido completamente rediseñado para que sea simple y fácilmente reutilizable.
  • Nuevos widgets (que ahora parece que se llaman fields): BirthdayField, PercentField, NumberField, IntegerField. Widgets especiales: RepeatedField, CollectionField, FieldGroup.
  • Personalmente el nuevo componente de formularios no me parece mucho más sencillo que el que existe actualmente.
• Caching on the edge (Fabien Potencier):
  • La conferencia ha concluido con la presentación de la verdadera killer feature de Symfony 2: un sistema de caché parecido a Varnish pero desarrollado con PHP.
  • En pocas palabras: Symfony2 incluye un sistema de cache que puede almacenar páginas enteras, de forma que tus aplicaciones tengan un rendimiento estratosférico.
  • Si utilizaste el plugin sfSuperCachePlugin en Symfony 1.X, esta nueva cache es como una versión infinitamente mejorada de ese plugin.
  • En aplicaciones sencillas, con 10 usuarios concurrentes Symfony2 es 5 veces más rápido que Symfony 1; con 100 usuarios concurrentes, Symfony2 es 11 veces más rápido que Symfony 1.
  • En aplicaciones complejas, con 10 usuarios concurrentes Symfony2 es 8 veces más rápido que Symfony 1; con 100 usuarios concurrentes, Symfony2 es 85 veces más rápido que Symfony 1.
  • Symfony2 ha sido diseñado desde el primer día para hacer uso de esta característica. Toda su arquitectura interna se ha diseñado para hacer posible esta super cache.
  • La clave es que Symfony2 incluye un acelerador HTTP programado en PHP. Se encarga de la expiración y validación de la caché HTTP.
  • Symfony2 soporta el uso de ESI o Edge Side Includes y otras muchas ideas y tecnologías definidas en el estándar HTTP Bis.

Otros anuncios importantes de la conferencia han sido los siguientes:

• Van a intentar desarrollar una herramienta para actualizar las aplicaciones symfony 1.X a Symfony2. Todavía están pensando en cómo hacerlo (incluso se habla de una capa de emulación de Symfony 1.X ejecutada sobre Symfony2). Puede que incluso no sea posible hacerlo y no exista tal herramienta de actualización.
• Si vas a desarrollar un sitio web que debe estar en producción en los próximos meses, olvídate de Symfony2.
• La primera versión alpha de Symfony2 estará disponible seguramente en Septiembre.
• La nueva documentación de Symfony2 se publicará el miércoles por la tarde o el jueves por la mañana.

Symfony2 cada día está más cerca y continúa añadiendo componentes que lo convierten en el mejor framework PHP para aplicaciones profesionales. Si quieres conocer más características, recuerda que las próximas Jornadas Symfony en Castellón incluirán una sesión dedicada a Symfony2.