A veces creamos relaciones en las entities para poder hacer consultas, por ejemplo, si tuviéramos una entidad User y otra Country y queremos obtener los usuarios de un país, lo que podemos hacer es añadir a la entidad Country un atributo $users y podemos hacer la consulta en DQL así:

SELECT u.name, c.name
FROM SMTCBundle:Country c
JOIN c.users u

A partir de la versión 2.3 de Doctrine, se puede hacer lo siguiente:

SELECT u.name, c.name
FROM SMTCBundle:Country c
JOIN SMTCBundle:User u WITH u.country = c.id

De esta forma no es necesario que Country tenga un atributo $users que sólo lo usamos para cuando hacemos consultas. Los Join se pueden usar tanto en DQL como con QueryBuilder.

day.desymfony.com

Podéis ver toda la información en la web del evento. Animaos y mandad vuestras propuestas de charla!!

Nos vemos en Barcelona!

Lo primero que haremos será crearnos una interfaz UserAware:

namespace SMTC\Bundle\MainBundle\Entity;

interface UserAware
{
    /**
     * Sets the user
     *
     * @param UserInterface|null $user A user instance or null
     */
    public function setUser(UserInterface $user = null);
}

Y la implementamos en las entities en las que guardamos el usuario, por ejemplo:

namespace SMTC\Bundle\MainBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * Training
 *
 * @ORM\Table(name="main_training")
 * @ORM\Entity
 */
class Training implements UserAware
{
    // ...

    /**
     * @ORM\ManyToOne(targetEntity="User")
     * @ORM\JoinColumn(name="user_id", referencedColumnName="id")
     */
    private $user;

    // ...

    public function setUser(UserInterface $user = null)
    {
        $this->user = $user;
    }
}

Ahora ya sólo nos queda la parte del listener de Doctrine. En el listener lo que haremos será mirar si la entidad que se va a persistir implementa la interfaz UserAware, en cuyo caso se le asignará el usuario de la sesión. Aquí hay un problema y es que no se puede crear un Listener de Doctrine e inyectarle el servicio security.context para recuperar al usuario porque nos da un error de dependencia circular. Una de las opciones es crearnos un servicio aparte del que podamos recuperar el usuario y este servicio será el que inyectemos al Listener de Doctrine. Vamos a usar la implementación que tienen en DoctrineBehaviours de esto:

namespace SMTC\Bundle\MainBundle\Doctrine;

use Symfony\Component\DependencyInjection\ContainerInterface;
use SMTC\Bundle\MainBundle\Entity\UserInterface;

/**
 * UserCallable can be invoked to return a blameable user
 * @see https://github.com/KnpLabs/DoctrineBehaviors/blob/master/src/Knp/DoctrineBehaviors/ORM/Blameable/UserCallable.php
 */
class UserCallable
{
    /**
     * @var ContainerInterface
     */
    private $container;

    public function __construct(ContainerInterface $container)
    {
        $this->container = $container;
    }

    public function __invoke()
    {
        $token = $this->container->get('security.context')->getToken();
        if (null !== $token) {
            return $token->getUser();
        }
    }
}

Y declaramos este servicio:

<!-- src/SMTC/Bundle/MainBundle/Resources/config/security.xml -->

<service id="smtc.security.user_callable" class="SMTC\Bundle\MainBundle\Security\UserCallable">
    <argument type="service" id="service_container" /> <!-- because of circular dep -->
</service>

Ahora ya podemos crear nuestro Listener en Doctrine:

<?php

namespace SMTC\Bundle\MainBundle\Doctrine;

use Doctrine\Common\EventSubscriber;
use Doctrine\ORM\Event\LifecycleEventArgs;
use Doctrine\ORM\Events;
use SMTC\Bundle\MainBundle\Entity\UserAware;

class UserSubscriber implements EventSubscriber
{
    protected $userCallable;

    public function __construct(callable $userCallable)
    {
        $this->userCallable = $userCallable;
    }

