[Constructeur] Pouvoir rendre inactive une saisie #174

Open
opened 3 months ago by maieul · 9 comments
maieul commented 3 months ago
Collaborator

On reprend le ticket commencé dans Formidable, dont la conversation est ici 👍:
https://git.spip.net/spip-contrib-extensions/formidable/issues/18

Je reprend donc, avec des idées comme cela qui me sont venues.

Parfois il arrive qu'on ne veuille plus d'un champ d'un formulaire formidable, mais qu'on veuille garder tout de même les enregistrement. Actuellement la seule solution pour ca, c'est de mettre un afficher_si false. Ca marche mais c'est moche, et cryptique.

Ma proposition :

  • une saisie peut être décrite ainsi
$masaisie = [
	'saisie' => <type_saisie>
    'depublie' => bool (true par défaut)
    'options' => [] // Ca on connait
]
  • dans #GENERER_SAISIES uniquement, ne pas generer la saisie si on est en depublie
  • dans #VOIR_SAISIE mettre une classe spécifique si depubliée
  • dans le constructeur de formulaire, ajouter une 5ème bouton (à côté de déplacer/dupliquer, etc) qui pourrait être
    • soit une glissière actif/inactif
    • soit une icone de bascule (un œil ? mais ca dit visible/invisible, pas le cas)
On reprend le ticket commencé dans Formidable, dont la conversation est ici 👍: https://git.spip.net/spip-contrib-extensions/formidable/issues/18 Je reprend donc, avec des idées comme cela qui me sont venues. Parfois il arrive qu'on ne veuille plus d'un champ d'un formulaire formidable, mais qu'on veuille garder tout de même les enregistrement. Actuellement la seule solution pour ca, c'est de mettre un afficher_si <code>false</code>. Ca marche mais c'est moche, et cryptique. Ma proposition : - une saisie peut être décrite ainsi ``` $masaisie = [ 'saisie' => <type_saisie> 'depublie' => bool (true par défaut) 'options' => [] // Ca on connait ] ``` - dans `#GENERER_SAISIES` uniquement, ne pas generer la saisie si on est en depublie - dans `#VOIR_SAISIE` mettre une classe spécifique si depubliée - dans le constructeur de formulaire, ajouter une 5ème bouton (à côté de déplacer/dupliquer, etc) qui pourrait être - soit une glissière actif/inactif - soit une icone de bascule (un œil ? mais ca dit visible/invisible, pas le cas)
maieul added the
amélioration
label 3 months ago

Après avoir relu l'ancien fil :

  • comme "inactif/disable" spécifiquement dans le contexte des formulaires est déjà utilisé pour un autre sens, alors le vocabulaire déjà existant (pour ne pas en introduire un nouveau) qui correspond le plus à la fonctionnalité est bien "publié/dépublié"
  • publié = c'est visible dans le site, dépublié = c'est invisible dans le site, ça correspond bien comme pour un article ou tout autre contenu
  • si on part sur ça, ça serait bien que ce soit le même vocabulaire plus tard dans Menus, Noizetier, etc, pour la même fonctionnalité
  • je pense pour l'instant toujours que le stockage serait mieux dans les options comme tout autre options, plutôt qu'ajouter un nouveau truc à la racine (le moins possible de choses à la racine, surtout pas pour une unique info)
  • pour l'interface par contre oui, ça devrait être pris en compte dans l'interface globale des premiers boutons, pas dans la config qui s'ouvre, mais je n'ai pas encore d'avis sur ce qui serait le mieux (notamment parce que d'hab dans le bouton on met un picto qui montre l'action qui sera faite, et non pas l'état en cours, alors si on mélange dans la même liste certain bouton qui montre l'action à faire, et un autre qui montre l'état en cours, ça peut être confus, à réfléchir)
