Projet

Général

Profil

Roadmap #3844

Gérer la parenté dans la déclaration d'un objet éditorial.

Ajouté par marcimat 🌈 il y a environ 2 ans. Mis à jour il y a 2 mois.

Statut:
En cours
Priorité:
Normal
Assigné à:
-
Catégorie:
compilo
Version cible:
Début:
23/10/2016
Echéance:
% réalisé:

0%


Description

Cf. la proposition d'ajouter :

'parent' => array('type' => 'rubrique', 'champ' => 'id_rubrique'),

Cela permettra donc de gérer mieux différents codes dans SPIP (hiérarchies, parents sur formulaires d'édition, urls arborescentes).

Voir : #2842 , #2743

editer_objet_parent.diff Voir (937 octets) RastaPopoulos ♥, 27/02/2018 16:20


Demandes liées

Lié à SPIP - Evolution #2842: Gestion unifiée du champ id_parent pour les objets dans les rubriques (API objet_get_rubrique) Nouveau 05/09/2012
Lié à SPIP - Anomalie #2743: Un objet ayant un champ id_parent ne peut l'enregistrer via action/editer_objet.php En cours 01/06/2012
Lié à Mots - Evolution #4151: Le bouton de création rapide d'un mot ne sélectionne pas le groupe en cours du mot Fermé 14/06/2018

Historique

#1 Mis à jour par marcimat 🌈 il y a environ 2 ans

  • Lié à Evolution #2842: Gestion unifiée du champ id_parent pour les objets dans les rubriques (API objet_get_rubrique) ajouté

#2 Mis à jour par marcimat 🌈 il y a environ 2 ans

  • Lié à Anomalie #2743: Un objet ayant un champ id_parent ne peut l'enregistrer via action/editer_objet.php ajouté

#3 Mis à jour par cam.lafit - il y a environ 2 ans

Salut

En généralisant cette approche est ce que cela bloque le cas où le parent n'est pas une rubrique ?

#4 Mis à jour par marcimat 🌈 il y a environ 2 ans

C'est justement le but. Parce que le cas où le parent est une rubrique, on sait déjà à peu près le gérer (en considérant que si la table a un champ 'id_rubrique' ou 'id_parent' alors son parent est une rubrique). C'est justement si on souhaite dire autre chose qu'on est ennuyé.

#5 Mis à jour par nicod_ 🐿 il y a plus d'un an

Complètement d'accord, et on en aurait bien besoin pour avancer sur le plugin Rang.

Il faudrait pouvoir gérer aussi un objet qui serait son propre parent.

Exemple : une poupée russe dont l'objet parent serait une autre poupée russe :

'parent' => array('type' => 'matriochka', 'champ' => 'id_matriochka_mere'),

#6 Mis à jour par cam.lafit - il y a plus d'un an

Salut

Si cela permet aussi de gérer les objets orphelins ça serait bien. Tout les
objets n'ont pas besoin d'avoir de parent. On peut voir le cas avec le
plugin page qui contourne ce comportement.


'parent' => array('type' => 'rubrique', 'champ' => 'id_rubrique',
'requis' => [obligatoire,option,non] ),

#7 Mis à jour par nicod_ 🐿 il y a plus d'un an

Où est ce que tu vois ce code ? je n'en trouve aucune trace sur la zone.

#8 Mis à jour par nicod_ 🐿 il y a plus d'un an

Bon, qu'est ce qui gênerait d'entériner cette spécification, et de l'implémenter dès maintenant ?
On ajouterait juste les clés 'parent' dans les définitions des tables adéquates (articles, rubriques, forums, autres ?)

On ne touche pas au code pour l'instant, ça ne casse rien mais on a au moins une information utilisable.
Ça permettrait déjà de l'utiliser dés maintenant dans des plugins (fabrique, rang...) ou des squelettes.
Ensuite on reprend par étapes le code de HIERARCHIE, et le reste.

Qu'en pensez vous ?

#9 Mis à jour par Peet du il y a plus d'un an

À lire les tickets ici et retours sur le forum Dev, je ne vois que des demandes, attentes et retours positifs.

On ajouterait juste les clés 'parent' dans les définitions des tables adéquates (articles, rubriques, forums, autres ?)
On ne touche pas au code pour l'instant, ça ne casse rien mais on a au moins une information utilisable.

ben...go go go :)