    /**
     * @param LifecycleEventArgs $args
     */
    public function prePersist(LifecycleEventArgs $args)
    {
        $object = $args->getEntity();
        if ($object instanceof UserAware) {
            $user = $this->getLoggedUser();
            $object->setUser($user);
        }
    }

    private function getLoggedUser()
    {
        $callable = $this->userCallable;
        $user = $callable();

        return $user;
    }

    public function getSubscribedEvents()
    {
        return array(
            Events::prePersist,
        );
    }
}

Y declararlo como servicio con el tag para que doctrine sepa que es un subscriber:

<!-- src/SMTC/Bundle/MainBundle/Resources/config/doctrine.xml -->

<service id="smtc.doctrine_subscriber.user_aware" class="SMTC\Bundle\MainBundle\Doctrine\UserSubscriber">
    <argument type="service" id="smtc.security.user_callable" />
    <tag name="doctrine.event_subscriber"/>
</service>

Ahora, cada vez que se persista una entidad que implemente la interfaz UserAware, se le asignará automáticamente el usuario de la sesión.

Lo primero que tenemos que tener bien configurado es la seguridad de la aplicación, esto está explicado en el manual de Symfony.

Desde el controlador, si extendemos de 

Symfony\Bundle\FrameworkBundle\Controller\Controller

use Symfony\Bundle\FrameworkBundle\Controller\Controller;

