function confirmMessage(msg)
{
if ( confirm(msg) )
return true;
else
return false;
}Pour ceux qui se demandent, confirm() ouvre une boîte de dialogue et retourne true si l'utilisateur clique sur "OK", false pour "Annuler".
function confirmMessage(msg)
{
if ( confirm(msg) )
return true;
else
return false;
}
squalyl (./301) :
Laver plus bool que bool.
J'adore, j'en ferais bien un slogan pour ce genre d'extrait.
<CFINCLUDE TEMPLATE="../../include_admin_security.cfm"/><CFIF Not IsDefined('cookie.admin')>
<script language="JavaScript">
alert("You do not have permissions to view this area");
window.open('index.cfm','_self')
</script>
<CFELSE>
<CFIF cookie.admin is 'No'>
<script language="JavaScript">
alert("You do not have permissions to view this area");
window.open('index.cfm','_self')
</script>
</CFIF>
</CFIF>squalyl (./311) :Pas forcément...
./308 ca aurait du sens si ils avaient écrit if(confirm(...) == something)
mais la ils font directement if(confirm(...)) donc la conversion implicite en bool est déja utilisée, ca ne fait aucun sens de vouloir l'éviter pour le retour de cette fonction.
ca ne ferait même pas de sens si la fonction appelante avait absolument besoin d'un bool. Puisque la conversion en bool se ferait au moment ou l'expression passée est évaluée, dans l'appelante.
/* PreOs 0.70 says CALCULATOR is -1 on the Titanium. We don't. */ #define CALCULATOR ((signed char)_CALCULATOR[0]>0?_CALCULATOR[0]:0)
Nil (./312) :squalyl (./311) :Pas forcément...
./308 ca aurait du sens si ils avaient écrit if(confirm(...) == something)
mais la ils font directement if(confirm(...)) donc la conversion implicite en bool est déja utilisée, ca ne fait aucun sens de vouloir l'éviter pour le retour de cette fonction.
ca ne ferait même pas de sens si la fonction appelante avait absolument besoin d'un bool. Puisque la conversion en bool se ferait au moment ou l'expression passée est évaluée, dans l'appelante.
Exemple de base : confirm() peut très bien se mettre à envoyer
0 = timeout
1 = ok
-1 = nok
-2 = interruption par un événement extérieur
2 = validation par un événement extérieur
S'il y a une évolution des données de sortie de confirm(), tu as juste à changer if (confirm()) en if (confirm() > 0), ce qui te permet d'éviter d'avoir à te repalucher tout ton code.
Arvi89 (./315) :Là on parle de changer les données renvoyées par confirm, qui peut tout à fait être utilisée directement…
Bah, lorsqu'une application reçoit des données d'une API, elle n'utilise pas directement mais reformate pour avoir un truc utilisable par le programme, donc oui, ça fait surcouche.
flanker (./314) :Tout dépend de qui développe quoi... si tu n'as pas la main sur une API et que tu sais qu'elle est en bêta ou qu'elle évolue beaucoup, ça peut se défendre. Si tu développes toi-même l'API ou si celle-ci est stable/éprouvée/figée pour une version majeure donnée, tu n'as effectivement aucune raison de faire ça.
Enfin, dans ce cas, chaque programme est obligé de refaire une surcouche à toutes les API qu'il utilise. Puis pour éviter la répétition de code commun, on mettrait ce code dans une bibliothèque séparée, qu'il faudrait à nouveau mettre dans une surcouche pour être sûr qu'il n'y a pas de problème en cas de changement d'API de la surcouche …
flanker (./318) :d'ailleurs, vu que ça n'a pas changé, je me demande pourquoi on demande encore confirmation
à la base, on parle de confirm(), quand même, le truc qui n'a pas bougé depuis 20 ans.
