[Salvatore] [source:lang/ saisies] Export depuis https://trad.spip.net de la langue fr
[Salvatore] [source:lang/ saisies] Export depuis https://trad.spip.net de la langue fr_tu
[Salvatore] [source:lang/ saisies] Export depuis https://trad.spip.net de la langue it
[Salvatore] [source:lang/ saisies] Mise a jour du bilan depuis https://trad.spip.net
Quand on valide un formulaire au clavier (touche entrée), c'est le 1er bouton submit présent qui est utilisé, mais il ne s'agit forcément du bouton de validation principal : ça peut être un bouton « revenir en arrière », « annuler », etc.
Ainsi on s’assure que ça soit le principal qui soit déclenché.
Il est ajouté via le _hidden du charger afin qu'il soit présent dans tous les formulaires qui déclarent des saisies, même ceux possédant leur propre html.
- formulaire de config en declaration automagique : conserver les clés
secretes
- recherche de l'icone d'une saisie d'abord dans le thème, puis via
`find_in_path()`
- fonctions pour la prise en charge correcte des grilles de questions
comme type de champ extra
- afficher_si : `IN` avec une valeur monovaluée à gauche
- `aisies_deplacer_avant()` et `saisies_deplacer_apres()`
la syntaxe `@toto@ IN 'A,B'` était prévue au départ pour les cas où
`toto` renvoie un array.
Mais côté JS, elle marchait également si @toto@ était une chaine.
Donc `@toto@ IN 'A,B'` était équivalent à `@toto@ == 'A' || @toto@ ==
'B'`. Sans doute une erreur de ma part lors de la réécriture il y a
quelques temps.
Cependant, maintenant que c'est fait, cela parait plutôt
logique/pratique.
Du coup on étend aussi cela côté PHP...
cf. https://contrib.spip.net/Formidable-le-generateur-de-formulaires#comment510112
Cela répond du reste à une demande formulé dans la discussion sur le
sens de `IN` en #44.
Close#163Fix#44
Pour résumer :
- si le champ est monovalué, IN a le sens de "la valeur appartient à ce
tableau"
- si le champ est tabulaire, IN a le sens historique de "au moins une
valeur appartient à ce tableau" (donc plutôt un INTERSECTION)
- on laisse tomber de changer de syntaxe pour exprimer une vrai
INTERSECTION + on garde la petite erreur logique sur IN qui prend le
sens d'intersection
- a priori, pas besoin de dev un INCLUS, et si c'est le cas on fera plus
tard.
Alberto