El próximo sábado 8 de noviembre se celebra el primer día de los programadores de plugins de Symfony. Después del éxito de los dos code sprint celebrados, ahora le llega el turno a los plugins.

El objetivo del encuentro es discutir detalladamente todo lo que concierne a los plugins:

• Creación y nombrado
• Utilización de modelos de datos, formularios y acciones personalizadas
• Pruebas unitarias y funcionales
• Empaquetado y distribución
• Novedades de Symfony 1.2

De esta forma el encuentro te interesa tanto si has creado algún plugin y quieres actualizarlo/mejorarlo como si nunca has creado un plugin porque tienes muchas dudas.

Como es habitual, el encuentro se realiza en el canal IRC de Symfony (irc://irc.freenode.net/symfony) y el plan de trabajo es el siguiente:

• Sesión 1: crear y publicar plugins
• Sesión 2: crear plugins configurables
• Sesión 3: code sprints de plugins nuevos y existentes

Cada sesión tiene una duración de 2 horas y el horario del encuentro en las principales capitales es el siguiente:

• Madrid: 16:00 – 22:00
• Buenos Aires, Montevideo: 13:00 – 19:00
• Santiago de Chile, Asunción: 12:00 – 18:00
• La Paz: 11:00 – 17:00
• Caracas: 10:30 – 16:30
• La Habana, Lima, Quito: 10:00 – 16:00
• México DF: 9:00 – 15:00

Fuente: Plugin Developers Day This Saturday!

¿Qué sucede cuando juntas tres de las aplicaciones favoritas de los programadores web?  Alvaro Videla, un symfonero uruguayo, acaba de hacerlo en su proyecto FireSymfony, que combina Symfony, Firefox y Firebug.

FireSymfony permite depurar las aplicaciones Symfony directamente desde el navegador Firefox, sin necesidad de utilizar la barra de depuración web. La primera versión del plugin permite mostrar dentro de un panel de Firebug exactamente la misma versión que la barra de depuración original:

Técnicamente, FireSymfony se compone de un plugin de Symfony que envía los datos de depuración al navegador mediante JSON y una extensión de Firefox que se encarga de añadir el panel de Symfony en Firebug:

• Más información y descarga del plugin fireSymfonyPlugin
• Más información y descarga de la extensión firesymfony (como se trata de una extensión en pruebas, es necesario estar dado de alta como usuario en el sitio web de las extensiones de Firefox)

La seguridad es uno de los pilares de Symfony desde que en mayo de 2008 se modificó su política de seguridad tras un grave agujero de seguridad que tardó demasiado tiempo en corregirse. Hoy en día Symfony incluye numerosas estrategias y utilidades para hacer frente a los ataques XSS y CSRF.

La semana pasada, Fabien Potencier, creador de Symfony, publicó un artículo en el blog oficial comentando una grave vulnerabilidad descubierta en RubyOnRails. Aunque la intención de Fabien no es iniciar una guerra con RubyOnRails sobre cuál de los dos frameworks es mejor, Symfony presenta una gran ventaja en este aspecto.

Los formularios de Symfony, desde su versión 1.1, son objetos de primer nivel, por lo que no tienen efecto los ataques que intentan inyectar campos que no pertenecen al formulario original. Tal y como se explica en el capítulo 2 del libro de formularios de Symfony, las opciones allow_extra_fields y filter_extra_fields permiten controlar si todos los campos del formulario deben tener asignado un validador y si se deben filtrar todos los campos adicionales.

En los comentarios del artículo de Fabien, un usuario llamado Toc alertaba sobre una posible vulnerabilidad de tipo XSS en el mecanismo de formularios. En menos de 7 horas el error había sido investigado, confirmado y solucionado. El resultado es la versión 1.1.4 de Symfony que incluye la corrección r11932.

En otro comentario del mismo artículo, el symfonero Pablo (conocido por su nick pablodip) asegura que actualmente Symfony no se encuentra protegido contra algunos ataques de tipo CSRF. De hecho, Pablo ha creado un plugin llamado pdCSRFPlugin para solucionar estos problemas.

Los plugins son uno de los puntos fuertes de Symfony, ya que permiten añadir nuevas características al framework y también permiten modificar cualquier funcionalidad. Sin embargo, elactual sistema de plugins tiene bastantes carencias:

• No existen unas reglas oficiales que los plugins deban seguir para asegurar su calidad
• No existe una recomendación oficial sobre cómo organizar el desarrollo de las diferentes versiones del plugin para cada versión de Symfony
• Algunos plugins han sido abandonados por sus creadores y otros apenas se mantienen
• No existe un sitio específico para acceder a todos los plugins de forma ordenada
• Todavía no se ha terminado el sitio symfony-forge.com

Afortunadamente, los creadores de Symfony se han propuesto acabar con todas estas carencias y han empezado por una de las más urgentes. Desde hace unas horas, ya está disponible la nueva sección de plugins del sitio oficial de Symfony:

El nuevo sistema está completamente hecho a medida, porque con más de 200 plugins ya no era cómo trabajar con el viejo Trac. Algunas de las características más destacadas del nuevo sistema son:

• Toda la información de los plugins está centralizada en un único sitio.
• Puedes buscar y filtrar plugins en función de la versión de Symfony, el ORM que utilizas, el autor o el nombre del plugin.
• Cada plugin muestra la información de su licencia, las instrucciones de instalación, las dependencias, toda su documentación, la lista completa de versiones para cada versión de Symfony, el listado de programadores que han creado el plugin, etc.
• Los creadores de cada plugin tienen acceso a su sección de administración, donde pueden categorizar el plugin, publicar nuevas versiones y añadir otros programadores al equipo de desarrollo.

Si eres el responsable de algún plugin, asegúrate que su archivo package.xml contiene toda la información necesaria y que está actualizada, ya que es la fuente que se utiliza para obtener la información de los plugins.

Por último, la nueva sección de plugins no es incompatible con el proyecto symfony-forge.com (sitio web dedicado en exclusiva a los plugins de Symfony, que se publicará próximamente) y tampoco sustituye al actual Trac (los plugins siguen utilizando el sistema de tickets del Trac y el repositorio común de Symfony).

Fuente: Plugins have a new home

El gran François Zaninotto ha escrito un artículo imprescindible titulado Comparing Propel, Doctrine and sfPropelFinder en el que compara de forma práctica los ORM Propel y Doctrine y también su plugin sfPropelFinderPlugin.

Propel es el ORM clásico de Symfony. Su principal ventaja es que está completamente integrado con Symfony y que decenas de plugins sólo funcionan para Propel. Su desventaja es que la versión 1.2 que se utiliza actualmente tiene un rendimiento muy mejorable.

Doctrine es el ORM del futuro de Symfony. Su principal ventaja es el rendimiento en ejecución y la forma tan concisa en la que se pueden escribir consultas muy complejas. Su principal problema es que todavía no dispone del mismo nivel de integración que Propel.

sfPropelFinder es un plugin que mejora las posibilidades de Propel haciendo que su sintaxis sea mucho más concisa.

En su artículo, François compara la sintaxis de los diferentes ORM haciendo las mismas consultas complejas con todos ellos. A continuación se muestran dos ejemplos de consultas complejas.

1) Obtener un artículo de la base de datos a partir de su título:

