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]

non, j'ai pas embeded le formulaire memberForm. Mais dans le executeNew, j'ai fait ceci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
$user = new sfGuardUser();
$user->setUsername($request->getParameter('pseudo'));
// ainsi de suite pour tous les champs.
// et avant de save le formulaire
$user->save();
// Une autre difficulté
// Récuperer cet objet $user et envoyer son id à $form 
// pour set le sf_guard_user_id à envoyer à la table membre
// Mais je n'ai aucune idée de comment faire
// Eventuellement $form($user); ?
// $form->setSfGuardUserId($user) renvoie une erreur. Je sais, c'est barebare de faire ca.
// et enfin
$form->save();

[bilbonec]

Plusieurs choses :

A priori, tu ne veux pas "récupérer cet objet" et le passer à ton MembreForm, mais récupérer l'id du user.

Ensuite, d'après le scénario que tu donnes, il conviendrait effectivement de faire un embedForm de User dans MembreForm.

Ceci dit, il faudrait peut-être commencer par revenir sur le schéma et être un peu plus verbeux (pour une fois ). Même si ce que tu mets à des chances d'être juste, je te conseillerais pour le moment de faire un :

Code :

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

1
2
3
4
5
6
relations:
  User:
    local: user_id
    foreign: id
    class: sfGuardUser
    foreignType: one

Ensuite, tu pourras réaliser ton embedForm dans ton MembreForm. Cela sera plus propre et aura plus de chances de marcher.

[etoileweb]

Je n'y suis pas arrivé. Avec ou sans embedForm, verbeux ou pas, ca n'a pas marché malgré tout ce que j'ai fait. Ca a pratiquement bouffé toute ma semaine.

Je résume le scénario souhaité pour ceux qui auraient d'éventuelles idées.
Objectif: Etendre sfDoctrineGuardPlugin pour avoir un profil utilisateur plus complet.
Actions: Créer un modèle membre avec une relation 1à1 vers sfGuardUser

Difficultés: comment renseigner les deux tables simultanément ?
J'ai essayé avec et sans embedForm sans succès.

Il y a un article ici: http://www.symfony-project.org/blog/...ineguardplugin. Je l'ai essayé mais ça n'a pas marché. En plus le scénario qu'il propose est pour le backend et si je fais un module sfGuardUser dans le frontend ca va faire doublons avec mon module membre, en plus tout le monde saura que j'ai utilisé sfDoctrineGuardPlugin. De toute façon, avec le embedForm ca me renvoi

Code :

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

sf_guard_user_id (on membre) could not be null

Quant à ce billet ici qui semble super, il n'est pas suffisamment... verbeux. Il ne dit pas dans quelle module se trouve son action executeRegister par exemple.
Ceux qui ont déjà réalisé leur espace membre basé sur sfDoctrineGuardPlugin, veuillez nous dire comment vous avez fait. Merci.

[bilbonec]

Ok, une chose que je n'ai pas faite : te parler d'héritage.

Dans Doctrine, tu peux définir des notions d'héritage : simple -- qui est inutile, selon même Doctrine !-- ; agrégé ; et concret.

Pour le moment, j'ai définis mes profils de cette façon :

• je créé un objet myProfile dans schema.yml qui étend de sfGuardUser en mode aggregation ;
• cet objet possède par défaut tous les champs définis dans sfGuardUser ;
• je déclare de nouvelles columns pour lui définir mes champs supplémentaires ;
• après le doctrine:build --all, j'ai dans mon lib > form un formulaire de base qui me fait souvent déjà tout ce qu'il faut.

Je pense que tu auras moins de difficultés à utiliser cette méthode, qui t'enlève ta gestion de la relation 1-1, source potentielle d'erreurs. Tu laisses ce boulot à Doctrine en passant par l'héritage concret, et tu l'évites même complètement avec l'héritage par agrégation puisqu'une seule table sera générée.

EDIT

Documentation officielle sur le sujet : Inheritance

[Michel Rotta]

C'est aussi la solution que je t'ai proposé ici. Deux avis identique, faut essayer !

[etoileweb]

Hum, ca semble intéressant. J'ai lu la doc que tu m'a proposé, bibonec. Comme c'est un "phénomène" tout neuf pour moi, je vais me documenter encore plus dessus. Je viens de trouver à ce propos cet article et je vais le lire. A bientôt pour la suite.

[bilbonec]

