Archives de l’auteur : Claymm

Pense bête : Gestion des erreurs avec les formulaires imbriqués sous Symfony 2.1

Publié le par
2

Lorsqu’on met en place des formulaires imbriqués avec Symfony 2.1 il ne faut pas oublier que la gestion des formulaires à légèrement été revue entre la version 2.0 et les versions 2.x, comme expliqué dans la notice prévue UPGRADE FROM 2.0 to 2.1.

Il ne faut également pas oublier de consulter la documentation Symfony officielle expliquant le fonctionnement et la mise en place des formulaires imbriqués.

Au sujet des erreurs sur les formulaire imbriqué, cette dernière nous expose comment « faire remonter » les erreurs propres au premier formulaire imbriqué dans le second. Il ne faut pas oublier de préciser au formulaire qui reçoit le premier, qu’il va devoir récupérer des erreurs autres que les siennes en précisant dans la méthode setDefaultOptions() de votre Form comme ceci :

namespace Acme\Bundle\AcmeBundle\Form;

class MyEntityType extends AbstractType
{
    public buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder->add('myotherentity', new MyOtherEntityType());
    }

    public function setDefaultOptions(OptionsResolverInterface $resolver)
    {
        $resolver->setDefaults(array(
            'data_class' => 'Acme\Bundle\AcmeBundle\Entity\MyEntity',
            'cascade_validation' => true
        ));
    }

    ...
}

Le tout couplé avec vos « Assert » sur les champs de vos entitées et une vue exposant correctement les erreurs de vos formulaires comblera la plupart de vos besoins.

Twig : Comment créer facilement et simplement votre propre filter

Publié le par
4

Les filters Twig sont très utiles lors des développements d’interfaces. Vous ne pouvez pas le nier, vous les utilisez tous les jours et je suis sûr que vous aimez ça :)

Twig vient avec tout un tas de filters plus utiles les uns que les autres, je vous invite à consulter cette liste complète des filters par défaut.

Vous pouvez également installer des filters en plus de ceux par défauts comme par exemple les quelques filters que Fabien Potencier a regroupé dans un repository Github appelé « Twig-extensions » et que nous vous recommandons. Installez facilement grâce à Composer et vous pourrez par exemple utiliser les filters debug (équivalent d’un var_dump() depuis une vue Twig), des filters relatifs à la manipulation de chaines de caractères comme avec le filter truncate ou encore des filters vous donnant la possibilité d’internationaliser vos vues.

Les filters par défaut et ceux de Fabien Potencier répondent aux besoins de la majorité des développements mais qu’en est-il si vous vous rendez compte qu’aucun des filters que vous connaissez ne réponde à un besoin particulier que vous exprimez ? Rien de plus simple, créez-le ! C’est ce que nous allons voir ici.

Pour commencer, vous devez créer un dossier Twig dans lequel vous créerez un autre dossier Extension à la racine de votre Bundle. Lorsque c’est chose faite, créez dans ce dernier dossier un fichier portant le nom de votre extension Twig comme par exemple MyfilterExtension.php. Voici ensuite ce que vous devrez au moins avoir dans ce fichier :

namespace Acme\Bundle\AcmeBundle\Twig\Extension;

class MyfilterExtension extends \Twig_Extension
{
    public function getFilters()
    {
        return array(
            'myfilter' => new \Twig_Filter_Method($this, 'doSomething')
        );
    }

    public function doSomething($value)
    {
        return 'transformated-' . $value;
    }

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

}

Ce que fait ce filter est très simple, à chaque fois que vous utiliserez dans votre vue Twig le mot clef myfilter, il ajoutera la chaine ‘transformated-’ devant la valeur de la chaine sur laquelle vous être en train d’appliquer votre filter, par exemple :

{{ 'value' }}

Affichera la chaîne de caractère value en tant que telle dans votre vue.

{{ 'value' | myfilter }}

Affichera la chaîne de caractère transformated-value dans votre vue.
Je vous laisse imaginer toutes les possibilités que vous pouvez développer avec ça ! :)

