[Constructeur] Pouvoir rendre inactive une saisie #174

On reprend le ticket commencé dans Formidable, dont la conversation est ici 👍:
spip-contrib-extensions/formidable#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)

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)

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

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

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.

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.

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

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 ?

En dehors de la question ergo : je viens de voir que saisie_afficher fait appel à saisie_editable() laquelle renvoi rien si jamais la saisie $option['editable'] est à false (si inexistant renvoie). Et fait si j'ai une saisie du type

	return array(
		array(
			'saisie' => 'case',
			'options' => array(
				'nom' => 'assets_global',
				'label_case' => '<:saisies:assets_global:>',
				'conteneur_class' => 'pleine_largeur',
			),
			'editable' => false,
		)
	);

-> la saisie ne s'affiche pas

DOnc en fait en terme d'API PHP on a ce qu'il faut... c'est juste en terme d'ergo que ca manque.

Par contre evidement ce qui existe actuellement dans l'API, mais documenté nul part ne répond pas à tes remarques sur "éviter de mettre à la racine" et "utiliser le même vocabulaire que les objets"...

Ah tiens je me rappelais pas de cette option, ça vient d'où à la base d'avoir eu besoin du editable saisie par saisie et non pas juste sur le form entier ? (vu que l'historique est pété dans le git difficile de remonter)

[edit]
pfiouuu j'ai réussi à remonter ! Et donc c'eeeeest… @marcimat qui a introduit ça ya DOUZE ans au tout tout début de l'API…
9fe23a1334

Je ne sais même pas si ça a vraiment été utilisé quelque part un jour…

Du coup ça pourrait possiblement être déprécié/déplacé/renommé autrement, peut-être… Si on conçoit aujourd'hui que ce serait mieux autrement.

perso je continue à penser que c'est pas idiot de mettre à la racine, ce qui ferait qu'on aurait à la racine trois choses

Le type de saisie
Les éventuelles sous-saisies
L'editabilité

Autant d'information qui relève de "ce qu'on voit en première approche pour une saisie".

Quand au terme editable vs statut, l'un est plus "formulaire centré" (y compris dans le monde SPIP), l'autre est plus "objet centré", mais pour moi un champ n'est pas vraiment un objet en tant que tel (il existe difficilement de manière indépendante : autant tu peux déplacer un article d'une rubrique à l'autre, autant déplacer un champ d'un formulaire à l'autre).

Donc je me dis : pourquoi pas garder tel quel ? Ca évitera d'avoir à fouiller pour savoir si c'est depreciable ou pas.

Mais justement le caractère affiché ou pas est une option modifiable par les gens, donc ça parait artificiel de le mettre lui précisément à la racine plutôt qu'un autre.

Pour les termes, c'est justement pour ne pas avoir un truc propre à chaque utilisation. Je ne trouve pas une bonne chose du tout d'avoir un terme propre au formulaire, et ensuite on va définir un terme propre aux éléments de menus, et ensuite un 3ème terme propre aux noizettes, etc…

Alors qu'au niveau API (puisqu'en premier lieu on parle de la nomenclature des API), il s'agit rigoureusement de la même chose :

ce sont des listes de petits squelettes configurables, qui mis ensemble génère telle ou telle interface (un formulaire, un menu, une page)
ces petits squelettes doivent pouvoir être activé/désactivé… affiché/masqué… publié/dépublié… whatever, sans perdre leur config, en pouvant les remettre quand on veut
donc un même terme cohérent devrait s'imposer à cette même fonctionnalité