Discussion :

[mixka13]

Bonsoir,

Je voudrais savoir comment je pourrais surcharger l'action executeSignin de la classe BasesfGuardAuthActions, en effet cette dernière redirige toujours sur la route @homepage, or je voudrais que la redirection soit conditionnelle, et pour cela je ne vois que la surcharge de cette action pour modifier son comportement à ma guise mais je n'y parviens pas.

De plus m'est-il possible d'utiliser une autre table que la table mise en place par le plugin sfGuardDoctrine pour gérer mes utilisateurs ??
Sinon comment puis-je modifier cette derniere pour qu'elle accueille plus d'informations sans modifier le schema.yml du plugin.

Merci de votre aide.

cordialement Mickael

[Michel Rotta]

Tu peux modifier la redirection à l'aide de paramètre et envoyer sur une autre page que home. Cependant cette redirection est statique dans tous les cas.

D'une manière générale, ce qui se trouve dans ton dossier lib/ est prioritaire sur le reste (pour l'autoload). Tu peux donc créer un dossier lib/plugins/sfDoctrineGuardPlugin/... et y mettre une copie du fichier en question, que tu modifiera. Ainsi tu peux avoir le comportement voulu. Par contre, tu te trouves à la merci de n'importe quel mise à jour et risque d'avoir à développer cette partie.

Je pense que la meilleur solution serait de modifier la configuration du plugin (sans le modifier) pour renvoyer sur une action qui n'aurait pour seul objet que de rediriger vers la bonne page. Ainsi, plus de modification du plugin et arrivée dynamique.


Doctrine accepte la surcharge des tables par héritage. C'est parfaitement réalisable avec la table sfGuardUser.

[mixka13]

Je pense que la meilleur solution serait de modifier la configuration du plugin (sans le modifier) pour renvoyer sur une action qui n'aurait pour seul objet que de rediriger vers la bonne page. Ainsi, plus de modification du plugin et arrivée dynamique.

Je ne comprend pas vraiment cette méthode, en tout cas comment la mettre en place.

Quant à la surcharge de ma table, cela s'effectue bien au niveau du schéma YML, la manipulation des objets doctrine restera la même dans symfony ( je veux dire sauvegarde, utilisation des formulaires, etc )

[Michel Rotta]

Lis le fichier readme du plugin.

A la fin du fichier tu vois comment définir deux routes :

Code :

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

1
2
3
4
5
 
all:
  sf_guard_plugin:
    success_signin_url:      @my_route?param=value # the plugin use the referer as default
    success_signout_url:     module/action         # the plugin use the referer as default

Tu définis la route après le signin :

• soit sur l'action (toujours la même) qui va suivre le signin (affichage d'un écran).
• soit sur l'action (toujours la même) qui va traiter le retour du signin où tu pourras en fonction d'informations qui te sont propre, rediriger vers ce qui te convient.

Maintenant, si tu veux plus d'informations sur comment faire, il faudra expliquer comment tu veux rediriger vers quoi.


Tu as la documentation sur l'héritage ici.
Utilise un héritage de type Column agregation.

[mixka13]

Merci beaucoup pour ton aide rapide et précieuse, j'avais oublié cette hyper-configurabilité de symfony qui permet de tout faire (ou presque )
Je n'aurais donc qu'a créer une route acceptant un ou des paramètres, la placer an paramètre de success_signin_url et ensuite un action spécifique va traiter cette requête pour me rediriger sur un page donnée suivant le contexte.

Pour l'héritage j'avais retrouvé cette page avant ta réponse, et je me pose la question suivante :

Je ne peux pas faire hérité la table sf_guard_user de ma table perso d'utilisateurs car cela reviendrais a modifier le plugin, et l'inverse et inutile puisque cela sera toujours la table inchangée sf_guard_user qui sera utilisée
Il y a un truc qui m'échappe donc sur la méthode (encore une fois )

De plus qu'elle est la différence entre héritance "simple" et Column agregation. (désolé, j'ai un peu de mal a saisir)

[Michel Rotta]

Pour le routage, oui mais. "Mais" parce que tu ne pourras passer d'informations par la route. Il faut donc les passer par un autre système. Probablement des informations dans l'objet myUser qui représente la session.

Dans le cadre d'un héritage simple la table contiens toutes les colonnes crée pour chaque enregistrement et il n'est pas possible de savoir, pour un enregistrement donné de quel classe il dépend.

Dans le cadre d'une colone agrégation, il y a un champ de plus qui est créé et qui permet de savoir la classe de l’enregistrement.

Si tu n'as qu'un héritage, c'est la même chose. J'utilise colunm agregate par habitue probablement.

Je ne vois pas trop le problème entre tes différentes tables. Le principe est de rajouter des champs à la table. Je ne vois pas pourquoi le fait que la table sfGuardUser soit étendue et non pas qu'elle étende puisse changer quelque chose.