Discussion :

[etoileweb]

Bonjour, j'ai déjà une table "membre" dans mon modèle, qui est en relation avec beaucoup d'autres table, par exemple la table "news" contenant un champ "member_id" pour identifier l'auteur de la news. Or il se trouve que pour gérer les utilisateurs, les groupes et les permissions, je dois installer sfDoctrineGuardPlugin. Ma question est de savoir s'il est possible de réaliser une liaison entre ma table membre et sfUser afin de procéder ainsi par des leftJoin au besoin. Sinon je suis embarrasser de savoir comment établir une liaison en sfUser et les autres tables de mon modèle qui ont un champ member_id, étant donné que la création du modèle précède l'installation du plugin. Si vous avez des idées, merci de me les donner.

[Michel Rotta]

Je ne suis pas sur de comprendre tous les problèmes que tu présupposes.

Tu peux parfaitement créer un champ sfUser_id dans ta table membre et mettre en place une liaison 1-1 entre les deux.

Tu peux modifier l'objet sfUser (après avoir modifier son parent pour prendre en compte les méthodes apportées par sfGuard) et créer tes propres méthodes. Attention, si tu modifie une méthode existante à ce quel retourne des données viables. Attention, l'objet sfUser ne fait pas partie du modèle, il n'est donc jamais utilisé dans une requête doctrine, j'ai l'impression que tu fais un peu de confusion sur ce point là.

Une autre solution serait de créer une table héritant de sfUser et d'y apporter les champs de ta table membre. Si ton modèle est conforme aux préconisations de nommage et que le champ primaire de toutes tes tables s'appelle systématiquement "id", ta table membre hérité de sfUser aura un champ membre.id (identique au champ sfUser.id) qui ne devrait, en rien, changer tes relation. Tu aurais alors une seule table sfUser étendue en membre et deux modèle objet (doctrine) pour y accéder. C'est la solution que j'utiliserais.

[etoileweb]

