Project

General

Profile

Development #60261

type de source de données pour quelques lignes (?)

Added by Frédéric Péters 5 months ago. Updated 5 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
04 Jan 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

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 ?

History

#1

Updated by Thomas Noël 5 months ago

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)

#2

Updated by Pierre Cros 5 months ago

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.

#3

Updated by Stéphane Laget 5 months ago

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.

#4

Updated by Pierre Cros 5 months ago

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.

#5

Updated by Pierre Cros 5 months ago

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.

#6

Updated by Stéphane Laget 5 months ago

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.

#7

Updated by Benjamin Dauvergne 5 months ago

Ç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.

#8

Updated by Brice Mallet 5 months ago

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

#10

Updated by Frédéric Péters 5 months ago

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.

Also available in: Atom PDF