J’ai une fonction traiter dans un formulaire en cvt sous spip 2.1.0-beta
Le traitement est conforme à ce qui est attendu, un message est construit pouvant être un tableau (ok, erreur)
mais un seul des deux éléments s’affiche
Pour les afficher correctement je n’ai rien trouvé d’autre que de les assembler avec le html :
$mr=$reussite?"
".$reussite."
":’’;
$me=$echec?"
".$echec."
":’’;
$retour=$mr.$me;
return $retour;
et pour les afficher dans le formulaire html :
[
(#ENV*{message_ok})
]
[
(#ENV*{message_erreur})
]
Ça me semble pas cohérent du tout, d’où vient ce comportement à votre avis ???
ps : avec safari j’ai une erreur (que je ne sais pas interpréter) après la fourniture du message :
XHR finished loading: « http://localhost:8888/ecrire/?exec=meta_site »
qui pointe cette ligne du cache.js
try{
xhr.send(type===« POST »||type===« PUT »||type===« DELETE »?s.data:null)}catch(e){
jQuery.handleError(s,xhr,null,e);
complete()}
J’ai une fonction traiter dans un formulaire en cvt sous spip 2.1.0-beta
Le traitement est conforme à ce qui est attendu, un message est construit pouvant être un tableau (ok, erreur)
mais un seul des deux éléments s’affiche
Pour les afficher correctement je n’ai rien trouvé d’autre que de les assembler avec le html :
$mr=$reussite?«
».$reussite.«
»:‹ ›;
$me=$echec?«
».$echec.«
»:‹ ›;
$retour=$mr.$me;
return $retour;
Je ne comprends pas ce qui ne marche pas et ce que tu fais…
J’ai une fonction traiter dans un formulaire en cvt sous spip 2.1.0-beta
Le traitement est conforme à ce qui est attendu, un message est construit pouvant être un tableau (ok, erreur)
mais un seul des deux éléments s’affiche
Pour les afficher correctement je n’ai rien trouvé d’autre que de les assembler avec le html :
$mr=$reussite?«
».$reussite.«
»:‹ ›;
$me=$echec?«
».$echec.«
»:‹ ›;
$retour=$mr.$me;
return $retour;
Je ne comprends pas ce qui ne marche pas et ce que tu fais…
return array(‹ message_ok ›=>$reussite,‹ message_erreur ›=>$echec);
ne fonctionne pas si j’ai à la fois une erreur et une réussite, il n’y a que message_ok ou message_erreur qui est capté par le html, jamais les deux.
ça me semble perturbant à moins que je n’ai rien compris finalement.
et puis il y a cette erreur XHR finished loading seulement présente sur ce formulaire
et pour les afficher dans le formulaire html :
[
(#ENV*{message_ok})
]
[
(#ENV*{message_erreur})
]
ça c’est normal …
en fait si je veux un code valide il faut écrire [(#ENV*{message_ok})] seulement bi
return array(‹ message_ok ›=>$reussite,‹ message_erreur ›=>$echec);
ne fonctionne pas si j’ai à la fois une erreur et une réussite, il n’y a que message_ok ou message_erreur qui est capté par le html, jamais les deux.
ça me semble perturbant à moins que je n’ai rien compris finalement.
L’un indique que le traitement s’est bien déroulé (tourne à droite), l’autre que non (tourne à gauche).
Le fait que les deux soient remplis indiqueraient alors un… « peut-être » (va où tu veux ?) ?
Là c’est du domaine de la logique floue que ne traite pas CVT
Plus sérieusement la question est : pourquoi ne peux-tu pas faire autrement que d’alimenter les deux retours succès + erreur ?
et puis il y a cette erreur XHR finished loading seulement présente sur ce formulaire
Un problème de domaine mal configuré lors d’un appel Ajax, je crois.
Arrive parfois quand tu fais des appel sur « localhost » et que ton site est en ligne…
Plus sérieusement la question est : pourquoi ne peux-tu pas faire autrement que d'alimenter les deux retours succès + erreur ?
- pour ne pas faire deux fois le traitement (un pour vérifier et un pour traiter)
- parce qu'un demi succès (1 traitement en succès+ 1 traitement en echec) peu suffire
mais bon c'est pas bien grave finalement puisque on peut construire un retour succés-erreur quand même.
C'est surtout que je n'ai pas bien compris cette histoire de return ici. Il faudra que je creuse.
Plus sérieusement la question est : pourquoi ne peux-tu pas faire autrement que d'alimenter les deux retours succès + erreur ?
- pour ne pas faire deux fois le traitement (un pour vérifier et un pour traiter)
Ah mais je m'insurge !
si tu mais les verif dans le traitement, c'est un détournement du principe.
Typiquement pour la mediatheque ou il faut dl les fichiers, la verification deballe les fichiers, les prepare, verifie que tout est bon.
Soit il y a une erreur et ça retourne un message
Soit tout est bon et elle ne renvoie rien, et traiter prend la main. Il ne refait pas le travail, mais recupere tout ce que verifier() a préparé.
- parce qu'un demi succès (1 traitement en succès+ 1 traitement en echec) peu suffire
C'est discutable. Une erreur devrait faire revenir à la saisie pour corriger.
Et si il y a une erreur, alors tout le message devrait passer en erreur.
mais bon c'est pas bien grave finalement puisque on peut construire un retour succés-erreur quand même.
C'est surtout que je n'ai pas bien compris cette histoire de return ici. Il faudra que je creuse.
Non, je te déconseille. C'est la veille implémentation d'origine qui a été conservée par compatibilité, mais cela risque de sauter un jour au l'autre. En particulier, ça n'est pas compatible avec l'utilisation du pipeline sur verifier.
Plus sérieusement la question est : pourquoi ne peux-tu pas faire autrement que d’alimenter les deux retours succès + erreur ?
pour ne pas faire deux fois le traitement (un pour vérifier et un pour traiter)
Ah mais je m’insurge !
si tu mais les verif dans le traitement, c’est un détournement du principe.
Typiquement pour la mediatheque ou il faut dl les fichiers, la verification deballe les fichiers, les prepare, verifie que tout est bon.
Soit il y a une erreur et ça retourne un message
Soit tout est bon et elle ne renvoie rien, et traiter prend la main. Il ne refait pas le travail, mais recupere tout ce que verifier() a préparé.
parce qu’un demi succès (1 traitement en succès+ 1 traitement en echec) peu suffire
C’est discutable. Une erreur devrait faire revenir à la saisie pour corriger.
Et si il y a une erreur, alors tout le message devrait passer en erreur.
mais bon c’est pas bien grave finalement puisque on peut construire un retour succés-erreur quand même.
C’est surtout que je n’ai pas bien compris cette histoire de return ici. Il faudra que je creuse.
Non, je te déconseille. C’est la veille implémentation d’origine qui a été conservée par compatibilité, mais cela risque de sauter un jour au l’autre. En particulier, ça n’est pas compatible avec l’utilisation du pipeline sur verifier.
Merci Cédric je vais suivre tes conseils et revoir le passage de vérifier à traiter…
