Régression ? Passage-de-tableaux-en-parametres-sous-forme-de-chaine
#136
Closed
opened 1 year ago by g0uZ
·
14 comments
No Branch/Tag Specified
constructeur_glisser_deposer
conteneur_inline
explication_simplifier_conteneur
fieldset_simplifier_conteneur
issue24_data_choix_autre
issue99
issue_48
master
no_submit
php8
v1
v2
v3
v1.42.11
v1.42.5
v2.0.0
v2.0.1
v2.0.2
v2.0.3
v2.0.4
v2.0.5
v2.1.0
v2.1.1
v2.1.2
v2.1.3
v2.10.0
v2.11.0
v2.11.1
v2.11.2
v2.12.0
v2.13.0
v2.14.0
v2.14.1
v2.14.2
v2.14.3
v2.14.4
v2.14.5
v2.14.6
v2.14.7
v2.14.8
v2.15.0
v2.15.1
v2.15.2
v2.16.0
v2.16.1
v2.16.2
v2.17.0
v2.17.1
v2.18.0
v2.18.1
v2.18.10
v2.18.11
v2.18.12
v2.18.13
v2.18.14
v2.18.15
v2.18.16
v2.18.17
v2.18.18
v2.18.19
v2.18.2
v2.18.20
v2.18.21
v2.18.22
v2.18.23
v2.18.24
v2.18.3
v2.18.4
v2.18.5
v2.18.6
v2.18.7
v2.18.8
v2.18.9
v2.19.0
v2.19.1
v2.19.2
v2.19.3
v2.19.4
v2.19.5
v2.19.6
v2.19.7
v2.19.8
v2.19.9
v2.2.0
v2.2.1
v2.2.2
v2.2.3
v2.20.0
v2.20.1
v2.21.0
v2.21.1
v2.21.2
v2.21.3
v2.21.4
v2.22.0
v2.23.0
v2.23.1
v2.23.2
v2.23.3
v2.23.4
v2.23.5
v2.23.6
v2.24.0
v2.24.1
v2.24.2
v2.24.3
v2.25.0
v2.25.1
v2.25.2
v2.25.3
v2.25.4
v2.26.0
v2.26.1
v2.26.10
v2.26.2
v2.26.3
v2.26.4
v2.26.5
v2.26.6
v2.26.7
v2.26.8
v2.26.9
v2.27.0
v2.28.0
v2.3.0
v2.3.1
v2.4.0
v2.5.0
v2.5.1
v2.5.10
v2.5.11
v2.5.12
v2.5.13
v2.5.14
v2.5.15
v2.5.16
v2.5.17
v2.5.18
v2.5.19
v2.5.2
v2.5.20
v2.5.21
v2.5.22
v2.5.23
v2.5.24
v2.5.25
v2.5.26
v2.5.27
v2.5.28
v2.5.29
v2.5.3
v2.5.30
v2.5.4
v2.5.5
v2.5.6
v2.5.7
v2.5.8
v2.5.9
v2.6.0
v2.6.1
v2.6.2
v2.6.3
v2.7.0
v2.7.1
v2.7.10
v2.7.11
v2.7.12
v2.7.13
v2.7.14
v2.7.2
v2.7.3
v2.7.4
v2.7.5
v2.7.6
v2.7.7
v2.7.8
v2.7.9
v2.8.0
v2.8.1
v2.9.0
v3.0.0
v3.1.0
v3.10.0
v3.10.1
v3.11.0
v3.11.1
v3.11.2
v3.12.0
v3.12.1
v3.12.2
v3.12.3
v3.12.4
v3.12.5
v3.12.6
v3.12.7
v3.13.0
v3.13.1
v3.13.2
v3.13.3
v3.13.4
v3.14.0
v3.15.0
v3.16.0
v3.16.1
v3.17.0
v3.18.0
v3.18.1
v3.18.10
v3.18.11
v3.18.12
v3.18.13
v3.18.14
v3.18.2
v3.18.3
v3.18.4
v3.18.5
v3.18.6
v3.18.7
v3.18.8
v3.18.9
v3.19.0
v3.19.1
v3.19.2
v3.19.3
v3.19.4
v3.19.5
v3.19.6
v3.2.0
v3.2.1
v3.20.0
v3.21.0
v3.21.1
v3.21.2
v3.21.3
v3.21.4
v3.22.0
v3.22.1
v3.23.0
v3.23.1
v3.23.2
v3.23.3
v3.23.4
v3.24.0
v3.25.0
v3.25.1
v3.26.0
v3.26.1
v3.27.0
v3.27.1
v3.27.2
v3.27.3
v3.27.4
v3.27.5
v3.27.6
v3.27.7
v3.28.0
v3.28.1
v3.28.10
v3.28.11
v3.28.12
v3.28.13
v3.28.14
v3.28.15
v3.28.16
v3.28.2
v3.28.3
v3.28.4
v3.28.5
v3.28.6
v3.28.7
v3.28.8
v3.28.9
v3.29.0
v3.29.1
v3.3.0
v3.3.1
v3.3.2
v3.3.3
v3.3.4
v3.30.0
v3.30.1
v3.30.2
v3.31.0
v3.31.1
v3.31.2
v3.31.3
v3.32.0
v3.36.2
v3.37.0
v3.37.1
v3.38.0
v3.38.2
v3.39.0
v3.4.0
v3.40.0
v3.40.1
v3.41.0
v3.41.3
v3.41.5
v3.41.6
v3.42.0
v3.42.1
v3.42.2
v3.42.5
v3.42.6
v3.42.7
v3.42.8
v3.43.0
v3.43.2
v3.43.3
v3.43.4
v3.43.5
v3.44.0
v3.44.1
v3.45.0
v3.45.1
v3.45.2
v3.46.0
v3.47.0
v3.47.1
v3.47.2
v3.47.3
v3.48.0
v3.48.1
v3.48.2
v3.49.0
v3.49.1
v3.5.0
v3.5.1
v3.50.0
v3.50.1
v3.50.2
v3.51.0
v3.51.1
v3.51.2
v3.51.3
v3.51.4
v3.51.5
v3.51.6
v3.51.7
v3.51.8
v3.52.0
v3.52.1
v3.52.2
v3.53.0
v3.53.1
v3.53.2
v3.53.3
v3.54.0
v3.54.1
v3.54.10
v3.54.2
v3.54.4
v3.54.6
v3.54.7
v3.54.8
v3.54.9
v3.55.0
v3.55.1
v3.55.2
v3.55.3
v3.55.4
v3.56.0
v3.56.1
v3.56.2
v3.56.3
v3.56.4
v3.56.5
v3.6.0
v3.6.1
v3.6.2
v3.6.3
v3.6.4
v3.7.0
v3.7.1
v3.7.2
v3.8.0
v3.8.1
v3.8.10
v3.8.11
v3.8.2
v3.8.3
v3.8.4
v3.8.5
v3.8.6
v3.8.7
v3.8.8
v3.8.9
v3.9.0
v3.9.1
v4.0.2
v4.0.3
v4.0.4
v4.1.0
v4.2.0
v4.2.1
v4.2.3
v4.3.0
v4.3.1
v4.3.2
v4.3.3
v4.3.4
v4.3.5
v4.3.6
v4.4.0
v4.4.1
v4.5.0
v4.5.1
v4.6.0
v4.6.1
v4.7.0
No Label
amélioration
bug
doublon
help wanted
invalide
question
refusé
Milestone
Set milestone
Clear milestone
No items
No Milestone
Assignees
Assign users
Clear assignees
No Assignees
8 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.
No due date set.
Dependencies
This issue currently doesn't have any dependencies.
Reference in new issue
There is no content yet.
Delete Branch '%!s(MISSING)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
No
Yes
Cette fonctionnalité semble cassée : https://contrib.spip.net/Doc-Saisies-complementaire#Passage-de-tableaux-en-parametres-sous-forme-de-chaine
J'ai testé sur Spip 3.2.11 et 4.0.0 avec le plugin saisies v4.0.3 :
oui, effectivement, j'ai cassé cela, pour des raisons d'optimisation.
5a9d92d
il vaut mieux utiliser #GENERER_SAISIES.
Je ne comprends pas ta réponde @maieul ni la justification du commit
Le message de commit dit
Alors que le commit fait le contraire en enlevant
|saisies_chaine2tableau
des squelettes concernés et que la feature documentée est cassée. Ça colle pas trop avec "jouons la sécurité de ne rien casser" heinJe ne comprends pas l'argument de casser du fonctionnel pour un gain de perf qui parait tout à fait anecdotique.
Je ne comprends pas la réponse qui consiste à dire "il vaut mieux utiliser
#GENERER_SAISIES
"... Ou alors ça y est c'est officiel : le plugin se veut définitivement un grosse boite noire dans lequel seul l'usage des tableaux de déclaration PHP est supporté et l'utilisation de la balise#SAISIE{...}
devient un usage de seconde classe ?Enfin anecdotiquement, je pense que coder
if (substr($option, 0, 4) === 'data')
au lieu de
if (in_array($option, ['data', 'datas', 'data_rows', 'data_cols'])
est une paresse fautive qui expose à ce qu'un utilisateur retrouve son argument
datatruc
tout cassé sans aucune bonne raison, alors même que c'est un codage plus lent et moins efficace...Bref, je le redis parce que je l'ai déjà dit : il faudrait faire un peu preuve de mesure et de reflexion dans les refactoring à la serpe, et la règle générale c'est qu'on ne casse une feature que si on est obligé et si on a vraiment une bonne raison pour ça.
Là je n'en vois aucune.
Pour info une recherche sur la zone ramene 2 plugins qui utilisent ce format, pour des saisies checkbox dans les formulaires de configuration de responsivenav et paravent.
À part ça j'aime beaucoup les saisies pour leur simplicité d'emploi direct... en HTML. Ne dépréciez pas cet usage !
Vu de ma fenêtre j'ai quand même l'impression que, outre les différences de point de vue sur les objectifs de ce plugin, on est un peu en limite de l'exercice et qu'il faudrait peut-être réfléchir à le refactorer voire à le découper.
J'ai vu passer des litanies surement bienveillantes de commits sur ce plugin les derniers mois et je ne trouve pas cela rassurant pour un plugin extrêmement utilisé. Cela manque de stabilité alors que le core devrait être finalement beaucoup plus stable vu les services qu'il offrent.
Et là où je rejoins Cedric à 100% c'est que la balise #SAISIE devrait être l'usage par défaut pour les formulaires simples et que l'usage du PHP devrait être réservé à des cas particuliers, ceux qui nécessitent des traitements complexes ou d'ajout de saisies par exemple.
A partir de là, les modifications de la balise #SAISIE devrait être très limitée et ne pas introduire de régression sauf en cas extrême.
Un plugin autant utilisé devrait faire l'objet de plus de discussions avant modification. Ce n'est pas parce qu'on a des tickets et des PR qu'on peut aussi modifier à tout va en disant tu n'avais qu'à lire les tickets et les PR.
Mais je sais que c'est difficile car on est pas tous disponibles au moment opportun.
On a rarement ce type de sujet avec les plugins du core...
Mes deux sous.
J'ai l'avis totalement opposé (obviously :p) : ce n'est pas à la personne qui crée un formulaire de savoir s'il va être réutilisé/étendu par d'autres plus tard, en tout cas quand il s'agit des choses partagées, contrib communes (objets, config, des plugins communs). TOUT formulaire commun (qu'on l'on maintient ensemble) peut être étendu/réutilisé par d'autres plus tard, c'est cet état d'esprit qui prévaut selon moi.
Et donc non : par défaut, SI un form est décidé avec Saisies (ceux qui n'utilisent pas du tout Saisies on n'en parle pas), alors ça devrait être en priorité en saisies explicitement déclarées. Et ensuite seulement les quelques forms vraiment super perso où on est sûr que ça sera jamais à étendre/réutiliser, là on peut les faire en #SAISIE si on préfère.
L'API déclarative est la seule manière qui permet que les champs d'un formulaire soit "découverts" magiquement ensuite par d'autres plugins, et donc réutilisés (form tout-en-un intégrant les saisies d'un autre formulaire par ex), ou étendu (insertion, déplacement, modif de label, obligatoire, ou autres options, etc), de manière hyper simple, en 3 lignes code, super propre sans regex, etc. C'est notamment le plus important pour les objets déclarés (objets qui font… l'objet de multiples réutilisations génériques et automatiques ensuite par moult autres plugins, Champs Extras, Profils, etc).
Voilà pour ce qui est de l'usage "à recommander" (après chacun fait ce qu'il veut), d'après moi.
En revanche, je suis tout à fait d'accord avec ce qui précède : ya pas à casser à tout va si on a la possibiltié de garder la compat, et que ça ne change pas grand chose à la performance.
Quelques points
a. Même si je pense que fondamentalement, saisies devrait être utilisé vers la normalisation en tableau de saisies plutôt qu'en
#SAISIE
(pour profiter notamment de la decelaration simplifié de verification + des afficher_si + de la possibilité d'extensivité comme le disait rastapopoulos), il est bien évident que, vu l'historique, le support de la balise#SAISIE
doit être maintenu.b. Lorsque j'avais supprimé le support de |, je n'avais pas en tete le passage par #GENERER_SAISIES (mea culpa), mais
#ARRAY
. En effet, la syntaxe avec|
permet, fondementalement, de passer un tableau clé/valeur. Elle a été pensée d'abord et avant pour la declaration de saisies en constructeur (type champ extra interface/formidable), mais pas en squelette, ou nous avons précisement dans le monde SPIP le#ARRAY
. Que cela ait pu être utilisé en squelette est une conséquence indirecte et non désirée (et que cela ait été documentée comme tel également).saisies_chaine2tableau()
doit faire appel à_T_ou_typo()
et c'est bien cette appel systématique qui pose souci.Cela étant, on peut tout à fait decider de revenir en arrière.
Alors oui attention, précision sur le point d'origine du ticket : le fait de balancer la syntaxe "texte brut décrivant tant bien que mal un tableau" quand on est dans un squelette, n'a JAMAIS été documenté. Là il s'agit d'un article WIKI, et non de la doc, et qui dit donc "ah tiens apparemment ça marche aussi comme ça". Ce qui ne signifie absolument pas que c'est prévu et supporté officiellement.
La syntaxe en texte brut est prévue uniquement parce que dans le constructeur (Extras, Formidable), quand on génère l'interface pour configurer les options, c'est la manière la plus simple de faire remplir par interface une suite de clés/valeurs.
Mais en revanche, quand on est dev et qu'on écrit soi-même tout dans le code, on DOIT utiliser un tableau, il y a tout ce qu'il faut pour ça, array() en PHP et #ARRAY en squelette, et pas du tout du texte brut.
Donc pour ce point précis : non ce n'est pas supporté, et ça devrait être enlevé du wiki, et je ne suis pas d'accord pour dire que ce point devrait être supporté à l'infini sans rien casser.
Ps : j'ajouterai un point plus personnel/humain. On est d'accord que ce plugin joue un rôle très important, et qu'il doit donc être très surveillé. Mais quand on recoit peu d'écho à nos questionnements, ou quand les seuls echos qu'on recoit c'est "oulà cela m'a l'air compliqué", cela ne donne pas particulièrement envie. J'ajouterai que ces derniers temps, j'ai investi de l'energie pour
Donc qu'il y ait un commit à la serpe, correspondant à un objetcif global "optimiser", sur un usage secondaire est pas vraiment documenté...
Point de vue "simple utilisateur" :
#SAISIE{...}
dont j'apprécie la rapidité et la simplicité d'écriture pour les formulaires#GENERER_SAISIES{...}
me semble tout à fait réservé aux (rares) cas où il faut faire un truc compliqué avec prise de tête pour retrouver la syntaxe, faire le débog......ce qui implique stabilité et non-rupture de compatibilité..
Par contre là ou je met un bemol @rastapopoulos c'est sur le "pas officiellement documenté", et là pour le coup "c'est notre faute" car on n'a pas de mecanisme encore dans saisies pour distinguer la generation de l'article "référence de saisies" (https://contrib.spip.net/Reference-des-saisies#option_data qui mentionne bien le pipe alors que cela devrait mentionner #ARRAY/data) de la doc en contexte dans un constructeur (qui mentionne bien le pipe).
Mais c'est un autre ticket #90.
Oui c'est pas idiot. Sauf que le principe de réalité s'applique et que 90% des formulaires ne nécessiteront jamais d'évolution externe plus facile avec la déclaration PHP j'en convient. Et même si un jour ça doit être le cas, il est assez facile de passer de #SAISIE à #GENERER_SAISIES.
Voilà pourquoi je reste sur ma position ;-).
Mais on va en rester là car on commence à dériver du ticket et la brigade de répression des dérives ticketales va nous tomber dessus.
@cy.altern oui tout à fait mais mon premier message était erronnée. La rupture ne concerne pas SAISIE vs GENERER_SAISIE mais le support du pipe en squelette en lieu et place du #ARRAY.
Ouiiiiiiiiiiiiiiii ? On m'appelle ? ^^
On ferme, puisqu'il s'agit d'une rupture d'une syntaxe non officiellement documentée, apportée sur une version majeure du plugins saisies.