Discussion :

[zarathoustra06]

bjr

débutant sur SF2 je travail sur une application elearning. je veux récupérer les l'ensemble des formation sur les quelle un etudiant est inscris. pour la gestion des étudiant j'utilise FOSUser sachant que l'entité user est liee a l'entité formation avec la relation onetomany

j'arrive a recuperer l'id user mais je ne sais pas comment l'utiliser pour recuperer les formation le concernant sur l'entité formation

merci pour votre aide.

[garniture]

Bonjour, est-ce que tu peux poster tes entités ?
Idealement un bout de code sur lequel t'as bossé ce serait un bon début.

Ps : Une formation peut avoir 1 ou plusieurs de stagiaires, un stagiaire peut avoir 1 ou plusieurs formations, pour moi c'est une relation manyToMany.

[damiensan]

Dans ton entity provider tu peux spécifier la méthode de récupération de ton entité. Tu ajoutes tes jointures et le tour est joué.

[garniture]

Dans ton entity provider tu peux spécifier la méthode de récupération de ton entité. Tu ajoutes tes jointures et le tour est joué.

Attention ajouter du traitement dans une entity est considéré comme une mauvaise pratique, si son mapping est bon, il dois faire un simple findAll() depuis le controlleur, si ce n'est pas le cas un pti coup de queryBuilder.
Il utilise FOSUserBundle, il ne dois surtout pas toucher à l'entity provider.

Dans tous les cas il dois montrer ses entités User et Formation

[gestrad]

Tu peux faire une relation bidirectionnelles entre tes entités.

Dans ton entités User tu auras une propriété $formations de type ArrayCollection contenant toutes les occurrences des formation.

Ensuite pour accéder à la liste des formations de l'utilisateur (depuis le controller par exemple) :

Code :

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

$formations = $user->getFormations();

Après tu peux itérer sur $formations avec un foreach par exemple pour accéder individuellement à chacune des formations.

[damiensan]

Attention ajouter du traitement dans une entity est considéré comme une mauvaise pratique, si son mapping est bon, il dois faire un simple findAll() depuis le controlleur, si ce n'est pas le cas un pti coup de queryBuilder.
Il utilise FOSUserBundle, il ne dois surtout pas toucher à l'entity provider.

Dans tous les cas il dois montrer ses entités User et Formation

Qu'est ce que tu racontes ? O_o

Faire un findAll() ?? bonjour le niveau de performance si tu as 12 000 000 d'utilisateurs.

De plus ta récupération de données doit se faire dans un service, qui est précisément l'entity provider.

Tu dois surcharger l'entity provider de FOS et spécifier une jointure dans la méthode loadUserByUsername, de cette façon tu auras dans la variable 'user' du contexte de sécurité ton utilisateur et toutes ses formations en une seule requête.
Ca c'est si tu souhaites par exemple afficher les formations de ton utilisateur connecté.

Si tu souhaites afficher une liste des utilisateurs avec leur formations. Une simple requête avec jointure dans ton repository te permet de le faire. Et comme dit précédemment tu pourras boucler sur les formations de chaque utilisateur avec un simple foreach

[MehrezLabidi]

Je te suggère d'utiliser des subscriber

[Nico_F]

Qu'est ce que tu racontes ? O_o

Faire un findAll() ?? bonjour le niveau de performance si tu as 12 000 000 d'utilisateurs.

De plus ta récupération de données doit se faire dans un service, qui est précisément l'entity provider.

Tu dois surcharger l'entity provider de FOS et spécifier une jointure dans la méthode loadUserByUsername, de cette façon tu auras dans la variable 'user' du contexte de sécurité ton utilisateur et toutes ses formations en une seule requête.
Ca c'est si tu souhaites par exemple afficher les formations de ton utilisateur connecté.

Si tu souhaites afficher une liste des utilisateurs avec leur formations. Une simple requête avec jointure dans ton repository te permet de le faire. Et comme dit précédemment tu pourras boucler sur les formations de chaque utilisateur avec un simple foreach

D'accord pour le findAll => très mauvaise idée. D'autant plus que ce n'est pas du tout ce qui est demandé.

Une simple requête avec jointure dans le repository permet effectivement d'afficher une liste des utilisateurs avec leurs formations.
Du coup si une requête peut faire ça, elle peut aussi faire une simple requête avec jointure dans le repository pour afficher un seul utilisateur avec ses formations.
J'avoue ne pas avoir bien saisi l'intérêt d'utiliser l'entity provider dans ce cas de figure : qu'est-ce que ça apporte de plus ?

Le problème n'est pas compliqué : un user a des formations. On les récupère en faisant $user->getFormations().

Il ne veut pas récupérer des users, il ne veut pas récupérer les formations d'une liste de users. Il veut les formations d'un user : c'est récupérer la collection d'un objet c'est tout.
En tant que débutant Symfony, vu la faible complexité du cas, et vu qu'il ne nous dit ni comment il récupère l'id de son user, ni dans quelle classe il se trouve, on ne peut pas en dire beaucoup plus ni suggérer des moyens d'optimisation.

Pour faire plaisir à damiensan je vais aussi proposer ma réponse saugrenue :
troll mode on* : Je te suggère d'utiliser des subscriber twig de repository dans lesquels tu devra dispatcher le CompilerPass....et la POO

[garniture]

@damiensan Merci de me faire remarquer que j'ai conseillé un findAll, je pensais à un findBy.
Je persiste l'entity provider ne sert pas dans ce cas de figure.
Je persiste c'est surement une ManyToMany
Je persiste tant qu'il ne montre pas ses entités dur dur de l'aider...

[damiensan]

Ok tu persistes beaucoup… mais est-ce que tu flush ?

En fait, je proposais l'entity provider car il a parlé de FOSUser. S'il veut afficher les formations de l'utilisateur connecté, il pourra directement les avoir dans le contexte de sécurité sans faire de requête supplémentaire.
Après si c'est pour le faire dans un controller, c'est clair qu'on se pend la tête pour pas grand chose, un requête de répo et hop c'est fini. (en relation n-n je pense aussi)

Un conseil, lis la doc de Symfony. C'est expliquer dans les tout premiers chapitres car ton "problème" est la base de ce que tu peux faire avec Sf et Doctrine