class UserController extends Controller
{
    public function showAction()
    {
        $user = $this->getUser();

        // ...
    {
}

Viendo el código de este método vamos a ver cómo podemos obtener el usuario en otros servicios:

public function getUser()
{
    if (!$this->container->has('security.context')) {
        throw new \LogicException('The SecurityBundle is not registered in your application.');
    }

    if (null === $token = $this->container->get('security.context')->getToken()) {
        return null;
    }

    if (!is_object($user = $token->getUser())) {
        return null;
    }

    return $user;
}

Para obtener el usuario hay que acceder al servicio security.context, de ahí obtener el token y de ahí obtener el usuario, es decir:

$user = $this->container->get('security.context')->getToken()->getUser();

Por lo que si desde un servicio queremos acceder al usuario, podemos inyectarle el servicio security.context y recuperarlo de ahí. Puede que según nuestra aplicación, necesitemos ejecutar o hacer comprobaciones cuando recuperamos el usuario, en ese caso se puede crear un servicio que sea el encargado de recuperar el usuario y hacer estas operaciones y será este servicio el que pasemos a los demás servicios para recuperar el usuario. Esto lo usaremos en uno de los próximos artículos.

Desde Twig podemos accedemos al usuario con:

{{ app.user }}

app es una variable global disponible en cualquier plantilla.

Desde un controller o servicio esta operación se hace también a través del security.context, lo que tenemos que hacer es comprobar si el usuario tiene un rol especial llamado IS_AUTHENTICATED_FULLY o IS_AUTHENTICATED_REMEMBERED:

use Symfony\Component\Security\Core\Exception\AccessDeniedException;

public function helloAction($name)
{
    if (false === $this->get('security.context')->isGranted('IS_AUTHENTICATED_FULLY')) {
        throw new AccessDeniedException();
    }

    // ...
}

¿Cuál es la diferencia? El rol IS_AUTHENTICATED_FULLY requiere que estés logueado en esa misma sesión, esto es útil por ejemplo cuando se quiere acceder al perfil del usuario para que cambie la contraseña. El rol IS_AUTHENTICATED_REMEMBERED permite que estés autenticado mediante la cookie de rembember-me.

En Twig se puede comprobar lo mismo con la función is_granted:

{% if is_granted('IS_AUTHENTICATED_FULLY') %}
    <a href="...">Delete</a>
{% endif %}

Partimos de esta configuración:

default:
    extensions:
        Behat\Symfony2Extension\Extension:
            mink_driver: true
            kernel:
                env: test
                debug: true
        Behat\MinkExtension\Extension:
            base_url: http://example.local/app_test.php
            default_session: symfony2
            browser_name: firefox
            javascript_session: selenium2
            selenium2: ~

Con el servidor de Selenium lanzado:

$ java -jar selenium-server-standalone-2.40.0.jar

Y ejecutamos behat:

$ bin/behat @AcmeBundle --config=app/config/behat.yml --tags=javascript

Con esta configuración los escenarios que están marcados con el tag @javascript se lanzarán con firefox. Para que se lancen con Chrome lo primero es cambiar browser_name a chrome.

default:
    extensions:
        Behat\Symfony2Extension\Extension:
            mink_driver: true
            kernel:
                env: test
                debug: true
        Behat\MinkExtension\Extension:
            base_url: http://example.local/app_test.php
            default_session: symfony2
            browser_name: chrome
            javascript_session: selenium2
            selenium2: ~

Si ahora lanzamos nuestros escenarios obtendremos el error:

Could not open connection: The path to the driver executable must be set by the webdriver.chrome.driver system property; for more information, see http://code.google.com/p/selenium/wiki/ChromeDriver. The latest version can be downloaded from http://chromedriver.storage.googleapis.com/index.html

Vamos a la página web que nos indica y nos bajamos la última versión del driver para nuestro sistema operativo. El fichero se llama chromedriver, ahora sólo falta añadir un parámetro a la ejecución del servidor de Selenium indicando la ruta al driver (si lo tenemos en el mismo directorio que Selenium no hace falta), de modo que ahora ejecutamos:

$ java -jar selenium-server-standalone-2.40.0.jar -Dwebdriver.chrome.driver=chromedriver

Y a partir de ahora ya podremos ejecutar los escenarios en Chrome.

Para acabar, cuando queremos mostrar la última respuesta con el step show last response en Mac, debemos añadir el parámetro show_cmd con el siguiente valor:

default:
    extensions:
        Behat\Symfony2Extension\Extension:
            mink_driver: true
            kernel:
                env: test
                debug: true
        Behat\MinkExtension\Extension:
            base_url: http://example.local/app_test.php
            default_session: symfony2
            browser_name: chrome
            javascript_session: selenium2
            selenium2: ~
            show_cmd: open -a Google\ Chrome %s

We are going to implement the typical Country, Province and City example:

Location is the model where we have the a City attribute:

namespace SMTC\MainBundle\Model;

use Symfony\Component\Validator\Constraints as Assert;

class Location
{
    /**
     * @Assert\NotBlank()
     */
    public $address;

    /**
     * @Assert\Type("SMTC\MainBundle\Entity\City")
     * @Assert\NotNull()
     */
    public $city;
}

Before we write the Form Type, we have to think about what we want to do. We want a Form Type with 4 fields, address will be a text field, city will be an entity field and the available choices will depend on the province field, this province will depend on country. When we have to add fields to a form which depend on other fields we have to use Form Events. Let’s see the implementation.

Our LocationType looks like this:

namespace SMTC\MainBundle\Form\Type;

use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\FormBuilderInterface;
use Symfony\Component\OptionsResolver\OptionsResolverInterface;
use SMTC\MainBundle\Form\EventListener\AddCityFieldSubscriber;
use SMTC\MainBundle\Form\EventListener\AddProvinceFieldSubscriber;
use SMTC\MainBundle\Form\EventListener\AddCountryFieldSubscriber;

class LocationType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $propertyPathToCity = 'city';

        $builder
            ->addEventSubscriber(new AddCityFieldSubscriber($propertyPathToCity))
            ->addEventSubscriber(new AddProvinceFieldSubscriber($propertyPathToCity))
            ->addEventSubscriber(new AddCountryFieldSubscriber($propertyPathToCity))
        ;

        $builder
            ->add('address', 'text', array(
                'label' => 'Calle'
            ))
        ;
    }

    public function setDefaultOptions(OptionsResolverInterface $resolver)
    {
        $resolver->setDefaults(array(
            'data_class' => 'SMTC\MainBundle\Model\Location'
        ));
    }