#10 Mis à jour par RealET 🔸 il y a plus d'un an

À mettre en relation avec #3976 pour le bouton de création rapide d'un mot clé

#11 Mis à jour par Peet du il y a environ un an

Pour info : j'ai implémenté cette idée dans le plugin RANG.
À l'usage c'est effectivement génial.

voir

déclaration : https://zone.spip.org/trac/spip-zone/browser/_plugins_/rang/trunk/rang_pipelines.php#L36
utilisation : https://zone.spip.org/trac/spip-zone/browser/_plugins_/rang/trunk/inc/rang_api.php#L201
utilisation #2 : https://zone.spip.org/trac/spip-zone/browser/_plugins_/rang/trunk/action/trier_items.php#L39

Keskon attends pour être heureux ?

#12 Mis à jour par nicod_ 🐿 il y a environ un an

Ça parait bizarre ce que tu fais là :
https://zone.spip.org/trac/spip-zone/browser/_plugins_/rang/trunk/inc/rang_api.php#L208
$id_objet.' = '.$id_objet

#14 Mis à jour par nicod_ 🐿 il y a environ un an

Un plugin minimaliste pour déclarer les parents, à compléter au fur et à mesure.
https://zone.spip.org/trac/spip-zone/changeset/107036

#15 Mis à jour par nicod_ 🐿 il y a environ un an

Discussion sur IRC, sur la gestion de plusieurs types de parents pour un objet :

03/11 _ 17:25:54 jluc les objets ne peuvent avoir qu'une seule sorte de parents ?
03/11 _ 17:26:22 jluc les articles peuvent être dans des rubriques mais dans des grappes aussi
03/11 _ 17:26:27 nicod_ c'est à discuter
03/11 _ 17:27:22 RastaPopoulos faut forcément un parent principal
03/11 _ 17:27:31 RastaPopoulos puisque c'est le but de l'utiliser pour les hiérarchies, etc
03/11 _ 17:36:33 nicod_ mais peut être d'autres parents possibles (secondaires) ? à discuter, je n'y ai pas réfléchi plus que ça
03/11 _ 17:47:12 jluc un seul type de parent ça permet surement de simplifier les traitements centraux
03/11 _ 17:47:29 jluc ceux les plus au coeur de spip
03/11 _ 17:51:11 peetdu hmmm...pas l'habitude des forums. Ce serait quoi le parent ?
03/11 _ 17:51:23 peetdu l'article ?
03/11 _ 17:52:25 peetdu ah ben ça peut être n'importe quel objet en fait
03/11 _ 17:54:32 nicod_ un type de parent principal oui, pour des types secondaires je ne sais pas, il peut y avoir un usage (ou pas)
03/11 _ 17:56:29 RastaPopoulos c'est un peu l'idée dans polyhier
03/11 _ 17:56:48 RastaPopoulos ya une rubrique principal et ensuite des classements secondaires
03/11 _ 17:57:11 RastaPopoulos mais pour l'API de déclaration de parents, je ne saisis pas trop ce que signifierait les secondaires, et dans quels cas d'utilisation réels ça serait utilisé

#16 Mis à jour par RastaPopoulos ♥ il y a 10 mois

Hello,
j'ai possiblement besoin de rajouter la prise en compte directe du champ "id_parent" s'il existe lors de la création, qui est un cas vraiment simple et bateau, qui est donc détectable sans déclaration spéciale, lors de la création d'un objet quelconque.

