[spip-dev] API Objet et id_parent

Hello,

Un petit sujet sur l’API objet que je me permets de remonter car je ne sais pas si c’est l’usage prévu ou pas.

J’ai un objet arborescent qui n’est pas une rubrique mais donc qui possède un id_parent pour structure sa hiérarchie.
Pour créer l’objet deux solutions :

  • formulaire classique, formulaire_editer_objet_traiter, qui appelle l’action editer_objet, qui elle-même appelle objet_insérer()
  • ou on appelle objet_insérer() en passant le $set.
    Dans les deux cas, si je veux mettre à jour id_parent il faut passer par le pipeline pre_insertion et on récupère l’id_parent soit avec _request() soit dans le pipeline [‘args’][‘id_parent’]

Pour modifier l’objet et en particulier son id_parent là ça se complique :

  • via le formulaire on arrive à objet_modifier qui ne fait rien car id_parent se fait par instituer et donc passe la main à objet_instituer avec un $c qui contient bien la saisie du nouvel id_parent.
    Or dans objet_instituer l’id_parent n’est considéré que si je suis en présence d’un objet rubrique. Qu’à cela ne tienne il reste le pipeline pre_edition et la récupération de l’id_parent par le _request() qui permet de forcer la modification
  • mais alors si j’appelle objet_modifier() ou objet_instituer() pour modifier directement l’id_parent, cela ne peut pas marcher car l’id_parent n’est jamais passé à aucun pipeline comme cela est fait dans l’insertion.

En conclusion, on ne peut pas modifier l’id_parent autrement que via un formulaire. Est-ce voulu ? Est-ce que mon raisonnement est incorrect ?

A vous lire.

J’ai eu le même problème (en développant un plugin sur des organigrammes) et j’ai fini par renoncer à la dénomination id_parent. Ce serait bien - comme l’indique Éric - de rendre id_parent plus universel qu’un usage aux rubriques d’autant plus que SPIP c’est la force des objets éditoriaux (et donc de leur hiérarchie).

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

Cela dit je ne crois pas que ça soit pris en compte nativement dans SPIP 3.3-dev actuellement, mais peut être uniquement avec https://git.spip.net/spip-contrib-extensions/declarerparent

En tout cas c’est quelque chose qu’il faudrait prendre en compte là où tu indiques.

MM.

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. :slight_smile:

Re,

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. :slight_smile:

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.

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.

Il n'y a pas de "côtés". Le fait d'avoir *son propre même objet* comme parent possible, est uniquement un cas particulier du fait d'avoir un parent. Voilà pourquoi c'est la même chose, ça va ensemble, à gérer dans la même API, les mêmes fonctions. Et comme dit dans le fil (et c'est ce que fait déjà toute l'implémentation dans declarerparent), il n'y a pas forcément à déclarer explicitement dans la définition de l'objet, pour les cas simples, ça gère déjà magiquement, dont le fait d'avoir un champ "id_parent".

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.

Que ce soit soi-même (le même objet) ou un autre objet, les utilisations sont les mêmes : gérer le champ pour dire quel est le parent durant l'édition, les hiérarchies, les URL, les duplications, et plein d'autres.

Yop,

Il n’y a pas de « côtés ». Le fait d’avoir son propre même objet comme parent possible, est uniquement un cas particulier du fait d’avoir un parent. Voilà pourquoi c’est la même chose, ça va ensemble, à gérer dans la même API, les mêmes fonctions. Et comme dit dans le fil (et c’est ce que fait déjà toute l’implémentation dans declarerparent), il n’y a pas forcément à déclarer explicitement dans la définition de l’objet, pour les cas simples, ça gère déjà magiquement, dont le fait d’avoir un champ « id_parent ».

Je ne suis pas du tout d’accord.
On ne pas considérer qu’un lien de parenté qui définit une arborescence est un cas d’usage d’un lien d’appartenance qu’on souhaite assimiler à une parenté sur certaines actions.

Alors oui, je vois bien l’intérêt quand on dit je crée un article dans une rubrique.
On peut dire je crée un objet fils ou l’article appartient à la rubrique.
Dans le cas des rubriques c’est plus ambigu car on a le choix le lien est une appartenance ou une parenté: on crée une rubrique fille ou un rubrique qui appartient à une autre ?

Mais un lien d’appartenance ne crée pas de hiérarchie (ou très plate, donc sans intérêt).
Et donc si mon objet hiérarchique, comme une rubrique, appartient à un objet X, je fais comment pour distinguer le père et le conteneur (au sens de l’appartenance) ?
En résumé, je trouve qu’en amalgamant la notion de conteneur et la notion de hiérarchie on fait une erreur de modélisation et on s’interdit d’avoir les deux sur un même objet.

Je ne sais si j’ai été clair ?
En tout cas, je ne pense pas que ce soit aussi limpide que tu le prétends.

Je ne suis pas du tout d'accord.
On ne pas considérer qu'un lien de parenté qui définit une arborescence est un cas d'usage d'un lien d'appartenance qu'on souhaite assimiler à une parenté sur certaines actions.

