Tareas

La línea de comandos de Symfony ahora trata de determinar la anchura de la ventana en la que se ejecuta para ajustar el tamaño de las líneas. Si no se puede detectar la anchura, se siguen utilizando 78 columnas como longitud máxima de cada línea.

sfTask::askAndValidate()

sfTask::askAndValidate() es un método nuevo para preguntar al usuario y validar su respuesta:

$respuesta = $this->askAndValidate('¿Cuál es tu email?', new sfValidatorEmail());

Este método también acepta un array de opciones, como se explica en la documentación de la API de Symfony.

symfony:test

Para comprobar que Symfony funciona bien en la plataforma en la que está instalado, es habitual que los programadores lancen todo el conjunto de pruebas que incluye Symfony. Hasta ahora había que buscar y utilizar un script llamado prove.php. A partir de Symfony 1.3/1.4, existe una tarea específica llamada symfony:test y que lanza la ejecución de todas las pruebas del código fuente de Symfony:

$ php symfony symfony:test

Si estabas acostumbrado a ejecutar el script php test/bin/prove.php, ahora debes acostumbrarte a ejecutar el comando php data/bin/symfony symfony:test.

project:deploy

La tarea project:deploy ha sido mejorada un poco, ya que si se le pasa la opción -t muestra el progreso de la transferencia de archivos en tiempo real. Si no se utiliza esa opción, la tarea no muestra nada salvo los posibles mensajes de error. Además, los mensajes de error ahora se muestran (si es posible) con un color de fondo rojo, para poder identificarlos más fácilmente.

generate:project

Doctrine es el ORM configurado por defecto en Symfony 1.3/1.4 cuando se ejecuta la tarea generate:project:

$ php /ruta/hasta/symfony generate:project prueba

Si quieres utilizar Propel en tus proyectos, incluye la opción --orm:

$ php /ruta/hasta/symfony generate:project prueba --orm=Propel

Si no quieres utilizar ni Propel ni Doctrine, puedes indicar la opción --orm con el valor none:

$ php /ruta/hasta/symfony generate:project prueba --orm=none

La nueva opción --installer permite pasar un script de PHP al instalador para personalizar la creación de los proyectos. Este script se ejecuta en el mismo contexto de la tarea, por lo que puede utilizar cualquiera de sus métodos. Los métodos más útiles son los siguientes: installDir(), runTask(), ask(), askConfirmation(), askAndValidate(), reloadTasks(), enablePlugin() y disablePlugin().

El blog oficial de Symfony publicó un artículo sobre el nuevo instalador personalizado.

También se puede pasar a la tarea generate:project un segundo argumento llamado author y que especifica el valor que se debe utilizar en la etiqueta @author de PHPdoc cuando Symfony genera las nuevas clases.

$ php /ruta/hasta/symfony generate:project prueba "Jose Perez"

sfFileSystem::execute()

El nuevo método sfFileSystem::execute() reemplaza al anterior método sfFileSystem::sh(). Entre sus nuevas opciones se encuentra la posibilidad de procesar en tiempo real la salida de stdout y stderr. También puede devolver estas dos salidas en forma de array. Si quieres ver un ejemplo de su uso, echa un vistazo a la clase sfProjectDeployTask.

task.test.filter_test_files

Las tareas de tipo test:* ahora filtran los archivos de las pruebas mediante la notificación del evento task.test.filter_test_files antes de ejecutar las pruebas. Los parámetros de este evento incluyen argumentos (arguments) y opciones (options).

Mejoras en sfTask::run()

Ahora se puede pasar un array asociativo de argumentos y opciones a la tarea sfTask::run():

$task = new sfDoctrineConfigureDatabaseTask($this->dispatcher, $this->formatter);
$task->run(
  array('dsn'  => 'mysql:dbname=mydb;host=localhost'),
  array('name' => 'master')
);

La antigua forma de hacerlo todavía sigue funcionando:

$task->run(
  array('mysql:dbname=mydb;host=localhost'),
  array('--name=master')
);

sfBaseTask::setConfiguration()

Cuando se ejecuta desde PHP una tarea que extiende de sfBaseTask, ya no es necesario pasar las opciones --application y --env antes de ejecutarla mediante ->run(). Ahora puedes pasarle directamente la configuración invocando el método ->setConfiguration().

$task = new sfDoctrineLoadDataTask($this->dispatcher, $this->formatter);
$task->setConfiguration($this->configuration);
$task->run();