    public function getName()
    {
        return 'location';
    }
}

As we said before, we have used listeners that will add city, province and country dynamically. We will see the implementation later, but first, we have to understand how Form Events work. I highly recommend you to read the Symfony documentation about dynamic form.

So, which events do we have to listen to?

We can find two scenarios, the first one is when we have to modify the form based on the underlying data, that is when we have our form populated with our model. And the other one is when the form should change depending on the data sent from the user, that is when the form is populated with the submitted data.

So we need our listeners to listen to PRE_SET_DATA and PRE_SUBMIT events. These two events are called just before populating the form (PRE_SET_DATA with the model data and PRE_SUBMIT with the submitted data). Our AddCityFieldSubscriber looks like:

namespace SMTC\MainBundle\Form\EventListener;

use Symfony\Component\Form\FormEvent;
use Symfony\Component\Form\FormEvents;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\PropertyAccess\PropertyAccess;
use Doctrine\ORM\EntityRepository;
use SMTC\MainBundle\Entity\Province;
use SMTC\MainBundle\Entity\City;

class AddCityFieldSubscriber implements EventSubscriberInterface
{
    private $propertyPathToCity;

    public function __construct($propertyPathToCity)
    {
        $this->propertyPathToCity = $propertyPathToCity;
    }

    public static function getSubscribedEvents()
    {
        return array(
            FormEvents::PRE_SET_DATA  => 'preSetData',
            FormEvents::PRE_SUBMIT    => 'preSubmit'
        );
    }

    private function addCityForm($form, $province_id)
    {
        $formOptions = array(
            'class'         => 'MainBundle:City',
            'empty_value'   => 'Ciudad',
            'label'         => 'Ciudad',
            'attr'          => array(
                'class' => 'city_selector',
            ),
            'query_builder' => function (EntityRepository $repository) use ($province_id) {
                $qb = $repository->createQueryBuilder('city')
                    ->innerJoin('city.province', 'province')
                    ->where('province.id = :province')
                    ->setParameter('province', $province_id)
                ;

                return $qb;
            }
        );

        $form->add($this->propertyPathToCity, 'entity', $formOptions);
    }

    public function preSetData(FormEvent $event)
    {
        $data = $event->getData();
        $form = $event->getForm();

        if (null === $data) {
            return;
        }

        $accessor    = PropertyAccess::createPropertyAccessor();

        $city        = $accessor->getValue($data, $this->propertyPathToCity);
        $province_id = ($city) ? $city->getProvince()->getId() : null;

        $this->addCityForm($form, $province_id);
    }

    public function preSubmit(FormEvent $event)
    {
        $data = $event->getData();
        $form = $event->getForm();

        $province_id = array_key_exists('province', $data) ? $data['province'] : null;

        $this->addCityForm($form, $province_id);
    }
}

In the preSetData method, the data we receive is from the model, so it will be an instance of the model, Location in this case. We use PropertyAccess because in Location, city is a public attribute, but if we want to use this listener with an Entity for example, we would need to call

$data->getCity()

$data->city

In the preSubmit method we receive the data from the view as an array.

Finally, we add the city field and depending on the value of province, it should only display the cities associated with the selected province.

The AddProvinceFieldSubscriber looks like:

namespace SMTC\MainBundle\Form\EventListener;

use Symfony\Component\Form\FormEvent;
use Symfony\Component\Form\FormEvents;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\PropertyAccess\PropertyAccess;
use Doctrine\ORM\EntityRepository;
use SMTC\MainBundle\Entity\Country;

class AddProvinceFieldSubscriber implements EventSubscriberInterface
{
    private $propertyPathToCity;

    public function __construct($propertyPathToCity)
    {
        $this->propertyPathToCity = $propertyPathToCity;
    }

    public static function getSubscribedEvents()
    {
        return array(
            FormEvents::PRE_SET_DATA => 'preSetData',
            FormEvents::PRE_SUBMIT   => 'preSubmit'
        );
    }

