Re: API Objet et id_parent

Re,

Le mar. 31 mars 2020 à 12:18, RastaPopoulos <[email protected]> a
écrit :

> Le 31/03/2020 à 10:38, Matthieu Marcillaud a écrit :
> > Alors c’est tout l’intérêt de la déclaration de parent qui a été ajouté
> dans la déclaration d’objet éditorial.
> > https://core.spip.net/issues/3844
>
> Et pour le cas simple sans déclaration, juste parce qu'on détecte qu'il y
> a un champ "id_parent", j'avais commencé un diff :
> https://core.spip.net/issues/3844#note-16
>
> Mais comme expliqué, j'ai pas commité car c'était mieux de réfléchir à
> long terme avec la déclaration complète. Déclaration et API qui ont été
> implémentées entièrement dans le plugin declarerparent, et qui permettent
> de connaitre dans les deux sens les parents et les enfants. D'après moi à
> intégrer au core évidemment. :)
>
>
Oui soit.
Mais je ne vois pas trop l'intérêt ni la raison de grouper les deux
problématiques liées à la "parenté".
On a d'un coté un objet arborescent qui utilise id_parent pour structurer
sa hiérarchie propre.
Et de l'autre des objets différents qui sont regroupés dans un même objet
de regroupement qu'on appelle "parent" ce qui permettrait de définir une
"hiérarchie" entre ces objets et l'objet parent (à un niveau donc ?), un
peu comme dans le plan du site.

Si ma description est juste je ne vois pas sémantiquement ce qui oblige à
considérer une évolution conjointe.

Dans le premier cas on a juste à considérer que les rubriques ne sont pas
les seuls objets arborescents et en déduire les modifications dans l'API
objet (instituer et les pipelines d'édition à priori) voire ailleurs (je ne
sais pas si le fameux ticket en fait état). On a pas besoin de définir une
nouvelle déclaration car id_parent suffit déjà comme pour les rubriques.

Dans le deuxième cas c'est une nouvelle déclaration dont je ne vois
l'utilité que pour la boucle hiérarchie (mais j'ai pas creusé) mais qui est
bien différente du premier cas. On pourrait très bien avoir un objet
arborescent inclus dans un objet d'un autre type.

Donc je pense qu'il faudrait couper les besoins en deux et avancer
indépendamment sur les deux.

++
Eric