Development #60261
type de source de données pour quelques lignes (?)
0%
Description
On a parfois des sources de données utilisant du Python pour faire
- Expression Python : [{"id": "0", "text": "Marié(e)"}, {"id": "1", "text": "Pacsé(e)"}, {"id": "2", "text": "Concubin(e)"}, {"id": "3", "text": "Divorcé(e)"}, {"id": "4", "text": "Veuf ou veuve"}, {"id": "5", "text": "Célibataire"}]
ou
- Expression Python : [{"id": "0", "text": "Pas de disponibilité"}, {"id": "1", "text": "Une place est disponible"}]
ou autre
Sur ces usages, on pourrait dire de passer par des fiches mais peut-être que ça apparait un peu démesuré, et qu'avoir la possibilité dans la source de données même de taper dans un tableau quelques identifiants et libellés serait un plus ?
Historique
Mis à jour par Thomas Noël il y a plus de 2 ans
Frédéric Péters a écrit :
Sur ces usages, on pourrait dire de passer par des fiches mais peut-être que ça apparait un peu démesuré, et qu'avoir la possibilité dans la source de données même de taper dans un tableau quelques identifiants et libellés serait un plus ?
Tu parles d'avoir un nouveau type de source de données, qu'on appelerait "Tableau" ou "Locale", en plus de l'actuel choix "JSON", "GeoJSON", "JSONP", "Python" ?
Je pense que ça serait utile (dans le cas de l'applification notamment, déplacer ce genre de source serait plus simple que de bouger carddef+data+views+etc)
Mis à jour par Pierre Cros il y a plus de 2 ans
Sauf que bouger carddef+data+views+etc on doit l'avoir de toute façon pour l'applification.
Et donc ce serait pas à la place mais en plus, perso je n'y vois pas d'intérêt.
Mis à jour par Stéphane Laget il y a plus de 2 ans
je trouve que c'est une très bonne idée au contraire. L'intérêt est notamment de pouvoir définir l'identifiant de l'item.
Mis à jour par Pierre Cros il y a plus de 2 ans
Je remets ce que j'écrivais sur le salon :
Recommander de passer par des fiches à chaque fois que c'est possible, ça me semble très bien, je le fais et franchement le gain de temps à faire ça directement avec une source de donnée est quasi nul. On empêchera pas les admins fonctionnels informaticiens de préférer les sources de données, mais on peut leur expliquer l'intérêt qu'il y a en terme de clarté, de maintenabilité, de granularité des droits pour la gestion, à utiliser des fiches.
Et Mik enchérissait derrière pour dire qu'il passait lui aussi par des fiches pour ces usages et que le seul problème était l'export des données, chose qu'on devra avoir de toute façon.
Mis à jour par Pierre Cros il y a plus de 2 ans
Et pour l'identifiant Mik écrivait :
Il faut donc penser avec les fiches à poser ses conditions sur un champs "identifiant" géré sur chaque fiche parce que l'id peut changer entre un export/import recette/prod.
Mis à jour par Stéphane Laget il y a plus de 2 ans
l'autre difficulté des fiches pour ce type de source de données est de ne pas avoir la main sur l'id. C'est #44604.
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
Ça pourrait simplement être une interface adaptée au dessus des fiches; genre un sous-type de fiches nommé "Nomenclatures" avec des fonctionnalités limitées, workflow par défaut implicite, un seul rôle de gestion ou implicitement le rôle de la catégorie associée, édition directe dans le listing, un tableau quoi.
Mis à jour par Brice Mallet il y a plus de 2 ans
Je suis pour un tel système qui simplifierait la gestion des petits référentiels, sans avoir à passer par des fiches. Prévoir, tout comme l'expression Python actuelle, d'avoir la main sur l'ordre d'affichage (les items de la liste peuvent s'ajouter/changer en cours d'élaboration du formulaire).
Mis à jour par Frédéric Péters il y a plus de 2 ans
Je me dis qu'il faut aussi considérer ici la nécessité de quitter les expressions Python, le taf de conversion serait jouable ici assez rapidement, avec des fiches c'est plus compliqué ("les conditions porte sur form_var_XXX_raw, et donc passer par des fiches suppose de revoir le wf et le formulaire à plein d'endroits différents").
Avec les fiches ça demande le code pour pouvoir leur définir manuellement un identifiant (#44604) et du code ou bricolage si on veut pouvoir les ré/ordonner.
Je reste hésitant, il y a une forte envie de dégager les expressions Python, et pouvoir le faire avec un développement bien cadré ici a son attrait, vs les devs supplémentaires plus généraux et moins définis et un travail de migration par les CPF moins évident.