Saisie radio : incohérence du champ disable_choix #137

Open
opened 4 months ago by Eric · 5 comments
Eric commented 4 months ago
Owner

Deux choses sur la saisie radio.

Quand on lit l'explication du champ data on a:

Vous devez indiquez un choix par ligne sous la forme "cle|Label" du choix...

On oublie pas la principale utilisation, il me semble, à savoir celle d'un tableau ? Si oui, il serait bon de le rajouter ici et surement dans d'autres saisies.

Ensuite, sachant qu'on peut passer un tableau pour le champ data, il est bizarre que le champ disable_choix ne puisse pas être aussi un tableau mais soit limité à une chaine "choix1,choix2" séparée par une virgule ce qui n'est il me semble pas cohérente avec le champ data passé en chaine non ?

On ne pourrait pas rendre cela plus cohérent, à minima, en acceptant le tableau pour disable_choix ?

Deux choses sur la saisie radio. Quand on lit l'explication du champ data on a: > Vous devez indiquez un choix par ligne sous la forme "cle|Label" du choix... On oublie pas la principale utilisation, il me semble, à savoir celle d'un tableau ? Si oui, il serait bon de le rajouter ici et surement dans d'autres saisies. Ensuite, sachant qu'on peut passer un tableau pour le champ data, il est bizarre que le champ disable_choix ne puisse pas être aussi un tableau mais soit limité à une chaine "choix1,choix2" séparée par une virgule ce qui n'est il me semble pas cohérente avec le champ data passé en chaine non ? On ne pourrait pas rendre cela plus cohérent, à minima, en acceptant le tableau pour disable_choix ?

Pour la partie explication, le problème est dans ce ticket : #90 car l'explication est décrite depuis le début pour les interfaces humaines, et là ya pas à parler de array du tout. Faut trouver une solution c'est sûr

Pour la partie explication, le problème est dans ce ticket : #90 car l'explication est décrite depuis le début pour les interfaces humaines, et là ya pas à parler de array du tout. Faut trouver une solution c'est sûr
Poster
Owner

Pour la partie explication, le problème est dans ce ticket : #90 car l'explication est décrite depuis le début pour les interfaces humaines, et là ya pas à parler de array du tout. Faut trouver une solution c'est sûr

Ah il y a une utilisation de l'API qui ne s'adresse pas à des développeurs c'est ça que tu entends par là ? Ah oui, dans ce cas il y a un problème. On ne pourrait pas alors dans la description faire deux paragraphes et laisser l'utilisateur décider lequel correspond à son contexte ?

Par curiosité c'est où qu'on utilise "cle|valeur" au lieu d'un tableau ?

> Pour la partie explication, le problème est dans ce ticket : #90 car l'explication est décrite depuis le début pour les interfaces humaines, et là ya pas à parler de array du tout. Faut trouver une solution c'est sûr Ah il y a une utilisation de l'API qui ne s'adresse pas à des développeurs c'est ça que tu entends par là ? Ah oui, dans ce cas il y a un problème. On ne pourrait pas alors dans la description faire deux paragraphes et laisser l'utilisateur décider lequel correspond à son contexte ? Par curiosité c'est où qu'on utilise "cle|valeur" au lieu d'un tableau ?

Ah il y a une utilisation de l'API qui ne s'adresse pas à des développeurs

Alors en fait historiquement c'est plutôt l'inverse : l'entièreté de l'API, et donc des descriptions d'explication dans les YAML, a été conçu pour les interfaces graphiques et non pour les développeurs. Toute l'API de Saisies (pas #SAISIE qui existait mais bien l'API) je l'ai conçu en premier lieu pour pouvoir générer le constructeur de formulaires qui est au cœur de Formidable puis de Champs Extras. C'est uniquement à ça que servent les YAML (car juste pour les devs, ces YAML ne servent à peu près jamais) : décrire chacune des saisies avec toutes leurs options possibles, pour générer des interfaces automatiquement.

Et c'est donc dans ces interface que sont utilisés ces "clé|valeur", car c'est la manière la plus simple et rapide, sans JS compliqué, de générer un tableau indéfini d'avance depuis un form HTML. Voilà pourquoi l'explication ne parle que de cela.

Comme le dit maieul dans le ticket dédié : dans 99% des cas ces explications fonctionnent toujours. Mais il y a quelques rares cas, et en fait essentiellement tous les "data", les tableaux donc, où l'explication n'évoque pas ce qu'on peut faire en dev (array PHP ou squelettes). Et c'est un problème de doc du coup :)

Pour les paragraphes, je ne suis pas chaud car vraiment l'utilisation principale (et en nombre d'utilisateurices c'est massif) c'est ce que vont lire les gens dans l'interface graphique. Autant l'inverse est vrai : un dev saura qu'il n'a pas à utiliser "cle|valeur" dans son contexte, mais pour les utilisateurs de l'interface ça n'a pas de sens. Parler de array() et #ARRAY à cet endroit là ne peut que rajouter du bruit et de la confusion à ces gens, dans une interface qui est déjà pas mal chargée.

Peut-être qu'il faut dans ces rares cas une clé dédiée "explication_dev" avec une chaine dédiée, et quand on génère la documentation, si elle existe, on affiche plutôt ça, et sinon l'explication commune. Ce serait un moyen simple de générer la doc (faut que je copie ça dans l'autre ticket du coup).

> Ah il y a une utilisation de l'API qui ne s'adresse pas à des développeurs Alors en fait historiquement c'est plutôt l'inverse : l'entièreté de l'API, et donc des descriptions d'explication dans les YAML, a été conçu *pour les interfaces graphiques* et non pour les développeurs. Toute l'API de Saisies (pas #SAISIE qui existait mais bien l'API) je l'ai conçu en premier lieu pour pouvoir générer le constructeur de formulaires qui est au cœur de Formidable puis de Champs Extras. C'est uniquement à ça que servent les YAML (car juste pour les devs, ces YAML ne servent à peu près jamais) : décrire chacune des saisies avec toutes leurs options possibles, pour générer des interfaces automatiquement. Et c'est donc dans ces interface que sont utilisés ces "clé|valeur", car c'est la manière la plus simple et rapide, sans JS compliqué, de générer un tableau indéfini d'avance depuis un form HTML. Voilà pourquoi l'explication ne parle que de cela. Comme le dit maieul dans le ticket dédié : dans 99% des cas ces explications fonctionnent toujours. Mais il y a quelques rares cas, et en fait essentiellement tous les "data", les tableaux donc, où l'explication n'évoque pas ce qu'on peut faire en dev (array PHP ou squelettes). Et c'est un problème de doc du coup :) Pour les paragraphes, je ne suis pas chaud car vraiment l'utilisation principale (et en nombre d'utilisateurices c'est massif) c'est ce que vont lire les gens dans l'interface graphique. Autant l'inverse est vrai : un dev saura qu'il n'a pas à utiliser "cle|valeur" dans son contexte, mais pour les utilisateurs de l'interface ça n'a pas de sens. Parler de array() et #ARRAY à cet endroit là ne peut que rajouter du bruit et de la confusion à ces gens, dans une interface qui est déjà pas mal chargée. Peut-être qu'il faut dans ces rares cas une clé dédiée "explication_dev" avec une chaine dédiée, et quand on génère la documentation, si elle existe, on affiche plutôt ça, et sinon l'explication commune. Ce serait un moyen simple de générer la doc (faut que je copie ça dans l'autre ticket du coup).
Collaborator

On ferme au profit de #90 ?

On ferme au profit de #90 ?

Non @JLuc ya une autre question sur l'option disable. Par contre on peut le renommer pour ne garder que ce point, l'autre étant déjà dans #90 oui.

Non @JLuc ya une autre question sur l'option disable. Par contre on peut le renommer pour ne garder que ce point, l'autre étant déjà dans #90 oui.
rastapopoulos changed title from Saisie radio : explication du champ data et incohérence du champ disable_choix to Saisie radio : incohérence du champ disable_choix 2 months ago
rastapopoulos added the
amélioration
label 2 months ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.