Con Propel:

$c = new Criteria();
$c->add(ArticuloPeer::TITLE, 'Título del artículo');
$articulo = ArticuloPeer::doSelectOne($c);

Con Doctrine:

$articulo = Doctrine::getTable('Articulo')->
  findOneByTitle('Título del artículo');

Con sfPropelFinderPlugin:

$articulo = sfPropelFinder::from('Articulo')->
  findOneByTitle('Título del artículo');

2) Obtener los últimos 5 comentarios de un artículo:

Con Propel:

$c = new Criteria();
$c->addDescendingOrderByColumn(ComentarioPeer::PUBLISHED_AT);
$c->setLimit(5);
$comentarios = $articulo->getComentarios($c);

Con Doctrine:

$comentarios = Doctrine_Query::create()->
  from('Comentario c')->
  where('c.articulo_id = ?', array($articulo->getId()))->
  orderby('c.published_at DESC')->
  limit(5)->
  execute();

Con sfPropelFinderPlugin:

$comentarios = sfPropelFinder::from('Comentario')->
  relatedTo($articulo)->
  orderBy('PublishedAt', 'desc')->
  find(5);

El artículo original contiene multitud de consultas complejas para que puedas comparar la sintaxis de los tres ORM.

Por último, aunque no muestra los datos exactos, François también indica el rendimiento relativo de cada ORM en forma de lista ordenada:

1. Propel 1.3 (el que tiene mejor rendimiento)
2. sfPropelFinder con Propel 1.3
3. Doctrine 0.11
4. Propel 1.2
5. sfPropelFinder con Propel 1.2 (el que tiene peor rendimiento)

Fuente: Comparing Propel, Doctrine and sfPropelFinder