Le 01/03/2018 à 14:28, nicod_ a écrit :
> La parenté est donc déclarée au niveau de la structure même de l'objet,
> ça me semble suffisant non ?

Yep, ça je m'en souviens oui, mais à mon avis il faut aller stable et
plus abstrait que juste la déclaration dans l'objet, car
1) ça peut éventuellement changer
2) il faudrait pouvoir prendre en compte les cas courants magiquement
même quand ya pas eu de déclaration explicite (id_rubrique, id_parent…)
3) ça donne le parent d'un type d'objet pour remonter, mais ça ne donne
pas l'inverse, les enfants

Donc dans tous les cas il faudrait sûrement une fonction du genre
array objet_info_parent($objet)
dont l'algorithme serait :
- s'il y a une déclaration explicite, c'est ça qu'on utilise
- s'il y a un champ id_rubrique, on fait comme si ça avait été déclaré
avec la rubrique array(type=>rubrique, champ=>id_rubrique)
- s'il y a un champ id_parent, on considère que l'objet est arborescent
de lui-même, et donc comme si ça avait été déclaré comme ça
array(type=$objet, champ=>id_parent)

Mais je pense aussi une fonction cette fois un peu plus longue, qui
donnerait l'ensemble des enfants directs qu'on a réussi à trouver
array objet_info_enfants($objet)
dont l'algorithme serait :
- un tableau de résultats en static pour toujours faire qu'une fois par hit
- si $enfants[$objet] déjà rempli en renvoie
- sinon on boucle sur tous les objets déclarés
- pour chaque, si on trouve que l'objet peut avoir comme parent direct
le $objet qu'on cherche, alors on l'ajoute à son tableau des enfants
possibles
- donc soit si dans sa clé "parent" ya $objet, soit s'il a un
id_rubrique et qu'on cherchait pour "rubrique", soit s'il a un id_parent
et qu'on cherchait pour son type

Encore autre chose, je ne sais pas si c'est prévu, mais il faudrait
pouvoir gérer les cas où le parent direct (on parle bien toujours de
parentée directe, pas de liens multiples) peut être *n'importe quel
objet*. Dans ce cas, il y a les champs objet et id_objet directement
dans la table de l'objet.

Mais il y a encore plus compliqué, et c'est le cas pour mes Chapitres,
mais aussi le cas pour les Forums fournit par SPIP : le parent direct
peut être
- SOIT l'objet lui-même car il est arborescent avec un id_parent
- SOIT n'importe quel autre contenu SI ET SEULEMENT SI le champ
id_parent=0 !

C'est bien le cas pour les forums :
- le premier forum d'un fil a pour parent un objet SPIP, avec objet et
id_objet remplis dans sa table ET id_parent=0
- les sous-forums ont AUSSI gardé en mémoire objet et id_objet du forum
racine, mais avec id_parent rempli avec l'identifiant id_forum de leur
parent

Dans ce cas on ne peut pas se baser uniquement sur le fait que objet et
id_objet sont remplis. Le parent est un objet SPIP quelconque si objet
et id_objet remplis ET id_parent=0. Et dès que id_parent>0 alors le
parent direct est le même objet (forum, chapitre ou autre).

Bref ya des cas comme ça qui sont plus complexes, mais pourtant
légitimes, et en plus fournis dans la dist, maintenus par le core, donc
il faut savoir les gérer aussi.

Du coup pour conclure, j'ai pas forcément de solution directe pour la
déclaration générique qui doit intégrer le noyau au final, mais c'est
pour expliquer pourquoi peut-être, possiblement, il y aurait besoin d'un
pipeline dédié dans Duplicator pour gérer ces enfantillages compliqués
tant que dans l'API de parent c'est pas encore résolu.

En tout cas ça fait avancer la réflexion :)

-- 
RastaPopoulos

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à