La antigua forma de hacerlo todavía sigue funcionando:

$task = new sfDoctrineLoadDataTask($this->dispatcher, $this->formatter);
$task->run(array(), array(
  '--application='.$options['application'],
  '--env='.$options['env'],
));

project:disable y project:enable

Las tareas project:disable y project:enable ahora permiten habilitar o deshabilitar un entorno de ejecución completo:

$ php symfony project:disable prod
$ php symfony project:enable prod

También se puedes habilitar o deshabilitar aplicaciones específicas de ese entorno:

$ php symfony project:disable prod frontend backend
$ php symfony project:enable prod frontend backend

Se ha mantenido la retro-compatibilidad de estas tareas, por lo que también puedes utilizarlas como antes:

$ php symfony project:disable frontend prod
$ php symfony project:enable frontend prod

help y list

Las tareas help y list ahora pueden mostrar sus contenidos en formato XML:

$ php symfony list --xml
$ php symfony help test:all --xml

La salida mostrada se basa en un nuevo método llamado sfTask::asXml() y que devuelve la representación XML de un objeto de tipo tarea.

Esta salida XML es útil sobre todo para aplicaciones como los IDE.

project:optimize

El propósito de esta tarea consiste en reducir el número de operaciones de lectura sobre el disco duro cuando se ejecuta una aplicación Symfony. Su funcionamiento se basa en guardar en una cache la localización de los archivos de las plantillas de la aplicación. Esta tarea sólo debería utilizarse en el servidor de producción. Además, es necesario volver a ejecutar la tarea cada vez que se modifica el proyecto.

$ php symfony project:optimize frontend

generate:app

La tarea generate:app ahora comprueba si existe una estructura propia de archivos y directorios en
data/skeleton/app. Si no existe esa estructura propia, se emplea el esqueleto de archivos y directorios definidos por defecto por Symfony.

Enviando un email desde una tarea

Ahora se puede enviar fácilmente un email desde una tarea mediante el método getMailer().

Utilizando el enrutamiento en una tarea

Ahora se puede obtener el objeto del enrutamiento dentro de una tarea mediante el método getRouting().

Excepciones

Carga automática de clases

Si se lanzan excepciones durante la carga automática de clases, Symfony las atrapa y muestra el mensaje de error al usuario, por lo que se resuelven muchos de los errores de tipo “página completamente en blanco” (o “White screen of death”).

Barra de depuración web

Si es posible, la barra de depuración web ahora también se muestra en las páginas de las excepciones en el entorno de desarrollo.

Integración con Propel

Propel ha sido actualizado a su versión 1.4, de la que puedes obtener más información en su propio sitio web: http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4

propel:insert-sql

Antes de eliminar toda la información de la base de datos, la tarea propel:insert-sql pregunta al usuario por su confirmación. Además, como esta tarea puede eliminar información de varias bases de datos, ahora también muestra el nombre de las conexiones de las bases de datos relacionadas.

propel:generate-module, propel:generate-admin, propel:generate-admin-for-route

Las tareas propel:generate-module, propel:generate-admin y propel:generate-admin-for-route ahora admiten una opción llamada --actions-base-class que permite configurar la clase base de las acciones para todos los módulos generados.

Comportamientos de Propel

Las clases propias de Symfony utilizadas para extender Propel se han sustituido por clases del nuevo sistema de comportamientos de Propel 1.4.

Si quieres añadir los nuevos comportamientos nativos en tus modelos de Propel, puedes hacerlo en el archivo de configuración schema.yml:

classes:
  Article:
    propel_behaviors:
      timestampable: ~

También puedes utilizar la vieja sintaxis del archivo schema.yml:

propel:
  article:
    _propel_behaviors:
      timestampable: ~

Deshabilitando la generación de formularios

Ahora se puede deshabilitar la generación automática de formularios si se pasan determinados parámetros a los modelos de Propel mediante el comportamiento llamado symfony:

classes:
  UserGroup:
    propel_behaviors:
      symfony:
        form: false
        filter: false

Para que esta opción sea tenida en cuenta, debes generar el modelo al menos dos veces, ya que el comportamiento se añade al modelo después de la primera generación.

Utilizando una versión diferente de Propel

Utilizar una versión diferente de Propel es tan sencillo como utilizar las variables de configuración sf_propel_runtime_path y sf_propel_generator_path en la clase ProjectConfiguration:

