Bonjour à toutes et à tous,
TL;DR
J’utilise les nouvelles facultés du core pour les déclarations de parenté des objets. Je m’interroge sur l’utilisation optimale de cette API pour créer une navigation cohérente, notamment en ce qui concerne la boucle Hiérarchie. Le potentiel semble immense, ouvrant un débat sur le plugin Polyhiérarchie versus l’API de parenté et le besoin d’une hiérarchie principale pour certains usages comme la création d’urls arborescentes. Comment exploiter au mieux ces fonctionnalités ? Mes exemples de déclaration de parents sont-ils valides ? Est-on en train finalement d’intégrer un Polyhiérarchie générique dans le core de SPIP ?
Je viens de tester, avec joie, la capacité native de SPIP à permettre via l’API d’édition d’objets de déclarer des parents pouvant être d’autres types d’objets.
Dans mon cas 3 objets s’emboîtent : région > département > ville
En jouant avec les options des urls_etendues j’obtiens même des urls arborescentes parfaites pour chacun de mes objets :
$GLOBALS['url_arbo_parents']=array(
'departement' => array('id_region', 'region'),
'ville' => array('id_departement', 'departement')
);
C’est le paradis ! Ca ouvre le champ des possibles !
Mais que puis-je encore faire avec cette nouvelle API de parenté ?
La boucle hiérarchie
La boucle Hiérarchie s’attaque aux arborescences de rubriques, soit. Mais dans le cadre d’objets variés parents ou enfants les uns des autres, elle devient de fait inopérante.
Sur le public, on peut toujours recoder des fils d’ariane à la main selon les différents cas de parentés connus, mais pour le privé que préconisez-vous : faut-il surcharger dans ses plugins objets via …/prive/echafaudage/hierarchie/objet.sans_rubrique.html ?
En même temps, quand je vois mes urls arborescentes apparaître (via urls_etendues), j’ai comme l’impression que le travail est déjà fait quelque part : urls_etendues étant bien capable de retracer toute une lignée de parenté avec n’importe quels objets pour produire une url arborescente.
Ne pourrait-on pas mutualiser/utiliser ce qui a déjà été fait sur url_étendues pour reproduire des lignées complètes (fils d’ariane) multi-objets ?
La Polyhiérarchie VS l’API de parenté
Pour d’autres objets éditoriaux, j’utilise abondamment les capacités de Polyhiérarchie pour classer des objets comme des « personnes » ou des « objets » dans des rubriques multiples.
Dans le cas de l’API de parenté, le besoin couvert est le même que pour les Polyhiérarchies, mais ici on est agnostique de tout concept de rubrique, donc générique.
En me basant sur le ticket Documenter l’API de parenté et ses sources référencées, je (crois) comprendre plusieurs choses :
-
la déclaration de parent sur l’API objet est un tableau de tableau, elle permet donc de déclarer plusieurs types de parents possibles pour un même objet.
-
on lit aussi dans la merge request 71 que l’API « intègre la gestion des tables de liens en parenté »
=> je comprends que l’on peut s’affranchir d’une colonne id_clefétrangère sur la table d’un objet et plutôt aller taper dans une table de liens générique (avec un couple objet | id_objet et optionnellement une condition spécifique comme un rôle par exemple) pour retrouver les parents de l’objet. -
autre corollaire, on pourrait donc pour déterminer le parent d’un objet soit :
- se baser sur une clef étrangère présente sur la table de l’objet, c’est le cas le plus simple
ex. : id_race sur mon objet Chien avec dans la déclaration de l’objet :
$tables['spip_chiens']['parent'] = array(
'type' => 'couleur_robe',
'champ' => 'id_couleur_robe',
);
- se baser sur une table de liens (+ une condition optionnelle)
ex. : une table spip_chiens_liens
id_chien (18) | objet (« couleur_robe ») | id_objet (3) | role (« parent »)
id_chien (18) | objet ( « centres_spa » ) | id_objet (6) | role (« parent »)
Avec dans la déclaration de l’objet :
$tables['spip_chiens']['parent'] = array(
'table' => 'spip_chiens_liens',
'source_champ' => 'id_objet',
'champ_type' => 'objet'
'table_condition' => 'role="parent"',
);
Permettant à la fois d’indiquer à la fois que le Chien 18 a pour parent la couleur de robe n°3 ainsi que le centre SPA n°6.
- se baser à la fois sur une clef étrangère ET sur une table de liens :
$tables['spip_chiens']['parent'] = array(
# Parenté sur clef étrangère depuis table objet
'type' => 'race',
'champ' => 'id_race',
# Parenté depuis table de liaison :
'table' => 'spip_chiens_liens',
'source_champ' => 'id_objet',
'champ_type' => 'objet'
'table_condition' => 'role="parent"' // Condition optionnelle de parenté
);
Permettant d’obtenir les parentés :
a) race > chien
b) couleur de robe > chien
c) centre SPA > chien
N’aurait-on pas créé une Polyhiérarchie ici !?
Avant de s’enflammer, quelqu’un saurait-il confirmer ou infirmer mon raisonnement et la validité des exemples de déclarations données ?
Enfin,
Pour qu’il puisse y avoir un fil d’Ariane principal, il faut déterminer une parenté principale…
Je soulève un autre sujet qui est lui aussi adressé par Polyhiérarchie : la hiérarchie principale est déterminée par l’id_rubrique/id_parent directement présent sur la table de l’objet traité. Et les liaisons secondaires sont traitées sur la table de liens spip_rubriques_liens.
En remontant les tickets liées à l’API de parenté, je comprends que ce sujet a lui aussi été débattu et je crois comprendre que la parenté principale est aujourd’hui « simplement » le premier éléments de parenté rencontré par l’API, donc celui que l’on déclare en premier dans l’API des objets éditoriaux ?
J’ai comme la forte impression que la parenté principale aurait pu être déterminée directement au niveau de l’objet, c’est partial certes, mais aussi simple et justifiable, car la parenté forte est logiquement au plus proche de l’objet.
Mais mon cœur balance pour plus de souplesse, et je me demande s’il n’aurait pas été possible de « simplement » ajouter une propriété « parenté principale » dans la déclaration de l’objet ou encore de disposer de deux tableaux distincts de parenté ; principale et secondaire ?
Exemple :
$tables['spip_chiens']['parent'] = array(
'parent_principal' => array(
# Parenté sur clef étrangère depuis table objet
'type' => 'race',
'champ' => 'id_race'),
'parents_secondaires' => array(
# Parenté depuis table de liaison :
'table' => 'spip_chiens_liens',
'source_champ' => 'id_objet',
'champ_type' => 'objet'
'table_condition' => 'role="parent"' // condition optionnelle de parenté
)
);
Ne serait-on pas proche ici d’intégrer complètement au core de SPIP l’approche de Polyhiérarchie de manière 100% générique ?
Je passe ici sur toutes les fonctionnalités de Polyhiérarchie liées à la découverte des parents/enfants directs/indirects et du calcul des branches par profondeur, ou encore des sélecteurs génériques pour lier tous ces objets entre-eux, etc. Mais, ne serait-ce pas déjà un énorme pas de franchis ?
Bravo aux valeureuses et valeureux qui sont arrivés au bout. Au plaisir d’échanger avec vous autour de cette API passionnante et de ses perspectives futures.
Bien à vous,
Pierre-Jean
PS : désolé Polyhiérarchie, je ne veux pas ta mort mais ta mue, tu as toujours fait partie de mes préférés, il est maintenant temps de jouer dans la cours des grands.
