classe polymorphe (?) dynamique

Version imprimable

12/12/2018, 22h32
wesh poussin

classe polymorphe (?) dynamique

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...
13/12/2018, 18h40
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.
14/12/2018, 03h44
wesh poussin

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

Citation:

Envoyé par Freudd

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.

Citation:

Envoyé par Freudd

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...

Citation:

Envoyé par Freudd

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 ?

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

Pseudocode blade :

Code:

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

Le modèle Page :

Code:

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

16/12/2018, 09h00
wesh poussin

Citation:

Envoyé par Happy

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

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.
16/12/2018, 22h23
Happy

:P 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 :aie:
18/12/2018, 08h26
wesh poussin

ben a priori, pas besoin de table pivot, juste :

- une table pages avec une colonne id
- une table blocs avec des colonnes id, type, et page_id

le problème c'est à partir de l'id de la page, de récupérer une liste d'objets (de modèles) correspondant aux différents types de blocs.
pour rappel chaque type de bloc implémente ses propres fonctionnalités (attributs et méthodes) et ils doivent pouvoir être gérables comme des plugins (installables / désinstallables, activables / désactivables)
18/12/2018, 08h31
wesh poussin

peut-être qu'avoir recours à des traits serait plus simple à gérer dynamiquement (et ressemblerait un peu à cet "héritage inversé" dont je parlais au dessus)

donc les plugins concernant les différents type de blocs se présenteraient sous la forme de traits à implémenter dynamiquement à un modèle block unique.
ça me semble un peu plus viable dans ce sens...