feat/enum2level

[J9rem]

Cette pull-request a pour objectif de créer un système de listes à plusieurs niveaux sans tout refaire dans YesWiki

Ceci est d'abord une pull-request draft, qui propose les améliorations en se basant sur des développements custom. Ne pas prendre le code proposé comme valide pour fusion tant que les spécifications ne sont pas validées. le code est d'abord proposé comme base de travail des spécifications qui peuvent invalider tout ou partie des modifications courantes.

Proposition de spécifications:

Spécifications pour les listes à deux niveaux

Auteurs:

JD: Jérémy Dufraisse

• [R01] : le niveau 1 DOIT être de type checkboxfiche, listefiche ou radiofiche qui pointe vers un formulaire qui contient les fiches de niveaux 1
• [R01.1] : le formulaire associé DEVRAIT contenir un champ EnumField qui pointe vers une liste ou un autre formulaire qui représente le niveau 2
• [R01.2] : la saisie des associations entre niveau 1 et 2 DOIT être faite par ce forumaire dédiée
• [R02] : un nouveau champ bazar DEVRAIT être créé pour permettre la définition des listes à deux niveaux
• [R02.1] : son nom dans les formulaires DEVRAIT être enumlevel2
• [R02.2] : la classe EnumLevel2Field DOIT étendre EnumField
• [R02.3] : la classe EnumLevel2Field DEVRAIT être un proxy vers le bon type parmi CheckboxEntryField CheckboxListField RadioEntryField RadioListField SelectEntryField SelectListField
• [R02.4] : un paramètre de type subtype DEVRAIT permettre de choisir le type de saisie dans le formbuilder afin de choisir à quel Field le champ EnumLevel2Field doit relier son proxy
• [R02.5] : le type enumlevel2 et son sous-type DEVRAIENT être correctement gérés par les facettes
• [R02.6] : le nom de la liste ou du formulaire associé DOIT être identique au nom de la liste ou du formulaire associé utilisé pour les listes de niveau 1
• [R03] : la liste de niveau 1 DEVRAIT être un champ standard de type CheckboxEntryField CheckboxListField RadioEntryField RadioListField SelectEntryField SelectListField
• [R03.1] : le champ enumlevel2 DOIT avoir un paramètre permettant de choisir le nom du champ associé dans le même formulaire pour le niveau 1
• [R03.2] : si le champ enumlevel2 n'a pas une valeur correcte pour le paramètre défini en [R03.1], il DOIT afficher un message d'erreur pendant la saisie des fiches
• [R03.3] : un autre paramètre de enumlevel2 DEVRAIT permettre de déterminer le nom du champ à utiliser dans le formulaire associé au niveau 1 (pratique pour différencier les champs multiples)
• [R03.4] : en l'absence de valeur pour le paramètre de [R03.3], ce DEVRAIT être le premier champ qui correspond qui est retenu
• [R04] : le niveau 1 DOIT être stocké normalement dans la fiche par le champ concerné
• [R04.1] : le niveau 2 DOIT être stocké normalement dans la fiche par le champ concerné (comme si c'était un EnumField standard)

JD : l'intérêt est qu'il n'y a rien à changer pour ce qui conerne l'affichage et le filtrage des données des fiches

• [R05] : lors de la saisie des fiches, un script javascript dynamique DOIT automatiquement mettre à jour la liste des valeurs possibles pour le second niveau
• [R05.1] : le script évoqué en [R05.1] peut être en VueJS (compatible versions 2 et 3)
• [R05.2] : le mode de saisie du niveau 2 DOIT être le même que les champs standards associés (checkbox,radio,list, par tags, drags and drop, cases à cocher, données externes, ...)
• [R05.3] : lors de l'enregistrement, les données DOIVENT être nettoyées pour s'assurer que le contenu du niveau 2 est bien associé au niveau 1 sinon, suppression de la valeur en trop
• [R06] : au niveau des filtres (facettes), une intéractivité DEVRAIT être mise en place (ou réactivée) pour ajuster en temps réel le nombre de fiches restantes pour les autres filtres
• [R06.1] : un nouveau paramètre de bazarliste DEVRAIT être créé pour choisir la règle entre les entrées d'un même filtre
• [R06.2] : le paramètre de [R06.1] PEUT s'appeler intrafilterrule
• [R06.3] : la valeur par défaut de intrafilterrule DEVRAIT être or
• [R06.4] : les valeurs possibles pour intrafilterrule DEVRAIENT être or ou and (et leur syntaxe en majuscule ou équilavent)
• [R06.5] comportement de la réactivité dans les filtres DEVRAIT être
  • intrafilterrule == or, pas de réactivité, comportement standard
  • intrafilterrule == et, activation de la réactivité
  • pour enumlevel2, activation de la mie à jour automatique du nombre de fiches pour le niveau 2, en fonction du niveau 1 dans tous les cas mais
    • si intrafilterrule == or, le nombre affiché correspond à toutes les fiches possibles en fonction du niveau 1
    • intrafilterrule == et, le nombre affiché correspond uniquement aux fiches possibles en fonction du niveau 1 et du niveau 2 déjà coché

JD: le reste du filtrage est déjà assuré par YesWiki pour les fonctions standards pour tous les templates

• [R07]: le niveau 1 PEUT être de type enumlevel2, ce qui permet de faire des listes à 3 niveaux avec toutes les informations stockées dans la fiche

---

Ce que fait la branche en l'état

• branche non fonctionnelle
• début de création d'un nouveau champ enumlevel2

Pour tester la branche en l'état

• modifier un formulaire en mode texte en ajoutant une ligne comme si c'était checkbox mais en mettant enumlevel2 à la place

[J9rem]

@mrflos je te propose dans le commentaire de tête de cette PR des spécifications pour des listes à deux niveaux (voir plus). Qu'en penses-tu ? J'ai l'impression avec ce que je propose que ça ne demande pas trop de modifications de YesWiki et que ça donne une structuration de formulaires imbriqués proche de LMS donc qui me paraît un fonctionnement fiable et facile à tester

[mrflos]

J'ai pas compris ce que c'est specs font et ce que c'est sensé faire... C'est pour pouvoir faire des facettes sur un champ d'une fiche associée, c'est cela?
Si c'est cela, il vaut mieux faire des modification au niveau des filtres et facettes plutot que sur l'intégrité des données, je pense. De créer des interdépendances forte au niveau des formulaires ca parait risqué, non?

[J9rem]

@mrflos l'idée est d'avoir une liste dont les valeurs de saisie possible se mettent à jour en temps réelle en fonction de ce qui est saisie dans la première liste.

Ca n'est pas de pouvoir faire des facettes sur un champ d'une fiche associée.

Comme ça concerne le mode de saisie, on ne peut pas modifier uniquement les filtres et facettes pour le faire car il faut bien nettoyer au préalable la liste des valeurs de niveau 2 pendant la saisie de la fiche (les filtres et facettes ne concernant que l'affichage)

L'interdépendance forte au niveau des formulaires existe déjà : module LMS ou listefichesliees donc je ne vois pas ce que ça rajouterait comme complexité de plus vu que c'est basé sur le même fonctionnement.

[EdmondAgate]

Là les specs deviennent trop techniques pour moi (hahah) mais je crois que ça correspond bien au besoin de pouvoir faire des interdépendances entre listes à la saisie :)

[mrflos]

@J9rem @EdmondAgate auriez vous des exemples (urls) avec ce genre de champs que je puisse mieux comprendre de quoi il s'agit?

[J9rem]

@mrflos nous n'avons pas encore d'exemple vu que ça n'est pas encore implémenté.

En quelques mots, l'usager qui remplit une fiche sélectionne une réponse dans la liste des régions. Une fois ce choix fait, la liste des départements se met à jour automatiquement et l'usager peut choisir un département qui fait partie de la région concernée.

C'est une liste à deux niveaux.

Est-ce que tu vois mieux le besoin ?

L'idée de la spécification est de faire un truc qui simplifie énormément la gestion des listes à deux niveaux de ce genre

[mrflos]

ok, mais ca se fait plutot en js ca, non?
En reprennant tes specs, concretement, à quoi ressemblerait la base? une liste de régions, une liste de département, et un formulaire bazar de liaison que serait rempli par le composant enumlevel2 ?

[J9rem]

ok, mais ca se fait plutot en js ca, non?

la saisie se fait effectivement en js MAIS pour que ça fonctionne bien et facilement , il faut un champ spécifique qui s'occupe de préparer les données comme il faut pour le js ET qui vérifie que les données sont correctes à l'enregistrement.

En reprennant tes specs, concretement, à quoi ressemblerait la base?

Que signifie le mot base pour toi ? le composant de base, un besoin de base, un début de travail, ... :thinking:

une liste de régions, une liste de département, et un formulaire bazar de liaison que serait rempli par le composant enumlevel2 ?

Ce serait plutôt:

• un formulaire "Région" avec un champ de type liste qui pointe vers la liste des départements.
• Une liste "départements"
• Des fiches du formulaire "Région", chaque région ayant les bonnes informations pour les départements
• un champ enumlevel2 qui permet de:
  • récupérer la liste des départements (et les informations concernant les régions) et fournit ceci au js pour que ça fonctionne en dynamique
  • ET assurer l'intégrité des données lors de l'enregistrement
  • ET qui reste parfaitement identifiable au niveau des facettes pour comprendre qu'il faut s'en occuper de façon différente dans les filtres (mise à jour automatique du nombre de fiches en fonction des cases cochées au niveau 1)

[mrflos]

par base c'était structure de la base de données, désolé c'était trop court, c'était lié à la question d’après sur ou sont stockées les données et tu y a répondu, merci!
je trouve cela quand meme compliqué cette proposition.. ca ne va pas etre facile de créer une liste à 2 niveaux pour des usager.es qui ne sont pas geeks....

Serait il pas plus simple de faire des gris gris pour les listes genre pour les labels des listes rentrer par exemple pour listeDepartements :

clé: 26 label : <span data-region="aura">Drome</span> 
clé: 13 label : <span data-region="paca">Bouches du rhone</span> 

Et faire un js pour que si une region est selectionnée, il filtre?

[J9rem]

ca ne va pas etre facile de créer une liste à 2 niveaux pour des usager.es qui ne sont pas geeks....

ce que tu proposes n'est pas plus simple non plus par contre, ça ne me semble pas vraiment très standard comme façon de faire et on perd le côté sémantique contrairement à la saisie par formulaire.

[mrflos]

Perso, je trouve cela bien plus simple d'avoir un petit code à copier/coller plutot que d'avoir un formulaire à créer, puis rentrer les valeurs qui vont bien, puis modifier un formulaire et rajouter un champ enum spécifique qui faudra configurer avec les bons champs.

[J9rem]

Cette PR ne rassemble pas les conditions nécessaires pour démarrer en particuliers l'établissement de discussions préalables pour définir la mise en place de la présente PR; Je clos donc cette PR et supprimer la branche associée pour éviter de polluer la liste des PR en cours.

[acheype]

Perso, je trouve cela bien plus simple d'avoir un petit code à copier/coller plutôt que d'avoir un formulaire à créer, puis rentrer les valeurs qui vont bien, puis modifier un formulaire et rajouter un champ enum spécifique qui faudra configurer avec les bons champs.

salut @mrflos je ne sais pas si tu as pris le temps de tester le module 2levels, mais l'ayant testé sur un projet, je trouve qu'elle fait bien le job. ça fonctionne soit avec des listes ou des formulaires et je trouve que c'est finalement assez simple à configurer (tout en graphique).

je me dis que cette extension commence à être suffisamment mature et mériterait d'intégrer le cœur. c'est sûr que c'est plus complexe que certaines bidouillles js mais avec de telles bidouilles on serait trop limité et ce n'est pas adapté à monsieur tout le monde... bref maintenant qu'on peut tester et voir le code, quel est ton avis ?

[mrflos]

Hello @acheype , j'ai pas testé récemment mais à l'époque l'interface n'était pas évidente pour moi (alors j'imagine meme pas pour un non informaticien), mais le prochain sprint sera l'occasion d'en discuter avec la communauté.
Je pense qu'il faut voir le cœur de YesWiki comme un endroit à maintenir le plus propre possible, et quand il y a des ajouts fonctionnels à faire pas juste bricoler la feature, mais penser concrètement à comment l'intégrer pour que cela améliore globalement l'outil. Je suis d'accord que les listes à 2 niveaux seraient un plus, mais je proposerai de plutôt revoir globalement le fonctionnement des listes de données dans bazar pour éviter les listes, listefiches, listesexternes, checkbox, tags, etc... et proposer une interface unifiée pour soit des listes à un niveau, soit à plusieurs niveaux avec un constructeur graphique pour gérer ces niveaux (et en profiter pour ouvrir les sources possibles pour ces données geojson d'umap, api data.gouv.fr, wikidata, etc,...).
Si le modèle de données est fait proprement à ce niveau là, c'est plus facile de produire des interfaces de saisies avec des niveaux et des facettes à niveau, sans rajouter des fields exotiques.

[acheype]

@mrflos Je conçois que la doc semble compliquée et qu'il faudrait la rendre plus accessible, mais l'extension dans son ensemble est plutôt bien foutue, ce n'est pas juste du bricolage (les bidouilles qu'on peut y voir c'est plutôt pour utiliser en tant qu'extension, du code qui devrait être au sein du cœur) et elle permet notamment de refactorer de vieux codes js encore existants.

chouette si vous prévoyez de simplifier de nombreux concepts ! j'imagine que le passage des formulaires en fiche est de la partie :) et je n'ai pas l'impression que tout cela est incompatible. Si on n'a plus qu'un type de champ liste (youpie, on n'aura plus les super noms checkbox79monnomdechamp !), on pourra très bien concevoir d'avoir un autre champs pour les listes de deuxième niveau. Perso, je trouve que cela justifie l'existence d'un champ et que ce serait plus simple que d'avoir un introduire un énième concept.

Je comprends pleinement que tu aurais préféré qu'il y ait vraie discussion en amont pour une feature de ce type, mais aujourd'hui on est dans une situation où on a une fonctionnalité complexe qui a été déjà développée et qui aurait logiquement sa place au sein du cœur (en tout cas au niveau de l'architecture).

Ce serait à mon sens du gain de temps pour tout le monde d'intégrer aujourd'hui cette feature quitte à remanier un peu la doc ou certains détails. Et cela permettrait de dégager plus de temps pour tous les refactoring importants dont tu parles ou d'autres qui sont systématiquement repoussés comme l'utilisation de format json au sein de la BD.

Ce serait en tout cas chouette si vous prenez le temps d'en discuter au sprint de juin. Il y a beaucoup de choses perfectibles au sein de YesWiki, et s'il n'y a pas une vraie raison en terme d'architecture, ce serait à mon sens dommage de devoir redévelopper d'une autre manière une grosse feature comme celle-ci.

[mrflos]

Oui par bricolage je ne remettais pas en cause le travail effectué mais des discussions sur l'extension à propos du fait que cela ne marche pas avec des checkbox, la qualité de la doc, sont des signaux qui m'indiquent que ce n'est pas mûr pour être intégré au cœur.
Autre réticence : tu me dis qu'il y a eu un gros travail de fait, donc j'imagine que c'est pas facile à prendre en main le code, et tes demandes d'ajout de fonctionnalités ont reçu la réponse qu'il faudrait trouver des moyens financiers pour faire les améliorations. Perso j'y voies un danger de dette technique à venir si on ne débloque pas l'argent pour les développements, surtout que @J9rem n'est pas dispo en 2023 pour des devs yeswiki, et a souhaité sortir des développements du cœur (ce que j'espère n'est que temporaire, mais actuellement c'est ca).
Aussi, les refactos plus généralistes deviennent de moins en moins faciles si l'on rajoute de nouvelles fonctionnalités. On est en fin de cycle pour doryphore, et il vaut mieux bien penser l'architecture d'ectoplasme pour permettre d'améliorer l'architecture globale de yeswiki, et donc pour moi garder cette feature sous forme d'extension est plus facile, et la fonctionnalité est très vite installée sur n'importe quel wiki.
Vu que la version 4.5 de yeswiki va un peu faire du refacto de bazar, il est prévu de faire tester l'extension aux personnes présentes au sprint, et s'il y a une majorité pour intégrer la feature au cœur, on le fera malgré mes réticences, bien entendu.

[acheype]

Oui, il y a encore des petits trucs à améliorer et peut-être qu'il faut attendre encore un peu avant de l'intégrer dans le cœur (on pourrait être clair aussi avec les points qui sont encore à améliorer)...

C'est un peu le serpent qui se mord la queue, tant que l'extension est dans son coin, maintenue par une seule personne, c'est dur pour chacun de se dire, tiens je vais participer en énergie/argent à son développement. Surtout que ce n'est pas une extension comme les autres, elle vient surcharger des fonctionnalités du cœur et doit systématiquement s'adapter à ses évolutions.

Je n'ai pas l'impression que ça puisse trop brider l'architecture d'ectoplasme, il y a déjà tellement à remanier.

Mais c'est cool si vous avez prévu de tester l'extension et que chacun puisse se faire son idée.

Pour moi, l'extension fait pleinement le job et si on est ok avec le fait qu'elle utilise un champ pour représenter une liste de deuxième niveau, autant bénéficier du travail qui a déjà été fait. Et perso, pour qu'elle puisse être pleinement fonctionnelle, j'y verrai simplement :

• une doc simplifiée
• le fait que les filtres ne prennent pas en compte les contraintes entre liste parent et la liste de niveau 2 (pas problématique pour les listeXXX mais juste pour les checkboxXXX)
• la suppression à chaque sélection de filtre des nombres à côté des options, c'était une bonne idée de tester mais ça complexifie pour l'utilisateur

La partie saisie est pleinement fonctionnelle et le champ se configure facilement via le form builder.

[J9rem]

surtout que @J9rem n'est pas dispo en 2023 pour des devs yeswiki, et a souhaité sortir des développements du cœur

pour éviter les quiproquos, je n'ai pas dit que je ne suis pas disponibles pour des développements YesWiki en 2023, ni que je ne souhaitais pas travailler pour le cœur de YesWiki. J'ai juste dit que je ne me positionne pas sur la proposition de prestations faite par l'association YesWiki pour la période 2023, ce qui ne m'empêche pas de répondre aux autres demandes de prestations faites par d'autres clients (autre que l'association YesWiki). Je le précise juste pour que mes autres clients ne voient pas dans le message précédent comme quoi je suis indisponible, ce qui n'est pas la réalité exacte.

Idem, je ne suis pas fermé aux apports dans le cœur (pour preuve, j'y apporte toujours des correctifs suite aux erreurs que je trouve), mais dans le cadre de prestations, je travaille maintenant dans des extensions dédiées et je peux faire des propositions de PR draft prêtes à fusionner dans le cœur à partir de ces extensions (toutefois, si des changements de spec. doivent être faits pour la fusion dans le cœur, avec de grosses adaptations du code, je laisse la PR comme base pour sa reprise par un autre dev.)

[mrflos]

Hello @J9rem et @acheype , après tests lors du sprint de juin 2023 dans les Landes, il a été décidé de garder cette fonctionnalité en extension, car elle introduit trop de complexité pour les utilisateurices de base, et que ce n'est pas un soucis pour les utilisateurices avancées de l'installer en extension.

[J9rem]

merci pour ce retour @mrflos . pour moi, ça me va (vu que ça fait un moment que je travaille avec le format de l'extension).