Discussion :

[rikemSen]

Bonjour,

Débutant sous Symfony, je bloque sur la logique pour mes entités. J'ai encore trop la conception orienté BDD et non entités/doctrine.

Je cherche à ce que :

• Un blog peut avoir plusieurs instances d'un même module
• chaque instance d'un module a ses propres configurations. (SES et non SA)

En MPD ça donnerait :

Blog : définit le blog en général
Module : définit le module en soit (nom, maximum d'instance possible par blog, date de création etc)
InstanceModule : définit que pour un blog précis il y a une instance d'un module (identifiable par son idInstance du coup)
ConfigurationModule : pour telle instance, il y a des paramètres

Exemple :
Un blog a deux fois le module "pub" sur son blog. Chaque instance a une configuration particulière avec par exemple (en configurationModule) :

idInstance : 1 (l'auto-increment généré dans la table associative InstanceModule)
key : imagePub
value : image1.png

idInstance : 2 (l'auto-increment généré dans la table associative InstanceModule)
key : imagePub
value : image2.png

En espérant que je suis assez clair sur mes explications.

A savoir que j'essaye de modéliser ça sous Skipper18 (anciennement "orm-designer") pour générer mes entités. Pouvez vous m'aider sur la partie purement logique/entité ?

Merci d'avance .

[Nico_F]

Hello,

Si tu veux modéliser des objets et non des tables, tu devrais commencer par modéliser avec un diagramme d'objet UML plutôt qu'un MPD Merise qui lui se focalise sur la BDD justement.

Ceci mis à part ce que j'en comprends c'est :
- Un blog a une collection de modules.
- Un module possède un type et une configuration.

Pour moi un Module c'est de toute manière une instance de module.
Pour toi un Module, c'est ce que je vais appeler un type de module.

La question à te poser c'est la suivante :

Est-ce que la liste de type de module est (plus ou moins) fixée ? Ou est-ce qu'elle est amenée à être modifiée par l'utilisateur depuis l'interface du site ?
En gros ce que je veux savoir c'est si c'est l'utilisateur qui va rajouter des types de module, ou si c'est le dev qui va faire de nouvelles fonctionnalités en ajoutant un type de module.

Dans le premier cas, tu ne seras pas obligé d'avoir une entité "type de module", tu pourras faire autant d'entités que de types de module (qui hériteront évidemment d'une classe commune) et les spécificités de ces modules se feront dans l'implémentation de chacune des classes.

Dans le second cas, tu seras obligé d'avoir une relation avec une entité type de module puisqu'on pourra ajouter ou retirer à tout moment un module existant.

[rikemSen]

Tout d'abord merci pour ta réponse.

Oui, je sais que le MPD est pas le plus adapté mais je savais pas comment expliquer mon problème autrement qu'en parlant en sgbdr .

La liste des modules est amenée à s'agrandir mais ça reste les développeurs du site qui vont les faire et le proposer fur et à mesure sur le site.

J'aurais donc en entités : blog, module et ?

L'idéal au final serait que je puisse faire approximativement quelque chose comme :

Code PHP :

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

1
2
3
4
5
 
$modules = $blog->getModules('HOOK_RIGHT');
foreach ($modules as $unModule) {
	$configuration = $unModule->getCfg();//récupère un array key/value 
}

[Nico_F]

Alors pars sur la première solution :

On va dire que je vois large et que je te fais la solution la plus souple possible.

Une interface ModuleInterface avec les méthodes obligatoires à implémenter pour chacun de tes modules (getName(), getConfiguration() etc.)
Une classe abstraite ModuleAbstract qui implémente déjà l'interface et qui possède les attributs communs à tous tes modules (et les setters qui vont avec (name, description etc.))
Plein de classes (ModuleTruc, ModuleMachin etc.) : autant qu'il y a de types de module qui étendront ModuleAbstract. Le nombre de modules pouvant être cumulés dans un seul blog sera défini en constante dans chacune de ses classes.
Une classe ModuleConfiguration qui aura une relation OneToOne avec ModuleAbstract. (à priori, un module n'a qu'une configuration et une configuration n'est effective que pour un module).

La difficulté sera peut-être la déclinaison des configurations si tu te retrouves avec des configurations qui ne possèdent pas du tout les mêmes champs.

En BDD ça donne à peu près ton schema mais sans le cadre de droite.
Si tu utilises l'ORM Doctrine, le mapping de tes attributs se fera sur la classe abstraite, et une colonne discriminator sera ajoutée à ta table en vdd pour pouvoir peupler la bonne classe quand il récupère les data d'un module.

Et tu pourras faire :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
foreach($blog->getModules() as $module) {
    $configuration = $module->getConfiguration();
    if ($module instanceof MonModule1) {
        $configuration->add('xx', 'yy');
    } elseif ($module instanceof MonModule2) {
        $configuration->add('zz', 'aa');
    }
    // etc...
}

[rikemSen]

Kamoulox.

Je vais étudier ce que tu me dis et demander des explications sur le chat . Merci beaucoup pour la solution. Je vais partir sur ça du coup