Une fois votre classe terminée, vous n’avez plus qu’à la déclarer dans votre services.xml afin d’injecter votre classe et de pouvoir l’utiliser.

...
<services>
    ...
    <service id="acme.twig.myfilter_extension" class="Acme\Bundle\AcmeBundle\Twig\Extension\MyfilterExtension"> 
        <tag name="twig.extension" />
    </service>
    ...
</services>
...

Un point intéressant consiste à donner la possibilité à votre filter d’accepter des paramètres depuis la vue Twig, en plus de la valeur (ou l’objet) sur lequel vous voulez effectuer un traitement. On pourrait imaginer par exemple un appel à notre filter suivant :

{{ 'value' | myfilter('rockin') }}

Et avoir une méthode doSomething() acceptant cette fois-ci un deuxième paramètre.

public function doSomething($value, $parameter)
{
    return 'transformated-' . $value . '-' . $parameter;
}

ce qui nous retournerais, en gardant notre exemple précédent, la chaîne transformated-value-rockin.

Bien sûr, ce n’est ici qu’une application simple, d’autres utilisations plus poussées des filters peuvent être faites comme par exemple passer un manager en paramètre à votre classe lors de l’injection pour pouvoir effectuer du traitement lié à des entités ou autre.

Utiliser un Validator dans un Form\Type Symfony2

Publié le par
10

Vous avez sûrement déjà dû utiliser des fonctions de validation appelées en callback sur vos formulaires (CallbackValidator) pour tester un retour de formulaire et lever une erreur sur un certain champs si la valeur de ce dernier n’est pas valide.

public function buildForm(FormBuilder $builder, array $options)
{
    $builder->add('myfield', 'text');
    $builder->addValidator(new CallbackValidator(function(FormInterface $form) {
    $myfield = $form->get('myfield');
    if ($myfield->getData() != null && !is_string($myfield->getData())) {
        $myfield->addError(new FormError('Invalid format'));
    }
}

Et bien sachez que vous pouvez utiliser dans vos Form/Type des Validator (à l’instar de ceux qu’on peut invoquer en utilisant les Assert dans nos entitées) qui vont pouvoir vous apporter un nombre important d’outils qui vont vous aider à valider vos formulaires.

Tout d’abord, il vous faudra utiliser les namespace de classes suivants :

<?php
namespace Acme\Bundle\AcmeBundle\Form\Type;

use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\FormBuilder;
use Symfony\Component\Form\CallbackValidator;
use Symfony\Component\Form\FormInterface;
use Symfony\Component\Form\FormError;
use Symfony\Component\Validator\Constraints\Regex;
use Symfony\Component\Validator\Constraints\RegexValidator;

class FooType extends AbstractType
{
    [...]
}

Les deux derniers sont ceux que nous devons rajouter pour pouvoir utiliser cette contrainte de validation. Ici nous avons choisit la validation de Regex mais vous pouvez utiliser n’importe quel type de contrainte tant qu’elle possède une classe Validator associée. (cf. liste des toutes les contraintes)

Il vous suffira désormais de juste instancier de nouveaux objets dans votre CallbackValidator afin de pouvoir analyser et valider une valeur.

[...]
public function buildForm(FormBuilder $builder, array $options)
{
    $builder->add('myfield', 'text');
    $builder->addValidator(new CallbackValidator(function(FormInterface $form) {
    $myfield = $form->get('myfield');
    if ( ! is_null($myfield->getData()) ) {
        $validator      = new RegexValidator();
        $constraint     = new Regex(array(
            'pattern' => "/^[a-z0-9-]+$/"
        ));
        $isValid = $validator->validate( $myfield->getData(), $constraint );
        if ( ! $isValid ) {
            $myfield->addError( new FormError( "This field is not valid (only alphanumeric characters separated by hyphens)" ) );
        }
    }
}
[...]

Voilà une astuce bien sympathique qui peut vous être utile à valider un champs qui, par exemple, ne figure pas dans les attributs de votre entitée. Exactement comme vous pourriez le faire en utilisant les validations de type Assert.