[spip-dev] CVT toujours éditables

Dev
1

Hello,

il me semble qu'il y a un problème avec les formulaires CVT.
En tout cas moi j'en ai un.

En cas de succès dans une fonction traiter, je retourne
return array(
     'message_ok' => $reponse,
     'editable' => false,
);

Mais dans le html, #ENV{editable} est toujours vrai (un espace).

Je suis remonté jusqu'à balise_FORMULAIRE__contexte()
dans /ecrire/balise/formulaire_

à la ligne 156, le paramètre editable est calculé en fonction du contexte :

$editable = true;
$erreurs = $post = array();
if ($je_suis_poste) {
     $post = traiter_formulaires_dynamiques(true);
     $e = "erreurs_$form";
     $erreurs = isset($post[$e]) ? $post[$e] : array();
     $editable = "editable_$form";
     $editable = (!isset($post[$e]))
           >> count($erreurs)
           >> (isset($post[$editable]) && $post[$editable]);
}

Donc, grosso modo, editable est vrai :
s'il n'y a pas d'erreurs => !isset($post[$e])
ou s'il y a des erreurs => count($erreurs)

Donc tout le temps vrai.

Pour afficher systématiquement le form en cas d'erreur, est ce qu'il ne faudrait pas utiliser isset($post[$e]) au lieu de !isset($post[$e]) ?

En tout cas, quand je supprime le "not", le comportement est celui attendu.

Si ça vous semble cohérent, j'ouvre un ticket ?

2

Salut,

il me semble qu'il y a un problème avec les formulaires CVT.
En tout cas moi j'en ai un.

J'ai eu un souci similaire il y a peu. Je n'étais pas remonté jusqu'à
balise_FORMULAIRE__contexte().

J'avais constaté que quand le formulaire était bien entouré par un
élément avec une class ajax et qu'on interdisait pas ajax dans
traiter, que ediatble passait bien à false...

Je n'avais guère été plus loin dans les investigations.
(cf: http://thread.gmane.org/gmane.comp.web.spip.user/189803/focus=189910)

3

il me semble qu'il y a un problème avec les formulaires CVT.
En tout cas moi j'en ai un.

C'était donc bien moi qui avait un problème.
Comme Cédric me l'a suggéré (merci à lui) :

Je soupçonne plutôt que ton problème vient de ce que ta fonction vérifier renvoie un null au lieu d'un array() vide en l'absence d'erreur.
Le !isset() ne veut pas dire qu'il n'y a pas d'erreurs (c'est le count() qui dit ça) mais qu'il n'y a pas de post (et donc qu'on est à l'affichage initial).

Ma lecture du code était incorrecte, et c'était bien lié au vérifier de mon CVT qui ne renvoyait pas un array() vide.
C'est subtil, mais au moins maintenant je le sais.

4

Pour le coup ce cas limite mériterait d'être mieux géré...

Cédric