Actuellement objet_inserer() peut lui passer une variable générique nommée $id_parent, mais en fait dedans la fonction ne gère que le cas si y a un champ "id_rubrique" pour cet objet. Du coup j'ai ajouté le cas encore plus simple où ya un champ "id_parent", càd quand l'objet est parent de lui-même (comme les rubriques).

Mais finalement je n'ai rien commité, car je me suis dit que ça rentrait dans la réflexion plus générale de ce ticket, et que mon petit bout de code devra bien être utilisé mais à l'intérieur d'un code plus large utilisant la déclaration explicite si elle existe. Je mets le diff de ma modif quand même pour historique.

En gros pour moi dans objet_inserer(), c'est toute la partie qui teste si ya "id_rubrique" + mon ajout qui teste "id_parent" qui devrait être recodé avec cet algorithme :
1) s'il y a un déclaration de parentée explicite, on l'utilise et on essaye de remplir les bons champs et la langue avec ça
2) s'il y a un champ "id_rubrique" on remplit magiquement
3) s'il y a un champ "id_parent" on remplit magiquement

Pour le 2) et 3), je ne sais pas si ça doit être à chaque fois en ajout, ou bien en "elseif", càd seulement si le cas précédent n'existe pas ! Il faudra le décider.

En attendant qu'on statue sur tout ça, je vais me débrouiller avec le pipeline "pre_insertion" pour lequel j'ai rajouté l'information "id_parent" tout à l'heure, car ça du coup je l'ai mis aussi en 3.2 puisque ça ne changeait rien…

#17 Mis à jour par RastaPopoulos ♥ il y a 9 mois

J'ai continué dans la réflexion, ayant besoin de parent et enfants dans le plugin Duplicator. J'ai expliqué différents problèmes dans la liste Zone, mais pour pas le perdre, je vais copier ça dans ce ticket.

Proposition de deux fonctions d'API génériques

À 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

Un parent direct dont l'objet n'est pas fixe

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.

Un parent encore plus compliqué avec deux cas à tester pour le même contenu

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 :)

#18 Mis à jour par RastaPopoulos ♥ il y a 9 mois

Ok, j'avance dans ma réflexion.

Cas simple où le type du parent est connu d'avance

'parent' => array('type' => 'rubrique', 'champ' => 'id_rubrique')

Proposition pour le cas où le type est variable

'parent' => array('champ_type' => 'objet', 'champ' => 'id_objet')

Proposition pour le cas complexe où le parent dépend de conditions ! Exemple : les forums

'parent' => array(
    array('condition' => 'id_parent=0', 'champ_type' => 'objet', 'champ' => 'id_objet'),
    array('condition' => 'id_parent>0', 'type' => 'forum', 'champ' => 'id_parent')
)

Au vu de la dernière proposition, je me demande si le parent ne devrait pas toujours être un tableau de tableaux, même quand il n'y a qu'un seul cas.

Cela éviterait de devoir tester plusieurs cas possible, dans les utilisations, on ferait donc toujours un "foreach" sur les parents. Et s'il n'y en a qu'un bah c'est tout, ça ne bouclera qu'une fois.

Ça ne me parait pas déconnant sachant qu'on utilise déjà ce principe pour la déclaration des statuts. Dans l'immense majorité des cas, il n'y a qu'un seul champ de statut, et pourtant c'est toujours un tableau de tableaux, car parfois ça peut être plus complexe.

'statut' => array(
    array( ’champ’ => ’statut’, ’publie’ => ’publie’, ’previsu’ => ’publie,prop,prepa’, ’post_date’ => ’date’, ’exception’ => ’statut’)
)

On reprendrait donc ce même principe et on aurait donc :

