Discussion :

[gavelin]

Bonjour à tous,

Je commence à peine symfony, j'ai fait le tutorial, et maintenant je me pose une question concrète concernant ma future application, question qui je le pense concerne à peu près tout le monde qui utilise symfony. Mais je n'ai vu personne qui posait clairement la question et personne qui n'y répondait clairement ^^

J'ai vu que la gestion des utilisateurs et de l'authentification était possible via les plugins sfDoctrineGuardPlugin par exemple.

Le problème c'est que j'ai besoin qu'un "user" ai des champs spécifiques du style : age, date de naissance, ville etc. et pas seulement son login, mot de passe !

Comment faire cela en se basant sur un plugin Symfony qui existe deja et qui nous permet de faciliter les choses tout de même ??

En vous remerciant d'avance

[Vince57]

Hello,

(grande première, c'est la première fois que j'arrive à aider quelqu'un)

C'est extrêmement simple en fait. Il suffi de créer un modèle pour ton "Profil", que tu lies à ton modèle sfGuardUser par une relation 1-1.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Configuration:
  actAs: { Timestampable: ~ }
  columns:
    lignetitre:         { type: integer, notnull: true }
    utilisateur_id:     { type: integer, notnull: false }
    signeastro :     { type: string, notnull: false }
  relations:
    Utilisateur:
      class: sfGuardUser
      local: utilisateur_id
      foreign: id
      type: one
      foreignType: one
      foreignAlias: Config

Et c'est tout!

Quand l'utilisateur se connecte, tu peux lui donner un lien vers son profil :

Code :

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

url_for('configuration/edit?id='.$sf_user->getGuardUser()->getConfig()->getId())

Côté administrateur, je te revoie à ce lien pour intégrer le profil à l'utilisateur.

[gavelin]

Merci Vince pour ces explications claires !!

Maintenant, si je veux lier mon user à d'autres tables (par exemple, une recette de cuisine), il faut que je fasse dans mon modèle recette vers l'utilisateur de type sfGuardUser comme tu as fait ?

Code :

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

1
2
3
4
5
6
7
8
9
 
relations:
    Utilisateur:
      class: sfGuardUser
      local: utilisateur_id
      foreign: id
      type: many
      foreignType: one
      foreignAlias: Recette

[Michel Rotta]

Il y a plusieurs solutions:

1. celle de Vince
2. redéfinir la table sfGuardUser dans le shema.yml de ton application en y rajoutant les champs
3. passer par le plugin sfForkedDoctrineApplyPlugin

La quel prendre ? C'est fonction des besoins.

Si tu dois permettre aux utilisateurs de gérer leurs comptes (cration, modification des mots de passes, de email, avec vérification) seul, la solution 3 est la tienne.

Si l'administrateur fait tous ce qui est configuration, la 1 est plus propre côté plugin (pas de modification du plugin, donc pas de problème en cas d'évolution de celui-ci), la 2 est la plus simple à mettre en oeuvre, mais, si le plugin évolue beaucoup (peut probable pour celui-là), il faudra, peut-être, modifier le shema et le prendre en compte.

[bilbonec]

Une alternative à ta solution 2. serait de partir sur le code de Vince et d'ajouter une notion d'héritage par aggrégation.

Vu que Doctrine gère (en partie correctement) l'héritage, autant s'en servir !!

http://www.doctrine-project.org/docu...en/inheritance

[gavelin]

J'ai opté pour la solution de mimi68 car j'ai besoin de gérer l'inscription de l'utilisateur, la vérif par email etc.

Par contre petit bémol sur le plugin sfForkedDoctrineApplyPlugin ; il ne marche pas avec la version 5.0.0 de sfDoctrineGuard ...
j'ai du installé une version plus ancienne de sfDoctrineGuard pour le faire marcher, en attendant la version compatible !.

[Michel Rotta]

Ca viendra (j'espère !).

@Bilbonex:
Tu as raison, il est aussi possible de passer par un héritage par agrégation de colonne. Seul inconvénient, la table finale change de nom et il est alors nécessaire de redéfinir un formulaire pour la gestion des utilisateur, celui de sfGuard ne marchera pas.

Ce qui, suivant les cas, sera un avantage ou un inconvénient.

[bilbonec]

@mimi68 : je ne comprends pas. Faire de l'héritage par aggrégation ajoute un champ "type" à ta table qui permet à l'ORM de reconnaître quel type d'objet est enregistré.

Et tu auras aussi deux objets : sfGuardUserForm et configurationForm qui seront générés et qui te distingueront les deux types de formulaire.

A moins que je n'ai pas compris quelque chose dans ta remarque ?

[Michel Rotta]

En fait tu auras effectivement deux objets, sfGuarUser et configurationForm.

La différence c'est que le sfGuarUser vas "voir" tous les user créé par configurationForm, mais que pour les champs définit dans sfGuardUser...

Donc dans le sfDoctrineGuardPlugin, le module de gestion des users ne prend pas en compte les nouveaux champs et tu es obligé de redéfinir un deuxième formulaire d'administration, basé sur configurationForm, pour gérer soit le reste des champs, soit la totalité... Donc plus de travail.

Et je suis particulièrement paresseux !

[bilbonec]

Ok, je vois ce que tu veux dire.

Je n'ai à ce jour utilisé que :
- soit des profils (en considérant en quelques sortes sfGuardUser comme une classe abstraite) ;
- soit des objets sfGuardUser.

Du coup, je n'ai pas eu l'occasion de vérifier ce point.
Il faudra que je le garde en tête pour le jour où je mixerai des profils et des sfGuardUsers

[Michel Rotta]

La version 5 de sfGuard a enrichie, légèrement, les profils de base, peut-être un début ?