Le 24/06/2020 à 11:39, cam.lafit a écrit :
> 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.

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…

-- 
RastaPopoulos

_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Répondre à