Merci Michou. Moi je suis débutant avec symphony (et même avec la POO en PHP) et tes explications on l'air un peu trop "technique" pour moi. mais comme tu ne comprend pas bien mon problème je le reformule le plus simplement possible. J'ai prévu la table membre pour permettre aux utilisateurs de créer un compte. La table membre est en relation avec plusieurs autres tables. Mais je compte utiliser sfDoctrineGuard pour la gestion des membres (puis tu m'as persuadé de le faire).

1. Premier souci: Lorsque j'aurai installé le plugin, pourrais-je créer une liaison entre la table sfUser et ma table membre, de façon à obtenir les données de cette dernière à partir de la première ?

2. Ou bien puis-je créer mon espace membre en me passant de la ma table membre ? Si oui, qu'est-ce que je fais de ses relations avec les autres tables, et comment créer le modèle ? je demande ca parce que les tables que sfDoctrineGuardPlugin crée viennent plus tard à son installation, alors que le modèle devrait être en place dès le début du projet.

J'avoue que je suis un peu embêté par ce plugin et que je n'y vois pas encore totalement clair. (J'ai lu et relu la doc.) Alors toute idée pour m'en sortir serait la bienvenue. (Stp Rotta, si c'est pas trop demander, tu pourrais détailler un peu plus ta réponse ? Merci).

[Michel Rotta]

Michou, Michou... ça peut prêter à confusion, non, je ne travail pas dans un cabaret

Vu ta deuxième reformulation, je me dis que j'avais plutôt bien compris la première

Bon :
1) non, tu ne pourras pas créer une table de liaison (enfin oui, tu pourais, mais cela n'aurait aucun intérêt). Par contre, tu peux parfaitement créer un lien entre ta table membre et la table sfGuardUser qui est celle des utilisateurs. Plus simple qu'une table intermédiaire et moins lourd à gérer.

2) Non, tu ne pourras pas te passer d'une table membre, quoique. En fait il est possible d'étendre la table sfGuardUser de deux manières différentes, soit directement, et elle deviendra ta table membres, soit par héritage directe (un particularité de Doctrine)(ce qui me semble mieux) qui te permet d'avoir une seul table accessible sous deux jeux d'objets distinct, sfGuardUser pour ce qui est de sa partie propre et membres pour le reste, avec les données provenant de sfGuardUser accessibles dans la table membres.

Par contre, les deux solutions impliques d'intégrer sfDoctrineGuardPlugin dés le début de l'étude et de la construction et je ne comprend pas pourquoi tu ne souhaite pas intégrer le sfGuard au départ.

Attention, dans la version 5 de sfDoctrineGuardPlugin, la table inclus des champs nom, prénom... qui pourraient faire double emploi avec une table membre totalement indépendante.

[etoileweb]

J'ai compris beaucoup de chose en lisant ces tutos ici: http://www.symfony-project.org/blog/...ineguardplugin, ici : http://www.symfony-project.org/blog/...ineguardplugin et ici : http://www.prettyscripts.com/framewo...g-user-profile

Toutefois, je continue d'avoir quelques ennuis. J'ai établi une relation 1 to 1 entre ma table membre et la table sf_guard_user:

Code :

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

1
2
3
4
5
relations:
  User:
   class: sfGuardUser
   foreignType: one
   onDelete: cascade

Espérant remplir sf_guard_user à partir de la table membre. Mais quand je soumets le formulaire, symfony retourne cette erreur:

Code :

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

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`nortb`.`membre`, CONSTRAINT `membre_sf_guard_user_id_sf_guard_user_id` FOREIGN KEY (`sf_guard_user_id`) REFERENCES `sf_guard_user` (`id`) ON DELETE CASCADE)

Pourriez-vous m'expliquer ce qu'il y a à faire ? Mes recherches sur le web ne m'ont pas beaucoup avancé. Merci.

[belgacem.tlili]

bonjour,

est ce que tu a utiliser le formulaire de MembreForm pour remplir la table membre et sf_guard_user ??
normallement tu doit imbrique le formulaire de sf_guard_user dans le membreFrom en utilisant le relation User que tu vient le creer

[etoileweb]

J'ai compris vos deux points de vue et je crois que vous avez tous raisons puisqu'après tout, seule une table sera dérivée et cela ne pose aucun problème de confusion dans les enregistrements. Mais en fin de compte j'ai choisi l'aggrégation de colonne et tout semble bien marché.
Seul problème (et le dernier, je l'espère), l'action signin. En fait, les infos s'enregistrent dans les champs ajoutés de sfGuardUser, tandis que ces champs firstname, lastname, email_address et username, qui sont des initiaux de sfGuardUser restent vides. Du coup l'authentification ne marche pas. Je crois que signin va chercher les infos dans ces champs. Je veux le reconfigurer pour lui indiquer les champs corrects, mais impossible de le trouver. Le fichier actions.class.php du module sfGuardAuth présente la classe suivante qui est vide:

Code :

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

1
2
3
class sfGuardAuthActions extends BasesfGuardAuthActions
{
}

Et je n'ai pas pu mettre la main sur ce basesfGuardAuthActions.class.php. Ou puis-je trouver l'action signin ? Suis-je autorisé à la modifier, sinon comment réussir l'authentification dans ces conditions ? Merci.

[bilbonec]

les infos s'enregistrent dans les champs ajoutés de sfGuardUser, tandis que ces champs firstname, lastname, email_address et username, qui sont des initiaux de sfGuardUser restent vides

A partir de quoi ces objets Doctrine sont-ils construits ? Un formulaire ou tes fixtures ?

Pour ce dernier cas, il y a une écriture particulière quand tu écris un fixture d'une classe enfant ; il ressemblera à ça :

Code :

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

1
2
3
4
5
6
7
sfGuardUser:
  monUser1:
    name: blabla
    email: bleble
    MonProfil:
      added_field1: blibli
      added_field2: blublu

EDIT

J'oubliais, pour l'action signin, un Search dans le plugin sfGuard sur executeSignin te donne directement :
- sfDoctrineGuardPlugin > modules > sfGuardAuth > lib > BasesfGuardAuthActions.class.php

[etoileweb]

Les données proviennent du formulaire du module membre.
Merci, j'ai bien retrouvé BasesfGuardAuthActions.class.php, mais franchement, je n'y vois rien à faire pour faire l'authentification. Tu as une idée ? Ou alors, comment faire pour remplir à partir du formulaire membre les champs originelles de sfGuardUser ?

[etoileweb]

C'est bon, j'ai réussi. J'ai fini par rebuild le modèle en renommant pareil les champs de mon modèle membre correspondant à ceux du modèle sfGuardUser. Ainsi pseudo est devenu username, ainsi de suite... Les données s'enregistrent dans le champ approprié de sfGuardUser qui ne les a pas dupliqués. L'authentification se passe sans le moindre problème. La bataille a été longue mais la victoire l'a couronnée.
Sauf que moi je veux l'affiner un peu plus. Lors de l'authentification, je veux vérifier si le membre a été banni par exemple. J'ai beau regarder dans le module sfGuardUser, mais j'ai pas trouver les actions qui commande l'authentification. Où dois-je faire cette configuration ? merci.

[mantex]

Bonjour,

Intéressante cette discussion.

Si résume l' héritage par aggrégation est conseillé en dupliquant les champs présente dans la table mère dans la table fille ?

Dans ce cas peut ton une table plusieurs fois pour pouvoir gérer des profils ?

ex :

sfguardUser -> client
sfguardUser -> assistant ( pouvant crée d ailleurs créer des clients)

[etoileweb]

Si c'est possible, mais dans ton cas précis, je crois qu'il conviendrait mieux que tu crées différents groupes d'utilisateurs (avec les permissions nécessaires) (Exemple: groupe client, groupe assistant) plutôt que de tables dérivées.

En ce qui concerne la duplication de colonnes, c'est ni l'objectif visé ni une obligation. Je l'ai fait juste pour surmonter une difficulté.