Re: API Objet et id_parent

RastaPopoulos <[email protected]>
Newsgroups gmane.comp.web.spip.devel
Message-ID <[email protected]>
Le 31/03/2020 à 13:47, Eric Lupinacci a écrit :
> 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".
https://git.spip.net/spip-contrib-extensions/declarerparent/src/branch/master/base/objets_parents.php#L181

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

-- 
RastaPopoulos
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.