Carnet Wiki

Version 5 — Juin 2018 YannX

Quand on parle « organigramme », les vieux informaticiens pensent « code spaghetti »,
et les autres : schema organisationnel Word.

Mais l’objectif est tout simple :
proposer une visualisation structurée arborescente à partir d’un fichier à plat !

SPIP fait déjà cela naturellement (nativement) pour les RUBRIQUES

 Et si on l’étendait ?

comment utiliser la puissance de SPIP
(d’une facon analogue à la boucle_n(HIERARCHIE{"RUBRIQUES",'id_rubrique','id_parent'}),
qui est un cas particulier de boucle_n(HIERARCHIE){ "RUBRIQUES",'id_rubrique','id_parent'} [1] !

Le besoin :

pouvoir partir d’un fichier « organigramme » à plat, transformé en table SPIP
comportant un champ (clé quelconque, par exemple dans mon cas une adresse mail)
qui serait spécifié pour servir de chainage clé étrangère réflexive
pour assurer le parcours de hiérarchie
(comme ’id_parent’ par rapport à ’id_rubrique’ dans la table RUBRIQUES).

On va supposer qu’il s’agit juste d’une administration bien hiérarchisée, donc pas de https://contrib.spip.net/Polyhierarchie , donc pas de rattachements fonctionnels, transversaux ni temps partiels partagés entre deux Services... ;-) !

On peut reprendre ce fonctionnement, pour l’exprimer comme le besoin de créer une sorte d’opérateur de recherche récursive, qui pourrait s’appliquer de facon générique à n’importe quelle table.

La mise en oeuvre idéale

on recharge complètement le fichier plat « SALARIES » en table,
on déclare un champ clé secondaire unique de chaque enregistrement (’mail_salarié’)
et son correspondant (’mail_superieur’) comme clé reflexive de parcours
=> la boucle B_n(HIERARCHIE{"SALARIES"}) /d’un type DATA spécifique ?/
permet un parcours récursif à partir de n’importe quelle valeur initiale de ’mail_salarié’ !

Cerise sur le gateau : on utilisera les possibilités de SPIP pour coder le modèle permettant même
de faire construire la carte heuristique .xml de l’organigramme calculé affichable sous FreeMind/FreePlane

Des solutions d’implémentation peut-etre ?

-  a) La boucle HIERARCHIE est déja disponible pour les rubriques :
comment étendre son paramétrage sur le modèle d’une boucle DATA pour pouvoir spécifier
les champs clé d’enregistrement et clé de rattachement au supérieur, dans la syntaxe SPIP
cf. // http://doc.spip.org/@boucle_HIERARCHIE_dist

-  b) On pense aussi au fonctionnement des Mots arborescents https://contrib.spip.net/Mots-arborescents ou https://contrib.spip.net/Groupes-de-mots-arborescents , ou bien les Rôles , la polyHierarchie ...

-  c) Peut-etre ce fonctionnement est-il déjà implémenté dans un plugin que je n’ai pas trouvé ?
Il y en a tellement dans Contrib ou sur la zone.... (comme https://contrib.spip.net/Plugin-Afficher-la-Zone )

-  d) le plugin Un Plugin Chapitre implémente en interne un fonctionnement de parcours arborescent analoque, depuis la révision 109506 ; serait-il possible de créer une/des fonctions qui appliqueraient ce cheminement arborescent de facon générique à une table, (de facon analogue à un template C++) par une simple expression déclarant [2] :

  • la table ciblée, portant sur tout objet (exemple les MOTS)
  • le champ identifiant, (par défaut id_objet ou la clé primaire)
  • le champ de même nature utilisé comme pointeur de parent (par défaut un champ nommé id_parent..)

-  e) au hasard de quelques lectures, je me note aussi https://contrib.spip.net/4909 : cette proposition décrit un processus pour intégrer des liens (sans récursion, mais juste en transversal) ; peut-etre que ce n’est alors qu’un cas particulier d’une récursion (qui n’aurait qu’un seul « dépendant »)...
à murir

Voila, si vous avez une idée.... merci de compléter cette page

Quelques références SPIP :
-  La Boucle HIERARCHIE,
et son implémentation actuelle http://doc.spip.org/@boucle_HIERARC...
-  La Boucle DATA, avec les exemples et [syntaxe->html" class="spip_url spip_out auto" rel="nofollow external">https://www.spip.net/fr_article6434.html] html ].  ; et le site dédié http://spip-loves-opendata.spip.net/la-boucle-data
-  les implémentations d’[itérateurs->https://code.
spip.net/autodoc/tree/ecrire/iterateur/]  :

  • [CONDITION->https://core.spip.net/projects/spip/repository/entry/spip/ecrire/iterateur/condition.php]
    -* [DATA->https://core.spip.net/projects/spip/repository/entry/spip/ecrire/iterateur/data.php]
    -* [POUR->https://core.spip.net/projects/spip/repository/entry/spip/ecrire/iterateur/pour.php]
    -* [SQL->https://core.spip.net/projects/spip/repository/entry/spip/ecrire/iterateur/sql.php]
    -* [PHP->https://core.spip.net/projects/spip/repository/entry/spip/ecrire/iterateur/php.php]]
    - les étapes dépréciées :
  • [critere_DATA_datasource_dist()->https://code.spip.net/autodoc/tree/ecrire/public/criteres.php.html#function_critere_DATA_datasource_dist]  : Utiliser directement le critère source
  • [critere_POUR_tableau_dist()->https://code.spip.net/autodoc/tree/ecrire/public/criteres.php.html#function_critere_POUR_tableau_dist]  : Utiliser une boucle (DATA)source tableau,#XX

Et quand on pense à toutes les utilisations d’exploration en arborescences hiérarchiques...