- Le filtre `|tenter_unserialize` est déprécié.
- Il est remplacé par `|formidable_deserialize`.
- Ce filtre peut recevoir au choix :
* Un tableau, qu'il retourne tel quel
* Un tableau serializé via `json_encode`
* Un tableau serializé via `serialize`
- Dans les deux dernier cas, il renvoie la version deserializé, en cas
de réussite, sinon l'argument passé.
Exemple
````
include_spip('formidable_fonctions');
'filtre');
$a = ['a' => 'a'];
$a = json_encode($a);
var_dump($a);
$a = formidable_deserialize($a);
var_dump($a);
$a = serialize($a);
var_dump($a);
$a = formidable_deserialize($a);
var_dump($a);
$a = serialize($a).'plop';//Serialisation corrompu
var_dump($a);
$a = formidable_deserialize($a);
var_dump($a);
````
Ainsi, pas besoin de convertir tous les formulaires de `serialize` à
`json_encode` à la mise à jour du plugin formidable :
on peut le faire au fur à mesure qu'on modifie les champs/traitements
d'un formulaire.
On utilisera donc ce filtre à chaque fois que l'on veut déchiffrer
depuis la BDD :
- * traitements d'un formulaire
- * saisies d'un formulaire
- * réponse d'un champ multivalué (ex: checkbox)
uniquement par le plugin `formidable_quizz`, actuellement non maintenu
et non publié.
Ce pipeline n'était pas générique, car le remplacement des `@@` ne
concerne pas que l'affichage résumé des réponses, mais aussi en
différent endroit (message de retour par exemple).
On créé deux pipelines plus générique :
- `formidable_pre_raccourcis_arobases`
- `formidable_post_raccourcis_arobases`
On supprime donc le pipeline `formidable_affiche_resume_reponse`.
On simplifie par ailleurs la signature de la fonction
`formidable_raccourcis_arobases_2_valeurs_champs()`.
1. En supprimant les deux derniers arguments passés par références (`$valeurs` et
`$valeurs_libellees`).
La seule raison de ce passage par référence, qui n'était utilisé sur
toute la zone que dans **UN** appel à la fonction, était précisement
de passer les valeurs libellées en arguments du pipeline `formidable_affiche_resume_reponse`. Puisqu'on supprime ce pipeline, plus besoin de ces valeurs.
2. On regroupe tout les paramètres en troisième arguments, dans
$options, tout en assurant une rétrocompatibilité (pas d'autre usage de
`formidable_raccourcis_arobases_2_valeurs_champs()` sur la zone, mais j'ai
du code perso qui l'utilise, et il n'est pas impossible que d'autres
fassent de même.
3. On ajoute une option `'contexte'` pour indiquer le contexte d'appel
de `formidable_raccourcis_arobases_2_valeurs_champs`, ce qui permet de
remplacer utilement le pipeline `formidable_affiche_resume_reponse`.
```
Erreur d’exécution ../plugins-dist/revisions/prive/objets/liste/versions.html | File […]/plugins/formidable/formidable_fonctions.php Line 280 : Argument 2 passed to generer_titre_formulaires_reponse() must be of the type array, null given, called in […]/ecrire/inc/filtres.php on line 4752
```
A priori il faudrait corriger plutot l'appel en amont, mais pour l'heure
il faut que ca sorte.
champs qui n'existeraient pas encore en base pour une réponse donnée.
Partant du constat
1. Que lorsque formidable reçoit une réponse vide (soit par
afficher_si, soit par non remplissage) pour un champ donné, il insère ce
champ en base quand même.
2. Que les seuls cas où le champ non rempli n'est pas présent en base
pour une réponse donnée, c'est quand il a été ajouté dans le formulaire
après l'enregistrement de la réponse.
Il ne paraît pas gênant lorsqu'on appel un crayon sur un champ
inexistant en base pour une réponse donnée de le créer en base, cela
revient juste à faire 1.
les valeurs n'ont pas dans _request() mais dans l'enregistrement d'une
réponse. On peut donc facilement utiliser le raccourci @@ pour afficher
une présentation particulière d'une réponse donnée (cas d'usage : un
plugin perso pour une application métier).
Du coup on fait appel à cette fonction pour affiche_resume_reponse() en
gardant la compatibilité ascendante de ce qui est passé au pipeline
homonyme (dont je doute que qui que ce soit l'utilise, mais c'est une
autre affaire).
n'était pas une correction de trailing spaces, mais un
changement de casse ! J'ignore diable sur quelle touche j'ai cliqué pour
provoquer cela.
Mea culpa
- suppression d'un code mort sur test de valeur brute ou pas brute,
puisque par défaut renvoyait les deux, le test avait lieu en amont
- pour déterminer la valeur humaine, on se base désormais sur
saisie-vues/xxx, ce qui assure d'avoir une valeur humaine aussi lorsque
c'est prévu mais qu'il n'y a pas d'argument datas à la saisie,
typiquement pour les saisies de type evenements (plugin agenda)
enregistrées correspond au seul traitement "enregistrement".
On déplace donc la config dans les réglages de ce traitement.
La migration des réglages est prévues lors de la mise à jour du plugin.
C'est un peu lourd de passer par saisie pour reformater ensuite le HTML en texte brut mais faisons au plus simple.
On ajoute un pipeline qui permet de faire des petites mises en forme perso sur les champs au besoin (ou sur l'affichage de la reponse).
On permet de configurer pour chaque formulaire une chaine qui sera utilisee pour afficher un resume de chaque reponse (les champs @input_1@.. etant remplaces par leur valeur).
Ceci rend les listes de reponse beaucoup plus utilisables.
#VOIR_REPONSE{champ} à utiliser dans une boucle (FORMULAIRES_REPONSES).
Par défaut ça afficher la même chose que #VOIR_SAISIE. Mais on peut faire des variantes pour ne sortir que la valeur (en HTML mais sans le label et l'entourage) ou que la valeur brute dans la base.
#VOIR_REPONSE{selection_1, brut}
#VOIR_REPONSE{selection_1, valeur_uniquement}
En troisième argument on peut aussi passer la chaîne qu'on veut afficher pour les champs qui n'ont pas de réponse (champ vide). Sinon c'est le truc par défaut "Sans réponse". On peut y mettre la chaîne vide si on ne veut rien.
Maïeul
Cerdic
maieul@maieul.net