Dans l'un de mes derniers projets, j'ai dû travailler avec les données de l'utilisateur, rentrait par ce dernier au momment de son inscription sur une appli Symfony2.
Le cas :
Un user s'inscrit sur le site en fournissant login, email, mot de passe. Je récupére le login et l'email pour générer un md5 (md5($login."".$email)), j'enregistre ce string en bdd pour une utilisation future.
Les moyens d'y arriver :
- - Surcharger le controller de FOSUserBundle.
Dans notre cas, cela revient à faire de " la bidouille " (avis purement personnel), donc je vais voir les autres solutions, si il y a pas quelques choses de mieux. - - Utiliser les événements déclenchés par FOSUserBundle.
Trés utile, mais vu la simplicité de notre cas, il y a peut être mieux et donc on garde les événements pour des besoins plus conséquents (log, envois de mail, etc). - - Utiliser les cycles de vie intégrer dans le framework .
Fait exactement ce que l'on cherche (comme de par hasard...). - - Ne pas toucher à l'application et créer un trigger qui le fera à la place.
C'est le mieux, mais on sort du framework et ce n'est pas le but de cet article.
Voyons donc comment utiliser les cycles de vie ou lifecycle.
Les cycles de vie / lifecycle :
Pour les liens, la doc, les infos voir bas de l'article.
On active le lifecyle sur notre entité quant on utilise les annotations (sinon voir les liens).
/**
* User
*
* [...]
* @ORM\HasLifecycleCallbacks()
*/
class User
{
// ...
}
Toujours dans l'entité User, on modifie le setter correspondant :
/**
* @ORM\PrePersist
*/
public function setFileName()
{
$this->fileName = md5($this->usernameCanonical."".$this->emailCanonical);
}
Et c'est tout! Désormais Doctrine se chargera automatiquement de nous créer le md5 en fonction des données de l'utilisateur et il le fera UNIQUEMENT à la création de l'user en ignorerant les updates.
La liste des callbacks de Doctrine :
- prePersist : Permet de faire quelque chose avant la création d'une entité. Ne donne pas accès à l'id de l'entité (normal rien n'est encore en bdd).
- postPersist : Permet de faire quelque chose après la création d'une entité. Accès à l'id de l'entité.
- preUpdate : Permet de faire quelque chose avant la modification (et non la création) d'une entité. Accès à l'id de l'entité.
- postUpdate : Permet de faire quelque chose après la modification (et non la création) d'une entité. Accès à l'id de l'entité.
preUpdate et postUpdate ne sont pas exécutés quant on passe par du DQL.
- preRemove : Permet de faire quelque chose avant la suppression d'une entité.
- postRemove : Permet de faire quelque chose après la suppression d'une entité.
Suivant ce que vous avez à faire, il est préférable de privilégier postRemove à preRemove. En effet si on supprime le dossier d'un utilisateur mais que le delete en bdd échoue, on se retrouve avec un dossier delete mais pas l'utilisateur correspondant...
preRemove et postRemove ne sont pas exécutés quant on passe par du DQL.
- postLoad : Permet de faire quelque chose au chargement (ou au refersh) d'une entité.
Attention, postLoad est un événements qui agit AVANT que les associations de l'entité ne soient chargées.
Utilisation des paramètres :
Comme vous pouvez le voir ma fonction setFileName n'utilise pas de paramètre, mais depuis la version 2.4 de Doctrine, il est possible d'en utiliser un qui donne accés à l' EntityManager et UnitOfWork :
Exemple de la doc officielle.
public function preUpdate(PreUpdateEventArgs $event)
{
//...
}
Pour aller plus loin :
- La doc officielle
- la liste des event doctrine (même ceux qui ne font pas parti des lifecycles)