Que ce soit pour ton problème actuel ou un autre, tu seras obligé de passer par l'héritage Doctrine si tu veux faire des projets Symfony propres car, comme l'article le dit :

l'héritage de table est probablement l'une des fonctionnalités les plus intéressantes de Doctrine

Alors bonne lecture

[etoileweb]

Je commence à y voir un peu plus clair dans ce fameux héritage et je crois qu'il est prometteur d'avenir radieux. Je penche pour l'héritage concret qui créera une table membre bien "concrète". Problème, d'après ce que j'ai lu, avec ce type, les enregistrements ne sont pas répliqués dans la table maîtresse. Dans ces conditions, comment authentifier les membres, puisque l'action signin (si j'ai bien compris sfDoctrineGuardPlugin) devrait chercher les identifiant dans le modèle sf_guard_user qui serait alors vide ? comment gérer ca, les permissions, et tout et tout ?

[Michel Rotta]

Humm

C'est la moins bonne notion d'héritage, comme tu as pu le constater, pour étendre la table sfUserGuard.

Essaie un héritage simple, qui va tous stocker dans une même table, et, dans symfony te donner deux jeux d'objets du modèles pour y accéder, un pour garder la partie administration, l'autre pour des champs rajoutés.

[etoileweb]

Ok, je n'ai pas compris ce que tu veux dire par "partie administration" mais avouons que ça se précise de plus en plus. Néanmoins, je demanderais quelques petits éclaircissements avant de passer à l'action. Est-ce que la réplication vers la table maîtresse des données enregistrées dans la table fille se fait automatique ou je dois le faire manuellement ? Puis, comment faire pour que toutes les actions se fassent sur le module membre, avec association des données dans les différents modèle de sfGuard, car je ne veux pas laisser apparaître que j'utilise le plugin ? Merci encore une fois.

[Michel Rotta]

Avec ce système d'héritage il n'y a qu'une table, donc aucun problème de transmission d'information !

Dans le plugin, tu as une partie administration qui permet de gérer les user, leurs groupes, leurs droits et les droits des groupes, c'est ce que j'appelle la partie administration, il me semble intéressant de la conserver.

Tu pourras facilement masquer l'utilisation du plugin pour le frontend moins facilement pour le backend et je n'en voit pas trop l'intérêt.

[etoileweb]

Ah, j'ai confondu. Mais là alors ça soulève une autre question. Puisque l'héritage ne crée qu'une seule table, qu'est-ce que je fais des relations de ma table membre actuelle ? Ou plutôt, je les transforme en relations avec sf_guard_user ?

[bilbonec]

Note importante : il est très déconseillé d'utiliser l'héritage simple dans quasiment tout projet !

Bien que de la doc existe dessus, il vaut mieux considérer qu'il n'existe que deux notions d'héritage : par agrégation et concret. Et ceci, de l'avis même de Doctrine, car l'héritage simple ne permet pas de distinguer tes enregistrements en base !!!

Ainsi, tu ne pourras faire de requêtes sur une table fille ou parente unique : elles concerneront forcément toutes les tables de ta hiérarchie !

Donc, si tu ne veux pas utiliser l'héritage concret, il faut utiliser l'héritage par agrégation.

Puisque l'héritage ne crée qu'une seule table, qu'est-ce que je fais des relations de ma table membre actuelle ?

Avec l'héritage par agrégation, même si tout est stocké dans une seule table, Doctrine ajoute seul une clause WHERE (p. ex. : WHERE type=myProfile) qui te permet de simuler tes différents objets. Tu peux tout à fait garder tes relations anciennes, elles sont censées toujours marcher.

[Michel Rotta]

Pas d'accord pour l'héritage simple, dans ce cas très particulier où il s'agit d'étendre une table avec un double système d'objet, il est le système d'héritage à utiliser.

Dans le cas où on souhaiterais avoir plusieurs types d'user différents avec des liaisons différentes (je ne pense pas ce système viable), alors l'agrégation est une solution.

Mais on est ici dans un cas très particulier, nous n'avons pas deux tables différentes, juste deux vue différente d'une seule et unique table.

Et pour répondre sur les droits, tu définis tes liens vers ton objet agréé, de la même manière que tu les définissaient avant, juste attention à la taille de l'Id, mais dans mes souvenirs, dans la version 5 de sfGuard, l'Id est passé à integer(8) (a vérifier).