Idée : widget "Formulaire interne" et "Carte"

Widget « Formulaire interne »

Je pense qu’il y a un vrai besoin d’avoir un widget qui permette de faire de la saisie dans un document grist avec un bouton de validation/soumission. A la différence de la fiche, c’est au moment du clic sur le bouton de validation que la ligne sera ajoutée dans la table liée.

J’en avais déjà parlé ici, ou ; voici quelques vues pour montrer ce à quoi je pense :

Ajout de ligne :

Modification de ligne :

Ce qui ajouterait une page au formulaire et un bouton « Suivant »/« Précédent » :

  • Une configuration équivalente à celle des formulaires : possibilité de faire du glisser/déposer, ajouter des sections, des descriptions, séparateurs etc. Et idéalement on pourrait aussi choisir notre police, changer les couleurs, grouper des champs…

Pour l’instant on utilise cette astuce mais qui est alambiquée, et qui est un détournement du formulaire classique.

Widget carte

Et dans l’idéal, il y aurait aussi un widget d’affichage qui pourrait s’appeler « Carte » par exemple, qui serait exactement ce même widget mais sans le bouton de soumission, et qui permettrait de faire de l’affichage de manière plus jolie et plus personnalisable que la fiche actuelle. Avec les mêmes fonctionnalités que le formulaire interne : possibilité de grouper des champs et formater les couleurs, polices, afficher des images etc.

Exemple :

Bon, le design serait à revoir évidemment, mais vous avez l’idée :slight_smile:

Ces deux widgets pourraient être réunis en un seul, par exemple un widget « Interface » qui aurait un mode « Edition/formulaire » et un mode « Affichage »…Mais ce serait peut-être moins facile à trouver dans la galerie de widgets.

N’hésitez-pas si vous avez des commentaires !

3 « J'aime »

@judemout a fait des interfaces très proches de ce que tu décris pour le grist de la Suite Territoriale (exemple : juliendemoutiez.github.io/src/views/ContactForm.vue at main · juliendemoutiez/juliendemoutiez.github.io · GitHub)

Il faudrait « généraliser » son travail pour que ça soit utilisable pour n’importe quel type de document.

C’est le code qui donne les widgets dans ces captures c’est ça ?



Pour généraliser il faudrait utiliser le mappage de colonnes, et du coup il faudrait potentiellement prévoir une très longue liste de colonnes à mapper, pour prendre en compte les tables qui contiennent beaucoup de colonnes… (je n’avais pas trouvé comment proposer autant de colonnes que celles présentes dans la table source, mais peut-être ai-je raté quelque chose ?)

Et aussi ajouter toute la partie configuration (glisser/déposer, ajout de sections, séparateurs etc), qui peut-être être récupérée du formulaire ?

2 « J'aime »

Pour appuyer ma propre proposition :slight_smile:

Plusieurs exemples de projets rencontrés récemment et pour lesquels ce serait trèèès utile :

  • programme CRPV de l’ANCT : c’est un questionnaire collaboratif. ex : il y a une colonne où on peut sélectionner une échelle « département », « commune », et des colonnes en suivant pour préciser « département concerné », « commune concernée » etc. Un formulaire interne permettrait d’obliger à remplir les colonnes correspondantes. Un formulaire interne avec choix conditionnel serait idéal, permettant d’afficher les colonnes selon le choix précédent.
    Permettrait aussi d’avoir des textes, des libellés pour expliquer comment remplir. (là on est vraiment limités avec le nom de colonne court et le petit (i) de description)

  • programme Réseaux régionaux de tiers lieux de l’ANCT : questionnaire de remplissage de données (subventions, RH…) pour les réseaux régionaux. un formulaire interne serait beaucoup plus pratique. Exemple :
    Il y a une table où on doit entrer « Sub ANCT », « Sub conseil régional »… Et il est compliqué de différencier une cellule « nul » = vide parce que le réseau n’a pas rempli la valeur, ou parce qu’ils ont laissé vide car rien reçu (et qu’ils auraient dû mettre « 0 »). Un formulaire interne permettrait d’obliger à remplir ce champ pour pouvoir valider.

  • projet de frigos connectés de la préf 82 :
    ils souhaitaient parvenir à mieux guider l’utilisateur :

– en matérialisant dans le tableau d’inscription le fait qu’il existe une liste déroulante (dans excel c’est une flèche), par défaut l’agent ne sait pas qu’il doit double cliquer → les listes déroulantes seraient beaucoup plus claires dans un formulaire interne
– interdire la saisie d’items différents des propositions de la liste déroulante → ce problème n’existerait pas
– rendre obligatoire la saisie dans les deux colonnes → idem

2 « J'aime »