Discussion :

[wesh poussin]

Bonjour,

je développe un CMS avec Laravel, mais je suis confronté à un problème de logique.

L'idée c'est que chaque page puisse posséder plusieurs blocs de contenu de différents types : html, galerie d'images, vidéo, etc.
Chacun de ces types doit se présenter sous la forme de module (plugin), activable ou non, et extensible (dynamiquement) : blockHTML, blockGalery, blockVideo, etc.
A priori je compte partir sur nwidart/laravel-modules pour mettre en place cette fonctionnalité.

L'idée pour l'instant c'est donc que chacun de ces modules hérite d'un modèle module avec lequel ils partagent tous certains attributs et méthodes. Mais chacun peut avoir des attributs et des méthodes qui lui sont propres.
Ils sont également tous sur la même table SQL.

Le modèle page a donc une relation one to many avec ces blocs.

Le problème c'est que je ne peux pas connaître le type de module avant d'avoir effectué une requête, et donc je ne vois pas comment gérer la liaison avec les tables (dans l'idée le modèle module devrait pouvoir être une classe abstraite, mais l'idée d'une liaison polymorphe dynamique me paraît extrêmement bancale) ou je ne vois pas comment dire à mes modules de s'auto-charger la classe qui leur correspond…

J'ai l'impression que le problème est pas si compliqué mais qu'il y a une bête logique qui m'échappe...

[Freudd]

Bonjour,

Désolé j'ai un peu du mal à comprendre, ce que tu appelles 'module' ce sont les blocs contenus par ta page ?
Ou un module c'est un modèle qui représente un bloc ? Si tu pouvais expliquer avec un diagramme de classe ou un diagramme conceptuel des données pour mieux visualiser ?

Bref, si l'idée c'est que tu as une classe abstraite/interface qui représente un bloc et que tu fasses hériter/implémenter cette classe/interface à chaque blocs pour avoir des attribues et méthode communes.
Que tu enregistres en base de données et qu'en fessant ta requêtes se soient tes classes filles et non la mère que tu souhaites afficher (par le polymorphisme).
Il suffit de garder en base de données le nom du type de blocs et d'utiliser un design pattern Factory pour les générer.

[wesh poussin]

merci pour ta réponse et désolé de pas être très clair.

Bref, si l'idée c'est que tu as une classe abstraite/interface qui représente un bloc et que tu fasses hériter/implémenter cette classe/interface à chaque blocs pour avoir des attribues et méthode communes.

oui, c'est l'idée !
je devrais clairement renommer ma classe module en block pour plus de clarté, donc je vais à présent parler de block plutôt que module :
blockHTML, blockGalery, blockVideo, etc. héritent de la classe block (la classe block pourrait aussi être une classe abstraite ou une interface).
et une page possède plusieurs blocs (de différent types).

toutes les classes dont je parle ici sont a priori des modèles.

Que tu enregistres en base de données et qu'en fessant ta requêtes se soient tes classes filles et non la mère que tu souhaites afficher (par le polymorphisme).

mouais c'est là que c'est moins clair : au sujet du polymorphisme.
en gros je ne vois pas de relation polymorphique : tous les blocs, quels que soient leurs types, appartiennent à une page, et à rien d'autre.
au lieu de ça je vois plutôt une multitude de relations one to many qui devront être gérables dynamiquement, vu que l'interface permettra d'ajouter ou de supprimer des types de blocs / donc des classes filles blockExample...

Il suffit de garder en base de données le nom du type de blocs et d'utiliser un design pattern Factory pour les générer.

Oui, c'est ce que je suis en train de faire, mais le problème c'est pas de créer les objets individuellement mais plutôt de gérer leur relation avec les pages.

Dans la pratique : je récupère une page, et je veux aussi récupérer tous ses blocs dans l'ordre et indépendamment de leur type. ça me semble lourd de créer et de gérer une relation par type de bloc : une page possède plusieurs blocs html, plusieurs blocs galerie, plusieurs blocs vidéo...
puis de fusionner tous ces tableaux pour les afficher dans l'ordre.
Mais c'est peut-être la seule solution et tout bien réfléchi je crois que eloquent permet quand même de faire tout ça en une seule requête.
Disons que dans l'idée j'aurais préféré que la page ait une simple relation one to many avec la classe block parent, et que cette classe block "s'auto-étende" à ses classes filles en fonction du champs type stocké en base de données / ou dit autrement que les objets block se mutent d'eux-même en objets blockExample.
Mais je sais même pas si le moindre langage permet ce type d'héritage inversé, donc ça correspond probablement à une erreur de conceptualisation. Et là pour le coup ça ferait certainement des tonnes de requêtes, mais ça me semblerait quand même plus pratique...
Merci en tout cas je crois qu'essayer de reformuler ça m'a permit d'y voir plus clair.

Du coup la question maintenant serait : est-ce que eloquent permet de gérer des relations dynamiques (où le nom de la relation et le nom du modèle appelé sont dynamiques) ?
bon j'ai trouvé ça, je vais continuer à me casser le cerveau : https://packagist.org/packages/patin...amic-relations

Ou est-ce que je me plante complètement et qu'une relation polymorphique me permettrait de faire ce que je veux simplement ?

[Happy]

En gros c'est la table relation qui indique le type

Pseudocode blade :

Code :

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

1
2
3
@foreach ( $page->blocks as $block )
{{ $block->type }}
@endforeach

Le modèle Page :

Code :

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

1
2
3
4
5
6
7
class Page extends Model
{
  function blocks()
  {
      return $this->hasMany('App\PageBlock', 'page_id');
  }
}

[wesh poussin]

En gros c'est la table relation qui indique le type

merci pour ta réponse Happy.

Je ne suis pas sûr de comprendre ce que tu veux dire, ou que tu comprennes ma question.

Je pense comprendre ce qu'est une relation polymorphe, j'en utilise pour des systèmes de tags, ou de fichiers attachés à des contenus divers, et je vois l'intérêt d'avoir une colonne type sur la table relation (tu parles bien de table pivot ?) dans le cas d'une relation Many to Many polymorphe.
Mais je ne pense pas que ça corresponde à mon cas pratique.

En l'occurrence je ne pense pas avoir besoin de table pivot vu que tous les blocs ne peuvent appartenir qu'à une seule page.
C'est donc une relation One To Many.

Le seul intérêt d'une table pivot c'est pour une relation Many To Many non ?

https://laravel.com/docs/5.7/eloquent-relationships

À moins que je me trompe la relation One To Many polymorphe me semble plutôt avoir un intérêt quand le One est de plusieurs types, pas quand le Many l'est :
https://laravel.com/docs/5.7/eloquen...phic-relations

Là je pense avoir besoin de gérer dynamiquement un ensemble de relations One To Many, je vois pas d'autre solution, et je ne sais pas trop si c'est faisable, en particulier sans passer par eval.

[Happy]

En fait, faut pas trop se compliquer, cette table pivot c'est juste.. la liste des blocs de la page. Bien que les blocs soient différents, c'est quand même une liste de blocs à stocker pour chaque page. Puis suivant son type on affiche le bon contenu.

Sauf si j'ai toujours pas compris