    private function addProvinceForm($form, $country_id, $province = null)
    {
        $formOptions = array(
            'class'         => 'MainBundle:Province',
            'empty_value'   => 'Provincia',
            'label'         => 'Provincia',
            'mapped'        => false,
            'attr'          => array(
                'class' => 'province_selector',
            ),
            'query_builder' => function (EntityRepository $repository) use ($country_id) {
                $qb = $repository->createQueryBuilder('province')
                    ->innerJoin('province.country', 'country')
                    ->where('country.id = :country')
                    ->setParameter('country', $country_id)
                ;

                return $qb;
            }
        );

        if ($province) {
            $formOptions['data'] = $province;
        }

        $form->add('province','entity', $formOptions);
    }

    public function preSetData(FormEvent $event)
    {
        $data = $event->getData();
        $form = $event->getForm();

        if (null === $data) {
            return;
        }

        $accessor = PropertyAccess::getPropertyAccessor();

        $city        = $accessor->getValue($data, $this->propertyPathToCity);
        $province    = ($city) ? $city->getProvince() : null;
        $country_id  = ($province) ? $province->getCountry()->getId() : null;

        $this->addProvinceForm($form, $country_id, $province);
    }

    public function preSubmit(FormEvent $event)
    {
        $data = $event->getData();
        $form = $event->getForm();

        $country_id = array_key_exists('country', $data) ? $data['country'] : null;

        $this->addProvinceForm($form, $country_id);
    }
}

This is similar to the previous Listener, depending on the value of the Country, it displays the provinces associated with the selected Country. We don’t really want the province value in our model, so the mapped attributed is set to false and because of that, we need to pass the Province object to the addProvinceForm in order to show the selected province.

And finally AddCountryFieldSubscriber:

namespace SMTC\MainBundle\Form\EventListener;

use Symfony\Component\Form\FormEvent;
use Symfony\Component\Form\FormEvents;
use Symfony\Component\PropertyAccess\PropertyAccess;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Doctrine\ORM\EntityRepository;

class AddCountryFieldSubscriber implements EventSubscriberInterface
{
    private $propertyPathToCity;

    public function __construct($propertyPathToCity)
    {
        $this->propertyPathToCity = $propertyPathToCity;
    }

    public static function getSubscribedEvents()
    {
        return array(
            FormEvents::PRE_SET_DATA => 'preSetData',
            FormEvents::PRE_SUBMIT   => 'preSubmit'
        );
    }

    private function addCountryForm($form, $country = null)
    {
        $formOptions = array(
            'class'         => 'MainBundle:Country',
            'mapped'        => false,
            'label'         => 'País',
            'empty_value'   => 'País',
            'attr'          => array(
                'class' => 'country_selector',
            ),
        );

        if ($country) {
            $formOptions['data'] = $country;
        }

        $form->add('country', 'entity', $formOptions);
    }

    public function preSetData(FormEvent $event)
    {
        $data = $event->getData();
        $form = $event->getForm();

        if (null === $data) {
            return;
        }

        $accessor = PropertyAccess::getPropertyAccessor();

        $city    = $accessor->getValue($data, $this->propertyPathToCity);
        $country = ($city) ? $city->getProvince()->getCountry() : null;

        $this->addCountryForm($form, $country);
    }

    public function preSubmit(FormEvent $event)
    {
        $form = $event->getForm();

        $this->addCountryForm($form);
    }
}

It is like AddProvinceFieldSubscriber, but Country doesn’t depend on any field.

This would be what we need to do with forms. We will also need two actions in a controller to fetch the list of provinces associated to a country and the list of cities associated to a province.

/**
 * @Route("/provinces", name="select_provinces")
 */
public function provincesAction(Request $request)
{
    $country_id = $request->request->get('country_id');

    $em = $this->getDoctrine()->getManager();
    $provinces = $em->getRepository('MainBundle:Province')->findByCountryId($country_id);

    return new JsonResponse($provinces);
}

/**
 * @Route("/cities", name="select_cities")
 */
public function citiesAction(Request $request)
{
    $province_id = $request->request->get('province_id');

    $em = $this->getDoctrine()->getManager();
    $cities = $em->getRepository('MainBundle:City')->findByProvinceId($province_id);

    return new JsonResponse($cities);
}

And in the view we will need JavaScript for making those calls when one of the selects change, this would be an example of the JavaScript to update the cities select when the Province select changes:

$("#location_province").change(function(){
    var data = {
        province_id: $(this).val()
    };

    $.ajax({
        type: 'post',
        url: '{{ path("select_cities") }}',
        data: data,
        success: function(data) {
            var $city_selector = $('#location_city');

            $city_selector.html('<option>Ciudad</option>');

            for (var i=0, total = data.length; i < total; i++) {
                $city_selector.append('<option value="' + data[i].id + '">' + data[i].name + '</option>');
            }
        }
    });
});

You can see the fully working example (with the code) here:

Ver Demo

Cuando en una Entity, modelo, en un formulario o donde sea usamos Constraints como NotBlank, NotNull, Email, etc. Realmente, ¿qué está pasando? Lo que estamos indicando es que estamos asociando que un determinado campo o clase (según donde lo apliquemos) debe cumplir con ese Constraint. Y ¿dónde está el código que se ejecuta para estas comprobaciones? Dentro del componente Validator, están definidas estos Constraints.

Vamos a ver NotNull. Todos las Constraints están divididos en dos clases, por una parte tenemos el propio Constraint:

namespace Symfony\Component\Validator\Constraints;

use Symfony\Component\Validator\Constraint;

/**
 * @Annotation
 *
 * @author Bernhard Schussek <bschussek@gmail.com>
 *
 * @api
 */
class NotNull extends Constraint
{
    public $message = 'This value should not be null.';
}

Esta clase extiende de Constraint y aquí se definen las propiedades y configuración, en este caso el mensaje que aparecerá cuando no se cumpla. Destacar también la anotación Annotation que permite luego poder usar la clase en una anotación.

Por otra parte tenemos el Validator:

namespace Symfony\Component\Validator\Constraints;

use Symfony\Component\Validator\Constraint;
use Symfony\Component\Validator\ConstraintValidator;

/**
 * @author Bernhard Schussek <bschussek@gmail.com>
 *
 * @api
 */
class NotNullValidator extends ConstraintValidator
{
    /**
     * {@inheritDoc}
     */
    public function validate($value, Constraint $constraint)
    {
        if (null === $value) {
            $this->context->addViolation($constraint->message);
        }
    }
}

Esta clase es la que se va a encargar de tener la lógica de validación en el método validate, el cual recibe el valor a validar y la Constraint de configuración. A través del atributo context añadimos las violaciones en el caso que se produjeran.

¿Qué cosas podemos configurar de la clase Constraint?

Lo mejor es ver una ya hecha, vamos a usar de ejemplo el Constraint UniqueEntity:

use Symfony\Component\Validator\Constraint;

/**
 * Constraint for the Unique Entity validator
 *
 * @Annotation
 * @author Benjamin Eberlei <kontakt@beberlei.de>
 */
class UniqueEntity extends Constraint
{
    public $message = 'This value is already used.';
    public $service = 'doctrine.orm.validator.unique';
    public $em = null;
    public $repositoryMethod = 'findBy';
    public $fields = array();
    public $errorPath = null;
    public $ignoreNull = true;

    public function getRequiredOptions()
    {
        return array('fields');
    }

    /**
     * The validator must be defined as a service with this name.
     *
     * @return string
     */
    public function validatedBy()
    {
        return $this->service;
    }

    /**
     * {@inheritDoc}
     */
    public function getTargets()
    {
        return self::CLASS_CONSTRAINT;
    }

    public function getDefaultOption()
    {
        return 'fields';
    }
}

Lo primero que salta a la vista, es que podemos añadirle atributos públicos. Estos atributos contienen información sobre la configuración que usaremos en el Validator y los podemos sobrescribir cuando instanciamos el Constraint:

namespace Acme\AdministrationBundle\Entity;

use Doctrine\ORM\Mapping as ORM;
use Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity;

/**
 * @ORM\Entity
 * @UniqueEntity(
 *     fields={"host", "port"},
 *     errorPath="port",
 *     message="This port is already in use on that host."
 * )
 */
class Service
{
    /**
     * @ORM\ManyToOne(targetEntity="Host")
     */
    public $host;

    /**
     * @ORM\Column(type="integer")
     */
    public $port;
}

Otra cosa importante que podemos configurar es el target con el método getTargets, la Constraint puede afectar a una propiedad, un método o una clase entera, en el caso de la propiedad, a la hora de validar sólo tendremos acceso al valor que contiene. Si indicamos, como en el caso de UniqueEntity que el Target es la clase, tendremos acceso a una instancia de esa clase en el Validator, por lo que podemos acceder a los métodos o atributos públicos que tenga:

public function getTargets()
{
    return self::CLASS_CONSTRAINT;
}

Por otra parte podemos indicar qué campos son los requeridos:

public function getRequiredOptions()
{
    return array('fields');
}

Y cuál es el campo por defecto si sólo nos envían un parámetro de configuración:

public function getDefaultOption()
{
    return 'fields';
}

Por lo que si añadimos el Constraint así:

/**
 * @ORM\Entity
 * @UniqueEntity("email")
 */
class Author

Es como si lo indicáramos así:

/**
 * @ORM\Entity
 * @UniqueEntity(fields={"email"})
 */
class Author

También podemos indicar el groups como en todas las constraints y finalmente tenemos el método validatedBy que indica cuál va a ser el Validator asociado. Por defecto es una clase que se llama igual que el Constraint + Validator:

public function validatedBy()
{
    return get_class($this).'Validator';
}

Cuando creamos un Validator al que le debemos inyectar algunas dependencias, tendremos que declarar el Validator como servicio y tendremos que añadirle el tag validator.constraint_validator y un alias que será el mismo nombre que el método validatedBy deberá devolver, que es justo que lo hace UniqueEntity.

<service id="doctrine.orm.validator.unique" class="%doctrine.orm.validator.unique.class%">
    <tag name="validator.constraint_validator" alias="doctrine.orm.validator.unique" />
    <argument type="service" id="doctrine" />
</service>

En la documentación oficial podéis encontrar cómo crear un Custom Validator.

Las consultas con fetch-join son aquellas que además de hacer el join, en el resultado devolvemos la entidad relacionada, es decir:

$query = $em->createQuery("SELECT u, a FROM User u JOIN u.address a WHERE a.city = 'Berlin'");
$users = $query->getResult();

Con esto hacemos que con sólo una consulta, podamos recuperamos los usuarios y sus direcciones sin tener que hacer consultas extra. El problema está cuando queremos limitar el número de resultados:

If your query contains a fetch-joined collection specifying the result limit methods are not working as you would expect. Set Max Results restricts the number of database result rows, however in the case of fetch-joined collections one root entity might appear in many rows, effectively hydrating less than the specified number of results.

Para esto, podemos usar la clase Paginator como indica la documentación:

use Doctrine\ORM\Tools\Pagination\Paginator;

$dql = "SELECT p, c FROM BlogPost p JOIN p.comments c";
$query = $entityManager->createQuery($dql)
                       ->setFirstResult(0)
                       ->setMaxResults(100);

$paginator = new Paginator($query, $fetchJoinCollection = true);

$c = count($paginator);
foreach ($paginator as $post) {
    echo $post->getHeadline() . "\n";
}

También hay veces que en proyectos siempre vamos a paginar cosas como la que acabamos de ver, para este tipo de cosas no hace falta usar bundles que paginen por cualquier cosa. Con la clase Paginator podemos hacer algo así:

use Doctrine\ORM\Tools\Pagination\Paginator;

