Yop,
je me confronte à un cas que je ne sais pas encore trop comment traiter au mieux.
Sur le principe : des mots clés qui représentent une liste de thèmes et de sous thèmes.
Les mots clés arborescents, c'est parfait.
Sauf que certains sous thèmes peuvent être liés à plusieurs thèmes.
Une sorte de polyhiérarchie de mots clés, en quelque sorte.
Quelqu'un a déjà bricolé un truc dans le genre ou bien je me lance dans une usine à gaz ?
Bonjour,
Il y a quelques années, j’ai été confronté au même souci qui se résume à
donner des mots-clés à un mot-clé (ce sont donc ses « parents »). La
solution (avec représentation graphique des relations), bricolée à
l’arrache s’appelait Mot sur Mots (Momo) :
– https://plugins.spip.net/momo.html
– https://contrib.spip.net/MoMots
Ce n’est sûrement pas une base de
code à reprendre 
peut-être quelques idées cependant ?
@+
Salut
Polyhierarchie a dans son code une logique multi objet.
J'avais regardé il y a (très) longtemps pour gérer ça pour un autre type d'objet et cela semblait jouable sans trop de galère.
Km
Si l'architecture de tous ces classements correspond déjà à ça, oui, de mon point de vue ça parait plus logique d'utiliser Polyhiérarchie qui est méga éprouvé et qui sert à ça depuis des années, plutôt que de recoder en fait 100% la même chose que Polyhiérarchie dans un autre objet. En terme de structure, tout est déjà là et d'après moi c'est ça qui est important à maintenir. Ensuite on peut toujours améliorer l'interface, personne n'est contre je crois…
Et là, pour l'interface, ce qui manque pour moi, c'est que Polyhiérarchie a toujours son exception dans sa table de lien (ça utilise id_parent au lieu de id_rubrique) et donc l'API des liens du noyau ne reconnait pas la table, ce qui ne facilite pas le même type de "bloc de liaison" habituel. Si on pouvait avoir le bon nom du champ (ou si l'API des liens permettait d'avoir le nom qu'on veut !) ça permettrait pas mal de facilités ensuite…