// config/ProjectConfiguration.class.php
public function setup()
{
  $this->enablePlugins('sfPropelPlugin');
 
  sfConfig::set('sf_propel_runtime_path', '/path/to/propel/runtime');
  sfConfig::set('sf_propel_generator_path', '/path/to/propel/generator');
}

Enrutamiento

Requerimientos por defecto

El requerimiento \d+ ahora sólo se aplica en sfObjectRouteCollection cuando la opción column es el valor id por defecto. Esto significa que ya no tienes que incluir un requerimiento alternativo cuando se especifica una columna no numérica (por ejemplo slug).

Opciones de sfObjectRouteCollection

Se ha añadido una nueva opción llamada default_params en las rutas de tipo sfObjectRouteCollection. Esta opción permite añadir parámetros por defecto para todas las rutas generadas por la colección:

forum_topic:
  class: sfDoctrineRouteCollection
  options:
    default_params:
      section: forum

Línea de comandos

Mensajes coloreados

Cuando se utiliza la línea de comandos de Symfony, el framework trata de averiguar si tu consola de comandos soporta los colores. No obstante, Symfony no siempre determina correctamente esta característica, como por ejemplo cuando utilizas Cygwin (ya que los colores siempre están deshabilitados en las plataformas Windows).

A partir de Symfony 1.3/1.4, puedes forzar el uso de los colores en los mensajes mostrados por Symfony pasando la opción global --color.

Internacionalización

Actualización de datos

Los datos utilizados en todas las operaciones de tipo i18n se ha actualizado a partir de la última versión del ICU project. Symfony ahora incluye unos 330 archivos de localización, lo que supone un incremento de unos 70 archivos respecto a Symfony 1.2. Como los datos actualizados pueden ser ligeramente diferentes a los anteriores, algunas pruebas unitarias pueden fallar si por ejemplo comprobaban “el décimo elemento de la lista de idiomas”.

Ordenación según la cultura del usuario

Las ordenaciones de estos datos dependientes de la localización también dependen ahora de esa misma localización. Puedes utilizar el método sfCultureInfo->sortArray() para ello.

Plugins

Antes de Symfony 1.3/1.4, todos los plugins se activaban por defecto, salvo sfDoctrinePlugin y sfCompat10Plugin:

class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    // for compatibility / remove and enable only the plugins you want
    $this->enableAllPluginsExcept(array('sfDoctrinePlugin', 'sfCompat10Plugin'));
  }
}

Los nuevos proyectos creados con Symfony 1.3/1.4 deben activar de forma explícita todos sus plugins dentro de la clase ProjectConfiguration antes de poder utilizarlos:

class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    $this->enablePlugins('sfDoctrinePlugin');
  }
}

La tarea plugin:install activa automáticamente todos los plugins que instala (y la tarea plugin:uninstall los deshabilita). Si instalas un plugin mediante Subversion, debes habilitarlo a mano.

Si quieres utilizar alguno de los plugins internos de Symfony, como sfProtoculousPlugin o sfCompat10Plugin, sólo tienes que añadir la correspondiente instrucción enablePlugins() en la clase ProjectConfiguration.

sfPluginConfiguration::connectTests()

Si quieres conectar las pruebas de un plugin con las tareas test:* de Symfony, puedes invocar el método ->connectTests() del plugin dentro del método setupPlugins():

class ProjectConfiguration extends sfProjectConfiguration
{
  public function setupPlugins()
  {
    $this->pluginConfigurations['sfExamplePlugin']->connectTests();
  }
}

Opciones de configuración

sf_file_link_format

Symfony 1.3/1.4 muestra las rutas de los archivos como enlaces pinchables siempre que sea posible (por ejemplo dentro de las plantillas de las excepciones en el entorno de desarrollo). La opción sf_file_link_format se define para este propósito. Si no está definida, Symfony busca la opción xdebug.file_link_format en el archivo de configuración de PHP.

Si quieres que al pinchar la ruta de un archivo este se abra por ejemplo en el editor de textos TextMate, añade lo siguiente en el archivo de configuración settings.yml:

all:
  .settings:
    file_link_format: txmt://open?url=file://%f&line=%l

La variable %f se reemplaza por la ruta absoluta del archivo y la variable %l se reemplaza con el número de línea en el que se debe posicionar el editor.