Discussion :

[bilbonec]

Tu n'es pas obligé de lier un module à un modèle de données. Cette restriction prévaut pour les modules générés grâce à l'admin-generator, mais pas aux autres.

Un module est un ensemble d'actions qui sont souvent liés à tes modèles de données, mais pas exclusivement.

Tu as une tâche Symfony :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

php symfony generate:module backend sfGuardUser

qui te permet de construire automatiquement l'arborescence de ton module.

Il te suffit ensuite d'ajouter ton action. Pour info, je tenterais bien de faire étendre ta classe d'action de celle utilisée dans le plugin, mais je ne garantis pas le résultat

[mantex]

OK merci j' ai compris le principe.

Je vais maintenant m' attaque à mon autre problème de fond.

Comment gérer les 3 niveaux de user dans mon shéma:

http://www.developpez.net/forums/d97...s-utilisateur/

[Michel Rotta]

Juste un point sur les méthodes du sfGuard.

Certaines informations sont stockée, lors du login, dans l'objet myUser, que l'on aura pris la peine de faire hériter de sfGuardSecurityUser.

On peut directement récupérer les informations :
->getUsername()
->getName()
->getEmail()

Donc la syntaxe :
$this->getUser()->getUsername()
permet de récupérer le nom de login de l'utilisateur. Cepandant, ce sont des shunt de la méthode complète qui est :
$this->getUser()->getGuardUser()->getUserName.
Cette méthode implique la récupération de l'objet du modèle sfGuardUser (en effet, ->getGuardUser() retourne un pointeur vers un objet du modèle), insidieusement, cela génère une requête SQL pour récupérer l'objet du modèle qui correspond à l'utilisateur courant. Vu que sfGuard est bien écris, l'objet user est alors stocké dans l'objet myUser et les demande suivante ne passeront plus par tu SQL. La triologie de demande ci-dessus décrite ne générera qu'une requête SQL. Du moins pour l'instance. Lors de la requête suivante, il y aura de nouveau une requête.

Il peut être intéressant d'utiliser le AttributHolder de l'objet sfBAsicSecurityUser (hérité du lointain objet sfUser à la base de l'arbre d'héritage), disponible dans le sfGuardSecurityUser pour y stocker des informations très régulièrement utilisée, ce en modifiant le myUser et notamment la méthode signIn. Attention à stocker vos information dans l'espace de nom 'sfGuardSecurityUser', qu'elle soient supprimées lors du logout de l'utilisateur.

Pour récupérer l'Id de l'utilisateur, il est possible de le faire sans avoir à générer une requête par :
$this->getUser()->getAttribute('user_id', null, 'sfGuardSecurityUser')

Les modifications, suivant le cas, peuvent être apportées au myUser ou aux objets du modèle en charge de récupérer les données.

Je ne vois pas le problème de gestion des trois types d'utilisateurs, avec les objets et les héritages, tu peux facilement créer les méthodes nécessaires dans les différents niveaux des objets du modèles. Regarde bien l'ordre d'héritages des différents objets du modèle, tu va voir que les objet hérités voient leur code être enfant du modèle sfGuarUser, il est donc possible de définir des méthodes pour les trois (dans le sfGuardUser) où pour chaque objet individuellement.