Dans cet article nous allons voir comment facilement valider un formulaire Symfony via les sfEvent.

Il existe de nombreuses méthodes pour valider ses formulaires en Javascript, mais celle que j’apprécie consiste à passer des données à la sémantique HTML des éléments de formulaire pour indiquer au javascript qu’elles sont les conditions à valider. En d’autres termes cela revient par exemple à renseigner un attribut class avec des valeurs telles que required ou encore email, etc. ou encore via un JSON toujours placé dans l’attribut class, récupéré ensuite grâce à jquery.metadata.

VanadiumJS, une librairie jQuery, est basée sur ce principe, elle ajoute une couche de validation javascript via des classes CSS de type :required, etc. Malheureusement elle souffre de quelques défauts, notamment l’I18N. Le jQuery plugin validation permet également de valider sous cette forme, il permet aussi une écriture des règles en javascript, hors de la sémantique HTML.

Le code ci-dessous a été testé avec ces 2 librairies Javascript. J’ai choisi de vous présenter le code correspondant à la librairie jQuery plugin validation car je la considère plus pérenne et elle gère l’I18N.

Autant pendant un temps ils n’avaient plus la côte, autant ces derniers mois je trouve qu’on lit trop d’articles sur les hacks CSS pour IE…

Que ce soit ici ou là ou encore là, on lit les louanges des * html et autres *+html, _ ou encore pire avec l’utilisation de \9… mais wtf?!

Le principal problème lié à l’utilisation d’un hack CSS, c’est que son périmètre d’application n’est pas maîtrisé, étant donné qu’il exploite une faille, son comportement futur ne peut pas être contrôlé…

Dans cet article nous allons voir comment accéder à des données dynamiques provenant de symfony, en Javascript. Pour quelle raison ? Car il est parfois nécessaire depuis JS d’avoir à accéder à des données telles que : de l’i18n, des URLs générés à partir du routing, la culture de l’utilisateur, etc.

I18n pour le titre d’une modalbox par exemple, dont le site serait internationalisé. URLs pour des appels Ajax, où il est déconseillé de recopier l’URL en dur dans le fichier JS… Et la culture pour bien configurer certains JS qui proposent des fichiers de traductions.

Lorsque l’on développe des tests fonctionnels en symfony avec lime, on se rend compte du lien fort qu’il y à la fois entre la sémantique HTML et les tests mais également entre les URLs et les tests. Voici un exemple :

$browser->get('/category/index');

Utiliser des URL comme celle-ci dans les tests fonctionnels peut être handicapant si en fin de projet votre client demande une optimisation des URLs. Vous allez probablement retravailler votre routing en conséquence. Et dès lors une bonne part de vos tests fonctionnels risquent de ne plus fonctionner. Alors, pourquoi ne pas tout simplement utiliser des routes dans vos tests fonctionnels ? D’autant plus que le routing.yml référence l’intégralité des URLs de votre application, ce serait dommage de s’en priver !