Je n'ai pas vraiment compris cette phrase. :stuck_out_tongue:

Mais arborescence, hiérarchie, appartenance, parenté, tout ça ce sont des *synonymes*. La différence est tellement infime et subjective, que ce serait beaucoup trop confus pour les utilisateurs finaux de leur dire "l'un veut dire ça mais l'autre c'est plutôt ça", alors que dans le langage courant, suivant les contextes, ça veut à peu près dire la même chose. Le fait d'avoir un parent principal crée une hiérarchie, une arbo.

Mais un lien d'appartenance ne crée pas de hiérarchie (ou très plate, donc sans intérêt).

Si.

Qu'est-ce que t'en sais que l'objet enfant n'est pas lui-même possiblement parent d'autres enfants ?

Rien qu'avec les objets courants avant même "declarerparent" on a : un événement est dans un article qui est dans une rubrique qui peut être dans une rubrique. TOUT ça est une hiérarchie.

Et donc si mon objet hiérarchique, comme une rubrique, appartient à un objet X, je fais comment pour distinguer le père et le conteneur (au sens de l'appartenance) ?

Ça n'existe juste pas.
Toute l'API "parent" ne travaille que sur la parenté *directe* ou *principal* = un contenu ne peut avoir qu'un seul parent principal.

En revanche il peut y avoir plusieurs *méthodes* de recherche du parent pour un même objet (objet-id_objet ET id_parent). Mais pour tel contenu précis, lui n'a qu'un parent principal, celui prioritairement trouvé. Et c'est ce que fait l'API parent, on peut déclarer plusieurs méthodes à la fois, c'est le cas pour les forums.

Pour une rubrique, c'est une rubrique (ou rien et donc secteur).
Pour un article c'est une rubrique.
Pour un événement c'est un article.

Pour un forum c'est SOIT n'importe quel objet SOIT un autre forum (et ça ne PEUT PAS être les deux à la fois, il n'y a qu'un seul parent direct).
Pareil pour l'objet "chapitre" du plugin éponyme qui a une structure similaire aux forums (un chapitre est soit à la racine d'un autre objet, un article, un devis, que sais-je, soit un sous-chapitre d'un chapitre, mais ça ne peut pas être les deux, il n'y a qu'un parent principal).

En tout cas, je ne pense pas que ce soit aussi limpide que tu le prétends.

Moi si. :stuck_out_tongue:

Oui, je comprends ce que dit Eric, même si le cas est peu commun.

Il suffit d’imaginer que les articles soient hiérarchisés aussi avec un champ id_parent (et en plus de id_rubrique) pour être un peu perturbé.

Il y a une contrainte à introduire : le id_rubrique doit être le même pour tous les articles enfants d’un article, sinon ça sonne bizarre.

Et à ce moment là tu peux dire le parent est :

id_parent > 0 => article / id_parent
id_parent = 0 => rubrique / id_rubrique

Peut être que Eric peut considérer cela comme le parent «principal» ?

Mais si tu peux ranger chaque article enfant dans une rubrique quelle quelle soit, c’est plus difficile de déterminer qui est le parent… la rubrique parente ou l’article parent ?

Ça me semblerait compliquer beaucoup les choses, de gérer ça (et comment ?), pour une utilité toute relative, non ?

MM.

Et à ce moment là tu peux dire le parent est :

id_parent > 0 => article / id_parent
id_parent = 0 => rubrique / id_rubrique

Mais c'est ce que fait l'API parent depuis le début ! cf tous mes liens d'exemples précédent…

Mais si tu peux ranger chaque article enfant dans une rubrique quelle quelle soit, c’est plus difficile de déterminer qui est le parent… la rubrique parente ou l’article parent ?

Je ne vois même pas ce que ça voudrait dire, et pour moi ça n'a aucun sens sauf à parler de poly-hiérarchie justement, si yen a plusieurs. Mais l'API parent se contente de gérer uniquement la parenté *directe/principale*, comme déjà dit. Et il n'y a donc qu'un unique parent possible à un instant T pour un contenu précis.

Yop,

Le 31/03/2020 à 15:38, Eric Lupinacci a insisté
sur la distinction entre la notion de conteneur et la notion de hiérarchie.

Ça me rappelle effectivement de vagues souvenirs des ambiguités dans la notion de "parent";
et par ailleurs des difficultés irréductibles à intégrer dans quels sens marchent les liens d'une table objet_liens
et aussi la notion de portfolio pas mauvaise en elle-même mais totalement pourrite par l'incohérence de l'UI.

+1 Assainissement et renforcement du noyau
+1 Être compréhensible et pas couper les cheveux en 42 pour des cas rares
+1 Des plugins pour aller plus loin
+1 Pas faire des rubriques, des forums et des groupes de motclés des cas particuliers

Et donc
+4 un noyau sain et fort mais pas totalement polyvalent,
et déléguer à un plugin les raffinements et perfections rarement utiles
Reste à définir lesquelles !

JL