Proposition Roadmap SPIP (court terme), et Composer.

:+1: : il m’a expliqué après-coup

Pour revenir à la roadmap SPIP, je me disais que l’on pourrait aussi intégrer YAML dans le core de façon à proposer plus facilement le format JSON/YAML pour remplacer les XML.
Le YAML permet d’avoir un « équivalent humain » au XML sachant que YAML et JSON sont très facilement interchangeables.

C’est discutté là : #5012 - YAML dans le core en 4.1 ou 4.2 ? - spip - SPIP on GIT ; et le passage à des fichiers de config en PHP est évoqué.

Je reviens sur le pseudo troll de Saisies.
Je me dis quand même que ça pourrait être intéressant de fournir un Core Saisies dans les plugins-dist en spip 5.0 par exemple parce que c’est quand même pénible d’écrire ces formulaires, de les lire avec les GET partout et surtout de les modifier à chaque changement de markup.

Là je reprends des formulaires qui datent un peu et c’est crispant, vraiment.

En plus, c’est à confirmer, mais ça devrait pas être un gros chantier de couper Saisies en un Core Saisies qui fournit la balise #SAISIE et les saisies de base et un full Saisies qui embarque le reste dont le PHP, YAML, etc non ?

En plus, c’est à confirmer, mais ça devrait pas être un gros chantier de couper Saisies en un Core Saisies qui fournit la balise #SAISIE et les saisies de base et un full Saisies qui embarque le reste dont le PHP, YAML, etc non ?

non effectivement. Le gros du travail sur saisie actuellement ne porte pas sur cette partie là, mais sur le multiétape, le afficher_si, les verifs automagique, etc.

On peut imaginer effectivement de scinder en deux plugins,

Le 06/02/2022 à 22:30, Maïeul Rouquette via Discuter de SPIP a écrit :

On peut imaginer effectivement de scinder en deux plugins,