Après avoir relu l'ancien fil : - comme "inactif/disable" spécifiquement dans le contexte des formulaires est déjà utilisé pour un autre sens, alors le vocabulaire déjà existant (pour ne pas en introduire un nouveau) qui correspond le plus à la fonctionnalité est bien "publié/dépublié" - publié = c'est visible dans le site, dépublié = c'est invisible dans le site, ça correspond bien comme pour un article ou tout autre contenu - si on part sur ça, ça serait bien que ce soit le même vocabulaire plus tard dans Menus, Noizetier, etc, pour la même fonctionnalité - je pense pour l'instant toujours que le stockage serait mieux dans les options comme tout autre options, plutôt qu'ajouter un nouveau truc à la racine (le moins possible de choses à la racine, surtout pas pour une unique info) - pour l'interface par contre oui, ça devrait être pris en compte dans l'interface globale des premiers boutons, pas dans la config qui s'ouvre, mais je n'ai pas encore d'avis sur ce qui serait le mieux (notamment parce que d'hab dans le bouton on met un picto qui montre l'action *qui sera faite*, et non pas l'état en cours, alors si on mélange dans la même liste certain bouton qui montre l'action à faire, et un autre qui montre l'état en cours, ça peut être confus, à réfléchir)
Poster
Collaborator
  • ok pour le voca
  • mais alors si on utilise le même voc que pour les objet, pourquoi ne pas proposer la même interface, ou similaire, à savoir une puce de statut (avec les même code couleur vert -> publié, rouge -> dépublié)?
  • pour le stockage : ok
* ok pour le voca * mais alors si on utilise le même voc que pour les objet, pourquoi ne pas proposer la même interface, ou similaire, à savoir une puce de statut (avec les même code couleur vert -> publié, rouge -> dépublié)? * pour le stockage : ok
Poster
Collaborator

Ah punaise, un truc comme cela qui me vient à l'esprit : est-ce que si on a le même voc + les mêmes boutons que pour les objets, il n'y aurait pas des champs qui dans ieextras basculeraient le bouton de statut en se disant "chouette, ca va me depublier automatiquement tous mes champs", et patatra non ?

du coup je dirais : il faut que ces boutons n'apparaissent dans le constructeur de formulaire que sur demande explicite.

Ah punaise, un truc comme cela qui me vient à l'esprit : est-ce que si on a le même voc + les mêmes boutons que pour les objets, il n'y aurait pas des champs qui dans ieextras basculeraient le bouton de statut en se disant "chouette, ca va me depublier automatiquement tous mes champs", et patatra non ? du coup je dirais : il faut que ces boutons n'apparaissent dans le constructeur de formulaire que sur demande explicite.

je n'ai pas trop compris la dernière idée

une fois le concept en place, et ce serait pareil si on l'ajoutait à Menus ou Noizetier, ça doit pas être caché pour moi, une fois que le contexte est là, à tout moment on doit pouvoir désactiver/réactiver un élément de l'ensemble (désactiver un champ de form, désactiver un élément de menu, désactiver une noisette) tout en gardant sa config et en pouvant le réafficher plus tard

je n'ai pas trop compris la dernière idée une fois le concept en place, et ce serait pareil si on l'ajoutait à Menus ou Noizetier, ça doit pas être caché pour moi, une fois que le contexte est là, à tout moment on doit pouvoir désactiver/réactiver un élément de l'ensemble (désactiver un champ de form, désactiver un élément de menu, désactiver une noisette) tout en gardant sa config et en pouvant le réafficher plus tard
Poster
Collaborator

Bon je reprend. Je me place clairement dans un cas d'usage de "champs extra interface". J'ai mes x champs extras, avec les boutons de bascule de statut de chaque champ (rouge vs verts). Je me dit alors "tiens, chouette, je peux dépublier d'un coup la valeur du champ titi". Alors qu'en fait non. C?est juste "je peux enlever d'un coup la possibilité de remplir le champ titi".

Et donc ma dernière phrase, c'est que ce à chaque plugin qui utilisent le constructeur de formulaire de dire si oui ou non cette possibilité de "depublier" un champ est activée.

Bon je reprend. Je me place clairement dans un cas d'usage de "champs extra interface". J'ai mes x champs extras, avec les boutons de bascule de statut de chaque champ (rouge vs verts). Je me dit alors "tiens, chouette, je peux dépublier d'un coup la valeur du champ titi". Alors qu'en fait non. C?est juste "je peux enlever d'un coup la possibilité de remplir le champ titi". Et donc ma dernière phrase, c'est que ce à chaque plugin qui utilisent le constructeur de formulaire de dire si oui ou non cette possibilité de "depublier" un champ est activée.
Poster
Collaborator

AUtre remarque concernant l'interface : je suis pas sûr que les puces rapides soient accessibles. J'ai même des gros doutes. Pour les objets spip standards, ce n'est pas grave car la méthode de base (le menu de statut) l'est, et donc les pucs c'est juste un truc en plus. Mais pour un constructeur de truc (formulaire, menu, ce que tu veux).

Du coup je m edit qu'un glissière serait le mieux, si jamais il en existe en js accessible.

AUtre remarque concernant l'interface : je suis pas sûr que les puces rapides soient accessibles. J'ai même des gros doutes. Pour les objets spip standards, ce n'est pas grave car la méthode de base (le menu de statut) l'est, et donc les pucs c'est juste un truc en plus. Mais pour un constructeur de truc (formulaire, menu, ce que tu veux). Du coup je m edit qu'un glissière serait le mieux, si jamais il en existe en js accessible.

Bé non les puces de statut c'est pas accessible et en plus tout riquiqui, au niveau ergonomique c'est juste un raccourci pour les personnes qui savent/arrivent à l'utiliser. Ceci dit on pourrait l'utiliser en mode statique juste pour montrer l'état avec un bouton à côté pour switcher entre les deux états… faudrait maquetter.

Bé non les puces de statut c'est pas accessible et en plus tout riquiqui, au niveau ergonomique c'est juste un raccourci pour les personnes qui savent/arrivent à l'utiliser. Ceci dit on pourrait l'utiliser en mode statique juste pour montrer l'état avec un bouton à côté pour switcher entre les deux états… faudrait maquetter.

Pour moi cette fonctionnalité est tout autant utile pour Formidable que pour Champs Extras au niveau constructeur… Dans les champs extras aussi tu peux vouloir masquer une saisie/champ temporairement SANS rien supprimer tout ce qui a déjà été configuré (et encore moins les contenus accumulés dans la base, si on veut supprimer les contenus, on supprime le champ là ça supprime bien les contenus).

Pour moi cette fonctionnalité est tout autant utile pour Formidable que pour Champs Extras au niveau constructeur… Dans les champs extras aussi tu peux vouloir masquer une saisie/champ temporairement SANS rien supprimer tout ce qui a déjà été configuré (et encore moins les contenus accumulés dans la base, si on veut supprimer les contenus, on supprime le champ là ça supprime bien les contenus).
Poster
Collaborator

et en plus tout riquiqui,

ca c'est un argument qui ne vaut plus 4 : les puces par défaut ne sont plus toutes riquiqui, et donc c'est du svg.

Cela étant l'accessibilité ca reste redibitoire.

Dans les champs extras aussi tu peux vouloir masquer une saisie/champ temporairement SANS rien supprimer tout ce qui a déjà été configuré

bien sur, mais je suis persudaé que des gens penseronts que ca masque aussi le contenu deja accumulé (sans le supprimer).

genre que avec cela, #TOTO ne renverra plus rien, jusqu'au jour où pouf je remettrait le champ toto à publier

Ceci dit on pourrait l'utiliser en mode statique juste pour montrer l'état avec un bouton à côté pour switcher entre les deux états… faudrait maquetter.

oui je pensais à un truc du genre, in fine.

t'a des otuils de maquetage simple ?

> et en plus tout riquiqui, ca c'est un argument qui ne vaut plus 4 : les puces par défaut ne sont plus toutes riquiqui, et donc c'est du svg. Cela étant l'accessibilité ca reste redibitoire. > Dans les champs extras aussi tu peux vouloir masquer une saisie/champ temporairement SANS rien supprimer tout ce qui a déjà été configuré bien sur, mais je suis persudaé que des gens penseronts que ca masque aussi le contenu deja accumulé (sans le supprimer). genre que avec cela, #TOTO ne renverra plus rien, jusqu'au jour où pouf je remettrait le champ toto à publier > Ceci dit on pourrait l'utiliser en mode statique juste pour montrer l'état avec un bouton à côté pour switcher entre les deux états… faudrait maquetter. oui je pensais à un truc du genre, in fine. t'a des otuils de maquetage simple ?
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.