function paginate($dql, $pageSize = 10, $currentPage = 1)
{
    $paginator = new Paginator($dql);

    $paginator
        ->getQuery()
        ->setFirstResult($pageSize * ($currentPage - 1)) // set the offset
        ->setMaxResults($pageSize); // set the limit

    return $paginator;
}

Y si queremos ver el número total de items y de páginas:

$totalItems = count($paginator);
$pagesCount = ceil($totalItems / $paginator->getMaxResults());

Hay mucha gente que usa el framework Symfony2, pero que desconoce una de las cosas más importantes que tiene y eso son los componentes que podemos usar por separado. No hace falta que usemos todo el framework cuando a veces sólo nos hace falta cierta funcionalidad que podemos cubrir con alguno o varios componentes.

En este caso vamos a ver unos ejemplos con el componente Finder. Este componente a mí particularmente me gusta mucho por la interfaz tan intuitiva que tiene.

El ejemplo que vi era listar los ficheros en un directorio recursivamente, ahora mismo no recuerdo cuántas líneas tenía, pero seguramente serían más de 25 líneas de código. Con Finder si queremos listar los ficheros se haría así:

use Symfony\Component\Finder\Finder;

$path = __DIR__;

$finder = new Finder();
$finder->files()->in($ruta);

foreach ($finder as $file) {
    print $file->getRelativePathname() . "\n";
}

Este era el ejemplo más sencillo, pero Finder nos proporciona una gran cantidad de métodos para configurar la búsqueda, como este ejemplo sacado de la documentación en el que podemos ver todo el potencial:

use Symfony\Component\Finder\Finder;

$s3 = new \Zend_Service_Amazon_S3($key, $secret);
$s3->registerStreamWrapper("s3");

$finder = new Finder();
$finder->name('photos*')->size('< 100K')->date('since 1 hour ago');
foreach ($finder->in('s3://bucket-name') as $file) {
    // ... do something

    print $file->getFilename()."\n";
}

Como podemos ver, en vez de buscar en local, está buscando en Amazon S3 y lo que está buscando son ficheros cuyo nombre empiece por photos, con un tamaño menor a 100K y que la fecha de modificación sea desde hace 1 hora.

Hacer todo esto en PHP plano nos llevaría mucho tiempo y con el componente Finder lo podemos resolver de una forma muy elegante y en muy poco tiempo.

Para acabar vamos a ver unos cuantos ejemplos más sacados de la documentación.

$finder->in('src/Symfony/*/*/Resources');

$finder->in(__DIR__)->exclude('bin');

$finder->ignoreUnreadableDirs()->in(__DIR__);

$finder->in('ftp://example.com/pub/');

$finder->sortByType();

Lo mejor de estos ejemplos es que no hace falta explicarlos porque se leen perfectamente.

Échale un vistazo a la documentación para ver todas las posibilidades.

homepage:
    path:     /
    host:     "{_locale}.example.com"
    defaults:
        _controller: AcmeDemoBundle:Main:homepage
    requirements:
        _locale: en|fr|de

En este caso, se recomienda añadir otro placeholder para el dominio:

homepage:
    path:     /
    host:     "{_locale}.{domain}"
    defaults:
        _controller: AcmeDemoBundle:Main:homepage
        domain: %domain%
    requirements:
        _locale: %locales%
        domain: "%domain%"

Ahora sólo nos queda definir el parámetro domain (y locales) en nuestra configuración. Esto nos va a permitir cuando estamos trabajando en local definir el dominio por ejemplo a example.local y en producción tenerlo como example.com.

También podemos indicar el host cuando importamos la ruta:

# app/config/routing.yml
acme_hello:
    resource: "@AcmeHelloBundle/Resources/config/routing.yml"
    host:     "{_locale}.{domain}"
    defaults:
        domain: %domain%
    requirements:
        _locale: %locales%
        domain: "%domain%"

Una alternativa a esto sería crear un Listener que nada más llegar la petición, obtuviera el subdominio y desde ahí configuraríamos el locale y lo que nos hiciera falta.