'parent' => array(
    array('type' => 'rubrique', 'champ' => 'id_rubrique'),
)
'parent' => array(
    array('champ_type' => 'objet', 'champ' => 'id_objet'),
)
'parent' => array(
    array('condition' => 'id_parent=0', 'champ_type' => 'objet', 'champ' => 'id_objet'),
    array('condition' => 'id_parent>0', 'type' => 'forum', 'champ' => 'id_parent')
)

Et voilà, avec ça je crois qu'on doit bien gérer 99% des cas !

Je vais implémenter ça dans le plugin "declarerparent" sur la zone, quitte du coup à devoir aller modifier le plugin Rang pour prendre en compte cette nouvelle écriture. Et du coup je vais l'utiliser dans le plugin Duplicator aussi, pour une autre vraie utilisation.

Ça valait le coup d'attendre et de trouver des cas réels d'utilisation avant d'officialiser une écriture, car avec les forums ou autre dans le genre, on tombe bien sur des cas tordus qu'il fallait résoudre.

#19 Mis à jour par RastaPopoulos ♥ il y a 9 mois

  • Statut changé de Nouveau à En cours

Et voilà, implémenté dans le plugin, il y a la nouvelle manière de déclarer, qui fonctionne donc aussi pour les forums :
https://zone.spip.org/trac/spip-zone/browser/_plugins_/declarerparent/trunk/declarerparent_pipelines.php

Et une API, ou plutôt deux API de 2x2 fonctions, une API pour les types, et une API pour les contenus précis :
https://zone.spip.org/trac/spip-zone/browser/_plugins_/declarerparent/trunk/base/objets_parents.php

Tout a l'air de fonctionner, et c'est assez magique !

objet_trouver_enfants('rubrique', 1) => array('article' => array(1, 2, 3), 'site' => array(1, 2, 3), 'chapitre' => array(1, 2, 3))

#20 Mis à jour par b b il y a 6 mois

  • Lié à Evolution #4151: Le bouton de création rapide d'un mot ne sélectionne pas le groupe en cours du mot ajouté

#21 Mis à jour par b b il y a 6 mois

Cet ajout permettrait aussi de résoudre #4151 de manière plus élégante que le patch que j'y ai proposé.

#22 Mis à jour par Peet du il y a 2 mois

Il faut aussi tester la prise en compte de cette nouvelle déclaration du parent dans :

  1. la balise #EXPOSE (voir https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/balises.php#L722)
  2. la boucle HIERARCHIE (voir https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/boucles.php#L58)

Faut-il ouvrir des tickets spécifiques ?

#23 Mis à jour par RastaPopoulos ♥ il y a 2 mois

Attention pour le 2 c'est pas mal plus compliqué : la boucle HIERARCHIE n'est qu'un alias de la boucle RUBRIQUES légèrement customisée, mais c'est uniquement une boucle RUBRIQUE. À moins de la casser complètement et revoir entièrement (y compris pour les appels) comment ça marche, je vois pas encore trop comment elle pourrait être multi-objets, générique (sans casser les milliers d'utilisation actuelles, qui attendent d'avoir les balises et même les critères qu'on peut ajouter en plus, des boucles de rubriques).

Ya des balises génériques #TRUC_ qui permettent de capter #TRUC_MACHIN, mais il faudrait peut-être, je crois pas que ça existe, une définition PHP de boucle "TRUC_" qui permet de capter tous les (TRUC_MACHIN). Ça permettrait en un seul code de définir toues les boucles (HIERARCHIE_PATATES).

Actuellement quand j'ai un objet arborescent, c'est ce que je fais, je définis une boucle similaire, mais à refaire à chaque fois :
https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/chapitres/trunk/chapitres_fonctions.php#L8

Mais en fait c'est con ce que j'ai, enfin ça peut servir, mais ya aussi plein de cas où on voudra désormais avoir la hiérarchie parente d'un truc sans savoir à l'avance son type d'objet… Donc va bien falloir trouver une manière de faire une boucle où on doit passer l'objet source en paramètre dynamique

Formats disponibles : Atom PDF