Perso pour l’instant je vois pas trop l’intérêt (à part juste pour le constructeur qui là est une interface, qq de visible, donc qui n’est pas l’API). :slight_smile:
Mis à part le constructeur tout saisies c’est « une API », et je vois pas l’intérêt de découper une API déjà pas si énorme en plusieurs. Et concrètement au quotidien on sépare pas les squelettes de leurs descriptions YAML, car ça sera forcément toujours à faire évoluer simultanément (si ya des choses ajoutées ou retirées dans le HTML généré, les options #ENV utilisées, bah le YAML doit évoluer plus ou moins en même temps donc bizarre si les deux sont dissociés).

Pour le troll en question, pour moi Saisies pourrait candidater si :

  • l’API était refaite en POO avec des class PHP (Saisie, SaisiesForm, etc), donc moins le bazar et sûrement plus optimisée, plus rapide
  • l’API permettait de personnaliser les squelettes par contexte/formulaire, pas juste globalement (le point principal de trollage de mémoire)
  • qu’on fasse un POC (dans un plugin) pour montrer qu’on peut faire la majorité des forms du core/dist avec, et que le but c’est que ce soit utilisé à la fin, car ya rarement d’intérêt d’ajouter au core/dist un truc pas utilisé par lui-même


RastaPopoulos

Je pense que si :slight_smile: .
L’intérêt c’est l’écriture des formulaires en HTML qui reste quand même largement répandue actuellement (au moins 90% pour les plugins et 100% pour le Core). Franchement quand on regarde le code qu’on doit pondre sans, avec la ligne de variables et les markups compliqués à répliquer à l’infini car on s’en rappelle jamais, je pense qu’on a du potentiel d’amélioration.
Et je ne parle pas des changements de markup à reprendre.

Donc oui, la balise #SAISIE me parait être une évidence pour simplifier l’écriture de nos formulaires et donc leur maintenance, même si il nous restera peut-être 2% de formulaires non compatibles.

Après, je suis d’accord que le YAML pose un petit problème.
Et surtout, je pense que ce que tu envisages pour candidater ne se fera jamais comme ça.
Je trouve donc dommage de ne pas nous simplifier la vie plus rapidement, dans les plugins et aussi dans le core, car pour aller dans ton sens, un plugin-dist doit être utilisé par le Core.

Donc n’est-ce pas trop dogmatique de se figer sur tout ou rien ?

Puisqu’on m’appelle au troll, moi c’est clairement les formulaires avec les saisies qui me donnent mal à la tête.

Les saisies te font des interfaces super standard 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é (cf #196 - [WIP] Ergonomie du formulaire instituer objet - spip - SPIP on GIT où on voit bien que pour affiner l’interface il faut pouvoir tricoter à la main proprement le html vs les contorsions qu’il faut faire pour esperer aligner 2 input dans un formulaire #98 - WIP: conteneur_inline - saisies - SPIP on GIT)

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.

Donc on en arrive vite à l’une des 2 solutions:

  • 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 »
  • 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…

(et j’ai pas du tout abordé l’aspect perf de l’affichage d’un formulaire en saisie vs un formulaire html…)

Bon ben on y est dans le troll.
On ne pourra donc jamais parler de ce sujet, un de plus dans spip…

Je n’ai ni proposé d’utiliser des saisies pour tous les formulaires, ni proposé de multiplier les saisies (bien au contraire) mais juste de migrer des formulaires très standard, qui, quoi qu’en dise sont les plus nombreux, vers une écriture plus simple et plus maintenable.
Le formulaire instituer est surement un des plus spéciaux (et donc bien entendu je ne l’inclus pas dans la migration) et d’ailleurs, puisqu’on est dans le troll, c’est pas la pseudo refonte qu’on vient de faire qui lui donne plus de sens…

En deux réponses on vient d’enterrer le sujet sans avoir apporter une quelconque réponse autre que dogmatique ou épidermique.
Je vous en remercie.

1 « J'aime »

Juste pour préciser qu’il y a différents moyens d’obtenir ce qu’on veut.

Je n’ai pas une vision très claire du sujet, mais je suppose que le plus important serait d’avoir une déclaration en PHP objet des champs du formulaire (label, explication, erreurs, type, valeur actuelle,…), qui peut ensuite être affichée par différents moyens dans le squelette.

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

Ce qui n’empêcherait pas de ne pas les utiliser totalement pour des cas très particuliers.

C’est un peu ce que font les copain·es ailleurs

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.

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.

Bref, je vois 2 sujets là dedans distincts : la déclaration, et la balise SAISIE.

1 « J'aime »

Mauvaise foi bonjouuuur :slight_smile:

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 :stuck_out_tongue:

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 :smiley:

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. :slight_smile:

Je ne dis pas qu’il y a des choses bloquantes du moins techniquement.
Maintenant, je reviens sur les fonctions que citent @marcimat : ma proposition de réflexion ne concerne que la balise #SAISIE qui aurait l’avantage de simplifier l’écriture et la maintenance en particulier lors de mise au point générale.

Le coté déclaration PHP, génération des saisies, je sais que c’est un autre débat sur la lisibilité et la maintenance des formulaires et là je peux entendre qu’on ait des divergences.
Mais mon propos concerne pour l’instant #SAISIE.

Et là, je ne vois pas ce qui nécessite de recoder en POO ou autre, pour utiliser une balise du type #SAISIE ?
Par contre, l’argument de performance est tout à fait recevable si tant est qu’on lui donne une réalité. A ce titre, je ne vois pas pourquoi la POO changerait les performances (question ouverte de non expert) ?

Bon, bah, en tout cas, y a pas consensus sur cette proposition (intégrer les « saisies » dans le core) … mais comme c’est proposé pour une 5.0, c’est pas trop grave, vous avez le temps de trouver un compromis.

Si on tente de se recentrer sur le sujet de ce topic, y pas consensus non plus sur (toutes) nos propositions. Et je constate qu’on est le 7 février et qu’on n’a pas réussi à sortir une 4.1 comme on l’espérait.

C’est peut-être parce que « court terme » est trop vague et que le calendrier que nous avons proposé de tenir a plus suscité l’envie d’ajouter des trucs et des trucs à une version imminente plutôt que de sortir effectivement une version. Tant mieux pour les envies, tant pis pour le rythme de release et la prochaine version mineure se fait moins imminente. Et les versions de PHP progressent, et on risque de rater le coche de la compat 8.1, de sortir une 4.1 à l’automne, de rater le coche de PHP8.2, et de pas pouvoir sortir une 4.2 qui soit compatible avec les versions PHP maintenues du moment, etc.

Je grossis le trait, certes. Mais je n’arrive pas à savoir combien d’entre nous se rendent compte que c’est de plus en plus difficile de maintenir une base de code qui a plus de 20 ans, écrite, et qui s’écrit toujours comme si on était, en PHP4.

Je ne jette pas l’éponge, mais plus on ajoute du code dans spip (core ou plugins-dist, c’est pareil) sans repenser notre manière de coder, d’assembler, de tester, de publier ce code, on aura de plus en plus de mal à tenir la distance et à se faire plaisir, pour certains.

Pour trouver un compromis, là, dans les jours qui viennent (disons 7, au hasard), est-ce qu’on pourrait partir du principe que la série de SPIP4.x est avant tout une étape, une transition vers une meilleure base technique ? Et qu’on se concentre surtout là-dessus ?

3 « J'aime »

Hello :slight_smile:
En faite, possible que je me trompe, mais pour moi, sauf si nous avons encore des problèmes de compatibilité php ou MySQL, nous devrions sortir spip 4.1 maintenant !
Ce qui n’est pas fini attendra la version 4.2 et puis c’est tout (surtout que si elle sort cet été, il ne reste pas longtemps à attendre…)

Bé oui il me semble qu’on était tous à peu près d’accord pour dire qu’il n’y avait aucune nouvelle intégration (en tout cas de plugins) en 4.1, que des peaufinages et éventuellement quelques PR si bien relu. Et que les ajouts c’est en master 4.2.


RastaPopoulos

Je voudrais juste rappeler que le lancement de ce fil concerne SPIP 4.1, SPIP 4.2 et SPIP 5.0.
Et depuis, il me semble que personne ne discute le contenu de la 4.1 mais plutôt de la 4.2 et surtout 5.0.
Donc ce n’est pas ce fil qui « retarde » la sortie de la 4.1.

Sinon, pour la 4.2, la proposition est toujours de scinder SVP en deux. A cet égard, « SVP référentiel » qui s’occupe de gérer la base des plugins existe et fonctionne, il reste donc à le brancher au nouveau SVP qui s’occupera uniquement de l’installation.
Et pour la partie composer, je ne sais pas.

On peut considérer donc que tout ce qui a été discuter ici en dehors de ces objectifs soit reporter en 5.0 et soit discuté tranquillement les prochains mois. Dans ce cas, j’ai l’impression qu’on peut tenir nos jalons non ?

Sans doute.

Tu as vu le nombre de trucs qui se sont ajoutés dans la 4.1 depuis le lancement de ce topic ? :slight_smile:

Donc, tout dépend du nombre de personnes qui parlent du futur et du nombre de personnes qui s’occupent du présent, et comment ils s’en occupent.

Ben en fait, non :slight_smile: . J’ai un peu de mal à faire la synthèse vu que l’on parle de 3 branches différentes.

En fait, je pense qu’à l’avenir faudrait ouvrir un fil par branche, ça permettrait de mieux suivre les évolutions d’une branche donnée.

Juste pour dire, il y a une 4.1.0-alpha :chipmunk::smiling_face_with_three_hearts: prête qui attend relecture de son annonce :loudspeaker: sur le blog.
@b_b ou autres relectrices & relecteurs :slight_smile:

2 « J'aime »

https://blog.spip.net/858 donc :slight_smile: