#philippe.breucker

On a tous eu le problème (oui, nous, les développeurs d’application web) : gérer les utilisateurs ! Ajout, suppression, modification, inscription, validation, profil, et j’en passe.
Donc je vous livre ici une petite expérience avec sfDoctrineGuardPlugin et sfForkedDoctrineApplyPlugin, deux plugins symfony 1.4 que j’ai utilisé pour me créer mon petit gestionnaire de profil personnalisé.Pour faire simple, voici le scénario à tester :

•  installer symfony 1.4 : jusque là rien de sorcier
•  installer sfDoctrineGuardPlugin, qui permet de gérer les utilisateurs à partir de Doctrine
• installer sfForkedDoctrineApplyPlugin qui permet l’ajout de fonctions du type « register », confirmation d’email, etc., et de gérer un profil utilisateur
• configurer ce dernier en ajoutant des champs dans votre schema.yml (voir la doc du plugin)
• générer les modules admin (et l’application backend si ce n’est déjà fait) pour sfGuardUser
• refaire les build des classes avec symfony doctrine:build –all-classes
• configurer les routes si besoin est
• effacer le cache

A la suite de quoi, vous croyez, tout content, pouvoir générer les modules admin generator avec les champs supplémentaires : eh bien non ! Ca serait trop simple !

En gros, et pour faire simple, le forkedPlugin ajoute une table pour gérer les profile : sfGuardUserProfile, et on ne peut pas facilement changer ça. Donc on se retrouve avec deux tables (sfGuardUser et sfGuardUserProfile) séparées (reliée quand même par une relation 1:1, heureusement), pour gérer les utilisateurs ! Seulement votre admin, lui, il aimerait (et on le comprend), éditer les utilisateurs dans son admin generator en un seul formulaire !

La solution (pas belle, mais j’ai pas trouvé mieux…) :

1. ajouter la relation « Profile » au schéma de sfDoctrineGuardPlugin :

   • <sf_root>/plugins/sfDoctrineGuardPlugin/config/doctrine/schema.yml

   •  Profile: class: sfGuardUserProfile foreign: user_id local: id type: one onDelete: cascade foreignType: one foreignAlias: User

2. copier le fichier de définition du formulaire admin

   • cp <sf_root>/plugins/sfDoctrineGuardPlugin/lib/form/doctrine/sfGuardUserAdminForm.class.php <sf_root>/lib/form/doctrine/sfDoctrineGuardPlugin 

3. ouvrir le fichier, dans la fonction configure(), ajouter la commande magique  $this->embedRelation(« Profile »)
4. créer ou modifier le fichier de config pour l’admin generator pour qu’il prenne en compte le widget ‘Profile’ :

   •  <sf_root>/apps/backend/modules/sfGuardUser/config/generator.yml

   • Voici le mien, mais c’est un exemple :

      generator: class: sfDoctrineGenerator param: model_class: sfGuardUser theme: admin non_verbose_templates: true with_show: false singular: ~ plural: ~ route_prefix: sf_guard_user with_doctrine_route: true config: fields: password_again: { label: "Password (again)" } list: title: User list display: [=username, created_at, updated_at, last_login] form: class: sfGuardUserAdminForm display: "User": [email_address, username, password, password_again] "Profile": [Profile] "Permissions and groups": [is_active, is_super_admin, groups_list, permissions_list] edit: title: Editing User "%%username%%" new: title: New User 

     Remarquez le « Profile » : [Profile] qui insère le sous-formulaire basé sur la relation 1:1 dans le formulaire. Vous pouvez bien-sûr définir des validateurs, et configurer les champs dans le fichier de configuration du formulaire de profil (celui de sfForked) :
     

     <sf_root>/lib/form/doctrine/sfForkedDoctrineApplyPlugin/sfGuardUserProfileForm.class.php