Nuevo en Symfony 2.7: mejoras para ser más productivo

Symfony 2.7 incluye innumberables mejoras y refactorizaciones en todo su código. Muchas de estas mejoras son cambios muy pequeños pero que mejoran la productividad de tu día a día. En este artículo te mostramos siete de esas pequeñas grandes mejoras.

Añadido el atajo getParameter() al controlador base

Cuando empiezas a aprender Symfony, uno de los errores típicos consiste en intentar obtener dentro de un controlador el valor de un parámetro del contenedor. Probablemente intentaste usar primero el método get() y al ver que no funcionaba, es posible que probaras con el método getParameter(), que no existe. Por suerte, en Symfony 2.7 se ha añadido precisamente ese atajo getParameter() para obtener el valor de cualquier parámetro del contenedor:

use Symfony\Bundle\FrameworkBundle\Controller\Controller;
 
class DefaultController extends Controller
{
    public function indexAction()
    {
        // Symfony 2.6
        $value = $this->container->getParameter('param_name');
 
        // Symfony 2.7
        $value = $this->getParameter('param_name');
 
        // ...
    }
}

Esta funcionalidad ha sido desarrollada por Hugo Hamon en el pull request #14052 de Symfony.

Mostrar información sobre el estado de tu versión Symfony

Teniendo en cuenta la cantidad de nuevas funcionalidades que incluyen las nuevas versiones de Symfony, seguramente nadie quiere utilizar una versión obsoleta del framework. Por eso, a partir de Symfony 2.7, la barra de depuración web te indicará mediante un código de colores el estado de tu versión de Symfony:

Symfony Version Feedback

Esta funcionalidad ha sido desarrollada por Wouter De Jong en el pull request #13626 de Symfony.

Añadido el código de estado HTTP a los listados del profiler

En ocasiones resulta difícil encontrar una petición concreta de entre todas las que almacena el profiler de Symfony. Para facilitar un poco las cosas, en Symfony 2.7 cada petición almacenada por Symfony también muestra su código de estado HTTP. Así te será más fácil localizar o descartar las peticiones erróneas, los redireccionamientos, etc.

Symfony Profiler HTTP Status information

Si utilizas una base de datos MySQL o SQLite para almacenar la información del profiler de Symfony, tienes que regenerar la tabla donde se guardan los datos o debes añadir a mano una nueva columna llamada status_code. manually.

Esta funcionalidad ha sido desarrollada por Alexander Schwenn en el pull request #13034 de Symfony.

Soporte de parámetros del contenedor en las condiciones de las rutas

En Symfony 2.7, las condiciones de las rutas ahora soportan el uso de parámetros del contenedor. Simplemente usa la notación tradicional y encierra el nombre del parámetro con % para que Symfony lo reemplace por su valor antes de evaluar la expresión. Ejemplo:

# app/config/routing.yml
contact:
    path:     /contact
    defaults: { _controller: AppBundle:Main:contact }
    condition: "request.headers.get('User-Agent') matches '%navegadores_permitidos%'"

Este cambio introduce un pequeñísimo cambio incompatible con las versiones anteriores. Si tienes una expresión como foo%bar%2, en Symfony 2.6 se interpreta como si usaras el operador módulo ($foo % $bar % 2), pero en Symfony 2.7 se considera que %bar% es un parámetro, por lo que si no está definido, verás un mensaje de error.

Esta funcionalidad ha sido desarrollada por Nikita Nefedov en el pull request #12960 de Symfony.

Movidos los comandos de tipo lint al namespace lint:

En las versiones anteriores de Symfony movimos todos los comandos de depuración al namespace debug: porque creemos que es mejor agrupar los comandos según su funcionalidad.

En Symfony 2.7 hemos hecho lo mismo con los comandos de tipo lint que se usan para descubrir errores de sintaxis en los archivos YAML y las plantillas Twig:

# Symfony 2.6
$ php app/console yaml:lint ...
$ php app/console twig:lint ...
 
# Symfony 2.7 (los nombres anteriores siguen funcionando bien)
$ php app/console lint:yaml ...
$ php app/console lint:twig ...

Aunque este cambio puede parecer ridículamente simple, agrupar los comandos según su funcionalidad hace que el framework sea más consistente y eso siempre es bueno.

Esta funcionalidad ha sido desarrollada por Abdellatif Ait boudad en el pull request #14116 de Symfony.

El comando lint:twig ahora soporta múltiples archivos y directorios

En Symfony 2.7 puedes pasar cualquier número de archivos y/o directorios al comando lint:twig:

# Symfony 2.6 (solo un archivo o un directorio)
$ php app/console lint:twig app/Resources/views/base.html.twig
  1/1 valid files
 
$ php app/console lint:twig app/Resources/views/blog/
  4/4 valid files
 
# Symfony 2.7 (todos los archivos y directorios que quieras)
$ php app/console lint:twig app/Resources/views/base.html.twig app/Resources/views/blog/
  5/5 valid files

Esta funcionalidad ha sido desarrollada por Miroslav Šustek en el pull request #13548 de Symfony.

Reinicio automático del servidor web embebido

