[Symfony 5] Afficher une liste d'objets enfants

Le problème exposé dans ce sujet a été résolu.

Bonjour,

Je possède 4 classes qui ont au moins 15 propriétés en commun.

La logique voudrait donc que je mette tous ces éléments en commun dans une classe abstraite, dont mes 4 classes enfant étendraient (ma classe abstraite étant Activity).

Or, je n’arrive pas à lister mes objets (ce que j’essaie de faire via mon controller) :


	/**
	 * @Route("/testActivity/list", name="testActivityList")
	 */
	public function testActivityList(ActivityRepository $activityRepository)
	{
		$activities = $activityRepository->findAll();

		return $this->render('activity/testActivityList.html.twig', [
			'controller_name' => 'testActivityList',
			'activities' => $activities,
		]);
	}


En effet, cela me génère cette erreur : The provided class "App\Entity\Activity" is abstract, and can not be instantiated.

Je la comprend tout à fait car il est logique de ne pas pouvoir lister les objets d’une classe abstraite, mais je ne trouve pas la solution…

J’imagine que je ne suis pas la seule à vouloir faire ce genre de chose et qu’il doit exister une solution simple ?

Merci par avance pour votre aide.

Je crois que je ne vois pas trop ce que tu veux dire par "lister les classes enfants plutôt que ta classe abstraite avec un type d’union".

En tout cas dans mon template toutes mes Activity doivent être listées dans un même tableau, triable et filtrable (j’utilise datatables)

Je ne connais pas. Je suis en PHP 7.1 et j’utilise Twig.

A mon avis je n’ai pas compris, mais si je veux faire l’équivalent, dans mon controller il faudrait que j’appelle chaque repository de chacune de mes classes, les render dans mon twig et dans chaque ligne de mon tableau faire un

//...
<li>{{ activityType1.date }} || {{ activityType2.date }} || {{ activityType3.date }} || {{ activityType3.date }}</li>
<li>{{ activityType1.startTime }} || {{ activityType2.startTime }} || {{ activityType3.startTime }} || {{activityType4.startTime }}</li>
//...

Mes données sont stockées en BDD, dans des tables différentes (ex: ActivityType1, ActivityType2, …), mais avec une base commune (Activity, qui est en abstract).

Si Activity n’est pas en abstract cela fonctionne mais le pb c’est qu’on est pas censés pouvoir l’instancier, donc pour moi le abstract est obligatoire.

Mes objets ont vraiment des propriétés identiques (par exemple date, startTime, endTime, …), c’est pour cette raison que je souhaite utiliser une classe mère abstraite.

Mais si les classes mères abstraites ne peuvent pas reliées à un Repository d’une façon ou d’une autre je crois que je ne vais rester comme j’étais avant, à savoir une classe Activity et une classe ActivityType.

Si ça se trouve c’est la meilleure solution au final, peut-être que je me suis pris la tête pour rien …

Salut

Est-ce que ta classe Activity est bien en MappedSuperclass ? Auquel cas, une MappedSuperclass ne peut pas être une entité, et donc pas utilisable telle quelle dans les requêtes, effectivement

Peut-être que la stratégie Class Table Inheritance de Doctrine pourrait te permettre ce que tu souhaites ?

+1 -0

Non, elle n’est pas MappedSuperclass, uniquement en abstract basique.

En revanche effectivement le fait de passer par une Single Table Inheritance correspondrait davantage à mes besoins !

Par contre ma table Activity est en Many-to-One ou One-to-Many avec d’autres tables, donc peut-être qu’il faut mieux que j’évite quand même d’après ce que je vois dans cette partie : https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/reference/inheritance-mapping.html#performance-impact, même si je ne comprend pas bien ce que ça veut dire (je bute sur le terme "leaf entity" entre autre).

Ah et puis "Columns that have NOT NULL constraints have to be on the root entity of the single-table inheritance hierarchy.", or j’ai des not null dans mes sous-entités, du coup ça ne va pas le faire. Je crois que le mieux c’est vraiment que je reste avec mes 2 entités : Activity et ActivityType.

En tout cas merci pour tes liens : c’est ce genre de chose que je recherchais mais je n’étais pas arrivée à tomber dessus ;-)

+0 -0

J’ai parlé de class table inheritance qui colle plus à ce que tu as comme modélisation si j’ai bien compris, et ce n’est justement pas single table inheritance, où toutes les entités seraient dans la même table  ;)

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte