Nous allons voir l’utilisation de la classe sfFilter. Attention à ne pas confondre sfFilter et les classes auto-générés lors du build de l’application qui sont des classes principalement utilisées dans le backend pour faire le tri sur les colonnes.
Mais concentrons nous d’abord sur sfFilter. Comme on peut le voir en parcourant rapidement le code c’est une classe abstraite on ne pourra donc l’utiliser que part héritage.
Les filters sont en fait une couche du Framework qui permet d’effectuer des actions avant ou après l’affichage d’une page, ce qui peut s’avérer très pratique.
On va donc partir d’un exemple simple :
Imaginons deux sites internet, un site A qui va faire une redirection vers mon site B. Sur mon site B les utilisateurs peuvent s’inscrire et j’ai besoin de stocker le site de provenance, ce qui va se faire à l’aide d’un cookie.
Une méthode primaire pourrait consister à faire une page qui va poser le cookie et faire la redirection. Seulement le jour ou je souhaite que mon site A redirige vers une page précise de mon site B il va falloir que je vienne changer le code.
Heureusement sfFilter est là !
Grâce à cette couche du framework je vais pouvoir créer une classe que je vais appeler TrackerFilter et qui va me faire tout le traitement nécessaire. Voici le code :
class TrackerFilter extends sfFilter {
public function execute($filterChain) {
$context = $this->getContext();
$request = $context->getRequest();
if ($this->isFirstCall() && $request->getParameter('r'))
{
$user = $context->getUser();
if (!$request->getCookie('reservation'))
{
$time = time()+60*60*24*7;
$context->getResponse()->setCookie('reservation', $request->getParameter('r'), $time);
}
}
$filterChain->execute();
}
}
- Que se passe t’il dans ces quelques lignes de code ?
- Notre classe va hériter de sfFilter (obligatoire)
- On va créer une function execute avec en paramètre $filterchain qui va nous permettre d’exécuter le code souhaité (obligatoire)
- On récupère le “context” et le “request” ce qui va nous permettre de vérifier si le cookie existe déjà et de le poser dans le cas contraire
- On exécute le filter (obligatoire)
Quelques précisions supplémentaires :
La fonction isFirstCall() permet de vérifier si c’est la première exécution du filter.
Le placement de la ligne
$filterChain->execute();
a son importance puisqu’elle permet de signifier si l’on souhaite que le filter s’exécute avant ou après l’action.
Maintenant il ne nous reste plus qu’à configurer notre filter, pour cela il faut modifier le fichier apps/APPLICATION/config/filters.yml qui d’origine contient :
rendering: ~
security: ~
# insert your own filters here
cache: ~
common: ~
execution: ~
Ce qui semble assez explicite pour savoir ou écrire notre configuration. On va donc compléter ce fichier comme suit :
rendering: ~
security: ~
TrackerFilter:
class: TrackerFilter
cache: ~
common: ~
execution: ~
Nous avons donc vu comment utiliser les filters avec un cas pratique simple mais qui est un cas qu’un développeur web va rencontrer souvent. Cette façon de faire laisse donc une certaine flexibilité et permet une fois de plus d’avoir un code simple, clair et factorisé.
On trouve là tout la puissance de Symfony.
Pour ceux qui sont intéressés par d’autres cas d’utilisation de sfFilter vous pouvez bien sûr vous reportez sur le livre. Vous y verrez qu’il est possible grâce aux filters de faire des redirection, ou encore d’ajouter du code sur notre page.
partager