Cada vez es más común usar el servidor web embebido de PHP mientras desarrollas aplicaciones Symfony. Seguramente ejecutas el comando server:run añadido en Symfony 2.2 para arrancar ese servidor.

Sin embargo, en Symfony 2.6 se añadieron tres nuevos comandos para controlar el servidor: server:start, server:status y server:stop. Lo único malo es que server:start requiere de la extensión pcntl de PHP para funcionar.

Así que en Symfony 2.7, si ejecutas el comando server:start y no tienes la extensión pcntl, Symfony ejecutará automáticamente el comando server:run.

Esta funcionalidad ha sido desarrollada por Wouter De Jong en el pull request #14198 de Symfony.

Conviértete en un miembro activo de la comunidad Symfony

Todas estas mejoras han surgido de la propia comunidad Symfony y han sido implementadas por voluntarios. Si tu también quieres ser un miembro activo de la comunidad, lee las guías para contribuir al proyecto Symfony y propón nuevas ideas, envía pull requests o revisa el código enviado por otros.

Fuente: New in Symfony 2.7: Productivity improvements

Comentarios

  1. Excelente Trabajo a todo el equipo y la comunidad Symfony, y además a ti, por traer está información para los de habla Hispana :).

    Una pregunta, la funcionalidad que verifica el status de la versión de Symfony, entiendo que cachea la petición que hace (por cuestiones de rendimiento), ¿pero qué pasa si estamos trabajando sin Internet y no se obtiene una respuesta para cachearla? ¿Se tiene esto en cuenta y no se hacen más peticiones al servidor? ¿o intenta obtener una respuesta cada vez?

    manuel_j555 el 23 de abril de 2015, 16:49:00

  2. @manuel_j555 me alegro que te gusten estos artículos sobre las novedades de Symfony.

    Me gusta la pregunta que haces sobre la funcionalidad que te avisa del estado de la versión Symfony. Si echas un vistazo al pull request original verás que yo estaba radicalmente en contra de esta funcionalidad. El motivo es precisamente tener que hacer una petición a Internet para saber el estado de la versión Symfony que estás usando.

    En mi opinión hacerlo así tiene muchos problemas, pero el más grave es el de la privacidad: Symfony, por su cuenta, sin avisarte y sin posibilidad de desactivarlo, está haciendo consultas a un servidor de terceros (symfony.com en este caso). En el repositorio de GitHub ya hemos recibido varios mensajes de gente que no está de acuerdo con esto.

    Y hay muchos más problemas. Por ejemplo un usuario informó hace poco que en su empresa tienen uno de esos proxys que prohíben casi todo y eso hacía que las peticiones de sus aplicaciones Symfony ahora duraran varios segundos debido a la petición a symfony.com que se está bloqueando.

    Por suerte, en este pull request van a cambiar la forma de implementar esta funcionalidad. Ahora la información sobre cuándo caduca cada versión de Symfony se incluye dentro del propio código fuente de Symfony. Así que ya no se hará nunca ninguna petición para obtener esta información.

    Javier Eguiluz el 23 de abril de 2015, 17:15:00

  3. Precisamente yo me encuentro en la situación que describes Javier, el proxy de mi empresa corta las conexiones de forma que al actualizar a la 2.7.0-BETA1 me encontré con tiempos de carga de 60 segundos (timeout de la llamada a symfony.com).

    Cuando vi que se realizaba una petición externa desde el propio framework sin solicitarlo yo me pareció una pésima idea, me alegra ver que esto no va a ser así en la versión definitiva.

    Saludos y gracias por el fantástico trabajo

    David Negreira Rios el 23 de abril de 2015, 17:30:43

  4. Muchas gracias por la respuesta Javier :)

    manuel_j555 el 23 de abril de 2015, 20:33:03

  5. Los felicito por los grandes cambios que han hecho a Symfony2. Bienvenida la nueva versión :).

    Javier hay un error que esta saliendo que la versión Symfony 2.7.x@beta "DEPRECATED - The Symfony\Component\OptionsResolver\OptionsResolver::setOptional method is deprecated since version 2.6 and will be removed in 3.0. Use the setDefined() method instead.", pero no hay documentación precisa para realizar los cambios. He realizado los siguientes cambios al formulario type pero sigue saliendo: Agregar la librería: use Symfony\Component\OptionsResolver\OptionsResolver;

    public function configureOptions(OptionsResolver $resolver) { $resolver->setDefaults(array( 'data_class' => 'AppBundle\Entity\User' )); } Podrías por favor indicarnos como poder hacer la corrección respectiva.

    Muchas gracias por tu ayuda.

    dmsagatha el 14 de mayo de 2015, 20:00:44

Este artículo ya no permite añadir más comentarios.
¿Por qué? Los artículos cierran sus comentarios automáticamente unos meses después de su publicación para asegurar que estos sigan siendo relevantes.

Publicada el

23 de abril de 2015

Etiquetas

Proyectos Symfony destacados

La forma más sencilla de generar el backend de tus aplicaciones Symfony. Ver más

Síguenos en @symfony_es para acceder a las últimas noticias.