Mauvaise foi bonjouuuur 
Les saisies te font des interfaces super standard
Oh mais, oh mais… que vois-je dans un SPIP avec pourtant 50 plugins ? 99% des formulaires CVT des objets et config et bref de tous les CVT du monde que je trouve sont… TOTALEMENT STANDARDS 
Les exceptions sont ultra rares et… parfaitement personnalisables puisqu’il suffit (au pire du pire) de personnaliser le squelette général pour faire ce qu’on veut plutôt qu’utiliser la génération auto.
Cet argument me parait donc assez peu pertinent.
et dès que tu veux affiner le html pour améliorer l’ergo ou l’usabilité ou la compréhension du formulaire, tu est coincé
Je ne vois aucun exemple insoluble pour l’instant car il y a plein de façon de personnaliser, ET EN PLUS on peut continuer d’améliorer (cf mon point précédent : permettre la personnalisation de telle saisie précise par contexte/formulaire, ce qui est totalement envisageable, et qui existe chez drupal etc).
Dans les choses déjà possibles :
- avec flex et grid, en ergo tu peux déjà personnaliser la majorité des tes (rares comme vu au point précédent) cas où ya besoin d’affiner l’ergo, d’aligner autrement, et cela pour un formulaire donné
- au pire du pire, on peut déjà faire refaire le HTML complet qu’on veut (formulaires/truc.html) dans les encore plus rares cas où c’est pas standard + ni flex ni grid ne permet
Dans les améliorations parfaitement ajoutables à court terme :
- pouvoir mettre l’explication avant ou après depuis les options (même si flex permet de changer le order déjà)
- pouvoir personnaliser la génération d’une saisie donnée (« checkbox » par ex) pour tel contexte/formulaire précis
vs les contorsions qu’il faut faire pour esperer aligner 2 input dans un formulaire [#98 - WIP: conteneur_inline
Il n’y a aucun contorsion technique, essentiellement du temps passé à caler la nomenclature. Mais techniquement ça reste très simple, et donc pour le coup ça couvrira un des cas très courant de personnalisation.
Autre exemple tout con : les saisies ont décidé que les explications sont au dessus du input, ce qui est pas forcément toujours pertinent d’un point de vue visuel, cas des checkbox que tu veux parfois en inline dans un seul container, parfois rouvrent sur un nouveau sous-formulaire comme dans facteur, etc etc.
Cf plus haut, place de l’explication déjà personnalisable par flex + améliorable très facilement en options si on veut (personne ne l’a spécialement demandé jusque là, mais facile à améliorer)… ouverture déjà pris en charge par afficher_si depuis des années… (y compris complexe pas juste suivant une case, et y compris dans du multi étapes désormais…) etc etc : ya strictement aucun blocage dans cette liste en fait.
- on a une interface totalement standardisée de geek pour geek qui s’assoit sur les problèmes d’usabilité au prix de « au moins ça va vite à coder »
Mantra répété, sans jamais aucun exemple concret qui ne soit corrigeable/améliorable facilement.
Comme dit plus haut, si on suivait cette affirmation ça voudrait dire que genre 100% des forms de l’admin sont « des interfaces de geek pour geek », ce qui est totalement faux : ces dizaines de form de l’admin, core et plugins, sont tous très classiques, et les besoins en interface plus complexe c’est genre 1% ou moins.
Même sans compter les 1% de perso, rien qu’avoir les 99% de forms classiques en saisie permet de s’assurer totalement qu’ils suivent les recommandations d’ergonomie et d’accessibilité justement, et quand on améliore, ça améliore alors sur tous les formulaires d’un coup. Rien que cet argument suffirait à mon sens à l’accepter, sachant que les 1% qui restent sont toujours personnalisables en n’utilisant pas la génération auto pour eux (+ les améliorations proposées faisables).
- on veut faire de la dentelle, et on finit avec 36000 saisies spécifiques qui sont utilisées à un endroit et au final tout ça est bien plus lourd à écrire, faire évoluer et maintenir…
Personne n’a jamais eu besoin de personnaliser 36000 saisies pour peaufiner de l’ergo, c’est un mythe qui n’existe pas dans la réalité des plugins existants, dont, je le répète 99% ou plus des formulaires sont parfaitement classiques et simples, sans besoin de trucs compliqués à personnaliser.
(et j’ai pas du tout abordé l’aspect perf de l’affichage d’un formulaire en saisie vs un formulaire html…)
(ce pourquoi je pense que saisies devrait se changer en POO pour l’avenir)
- en le passant à une balise directement qui génère le form (un équivalent à GENERER_SAISIES )
- ou individuellement chaque entrée voulue à un SAISIE ou une inclusion (un peu plus fin sur la structure donc),
- ou pour des besoins plus spécifiques directement dans le html désiré, et là on utilise les données de l’objet (plutôt que de les calculer pour certaines dans le squelette)
Mais… c’est à peu près littéralement ce que fait déjà Saisies, avec la déclaration en PHP… haha 
On peut tout aussi bien laisser la génération auto, que TOUJOURS faire le HTML à la main ou avec #SAISIE ou autre inclusion, si on veut pas l’auto.
Concernant le plugin Saisies actuel, il faudrait pouvoir dire « utilise tel template de base » ou « utilise tel template pour ce type de champ »… Il y avait eu des discussions, je ne sais pas où ça en est, mais le fait que effectivement Saisies utilise actuellement des cascades d’inclusions de squelettes fait qu’il est évidemment plus énergivore qu’écrire directement le HTML. Mais la simplicité est incomparable.
Exactement, la simplicité d’écriture et de maintenance est incomparable, et oui ce truc de pouvoir personnaliser les saisies par formulaire (que pour tel formulaire ça soit une implémentation différente) c’est déjà en discussion et dans la todo depuis… 10 ans je pense, depuis le début de l’API PHP.
C’est juste qu’en fait dans la réalité du terrain, ça reste quand même un besoin super rare d’avoir vraiment besoin de ce niveau de granularité de personnalisation, et donc je n’en ai jamais eu besoin moi au point d’avoir le temps de coder cette amélioration.
Mais techniquement il n’y a absolument rien d’insurmontable à ajouter cette fonctionnalité.
Pour sûr je pense qu’il faut revoir ce qu’est une définition de saisie : c’est dommage en 2022 de continuer à utiliser des array (dans des array dans des array) (les IDE ne nous proposent pas de complétion, l’analyse est limitée…). Mais les squelettes SPIP ne savent pas vraiment gérer des objets… ça n’aide pas du tout.
Ça tombe bien, pour les 99% ou plus de cas courants, ya pas à l’utiliser depuis les squelettes, mais depuis une déclaration PHP, donc comme dit plus haut, oui moi je suis à fond pour qu’une version majeure plus tard passe tout en POO avec des classes et méthodes.
En revanche, la description en array serait toujours là pour moi, pour insérer en masse une description, pour l’export/import, l’enregistrement en base, etc. Mais le « moteur » serait en classes/méthodes et il me semble que toutes les opérations tourneraient alors plus vite qu’actuellement, ce qui limiterait la critique sur la rapidité.
Bref, en résumé : la plupart des critiques évoquées sont soit déjà résolubles, soit résolubles facilement à court terme, soit ne concerne tellement qu’une infime utilisation que pour ça, ça peut continuer d’être fait à la main sans bloquer que 99% du reste peut être déclaré/généré auto en saisies.
Tu vois @eric_tonton, quand on regarde bien, ya rien de si bloquant.
prête qui attend relecture de son annonce 
sur le blog.