
Envoyé par
atc666
ceci étant provisoirement fini
NOPE! 
Y'a des horreurs.
Pour commencer, où as-tu pêché ça ?
1 2 3 4 5 6 7 8 9 10
| <script for=window event=onload language="JavaScript">
{
do
{
}
while (typeof file != 'function')
texte='promo'
texte = file('start');
}
</script> |
Bon grâce à toi j'ai au moins appris un truc, je ne connaissais pas les attributs for et event de la balise <script>. Cependant, comme c'est bien marqué en gros ici, Don't use it! C'est une extension Microsoft, ça ne marche que sous MSIE. D'ailleurs, si on réorganise le code, on peut voir ça :
do {} while (typeof file != 'function');
C'est une boucle qui ne fait rien ! Ce type de boucle, qui monopolise le processeur en attendant qu'un certain évènement se produise, est appelé attente active. Et en général, c'est une mauvaise pratique ! Si par hasard, la fonction file n'est jamais définie (par exemple à cause d'une erreur de syntaxe), ton script va boucler à l'infini, et ça va occuper le processeur pour rien. Sous certains navigateurs, ça peut se terminer en freeze avec obligation de fermer la page, voire tuer le programme…
D'autre part,
xhr_object.open("POST", 'new2.php', true);
Pourquoi ce 3e paramètre true ? Tu sais que ça rend la requête synchrone ? Avec ça, la page et les scripts sont bloqués le temps que la réponse du serveur arrive. Tu perds tous les avantages de l'AJAX !
Et puis, fais-moi le plaisir de retirer ces attributs language de tes balises <script>, je te l'ai déjà dit, ils sont obsolètes.
⁂
Ensuite,

Envoyé par
atc666
si je colle mon settimeout sans les 'info' de lancement de la procédure elle tournera quand même ?
Ça, tu devrais le savoir vu que c'est toi qui as codé la fonction. Enfin, je crois… 
En fait, tu n'utilises jamais le paramètre ur de ta fonction. Peut-être que la variable globale texte joue ce rôle à sa place.
Note qu'il est recommandé d'utiliser des paramètres plutôt que des variables globales. En général, moins il y a de variables globales dans la mémoire, plus le script est efficace. Et puis ça fait du code mieux organisé, et donc plus facile à maintenir.
Avec la syntaxe de setTimeout que je t'ai conseillée, en théorie tu peux passer des arguments supplémentaires, comme ceci :
setTimeout(file, 15000, texte);
Mais en pratique ça ne marche pas sous MSIE. Par contre, tu peux tout à fait envelopper l'appel dans une fonction anonyme :
setTimeout(function() { file(texte); }, 15000);
Il faudra que tu t'habitues à ce genre de syntaxe : en JavaScript les fonctions sont des variables comme les autres. Quand on les utilise en tant que variable, on ne les appelle pas, donc on ne met pas de parenthèses. Pour faire un exemple adapté à notre situation :
1 2 3 4 5 6 7 8 9 10 11
| function bidule() {
if (this.readyState == 4) {
if (this.status == 200) {
alert(this.responseText);
} else {
alert("problème de connexion");
}
}
}
xhr.onreadystatechange = bidule; |
Voilà, j'ai utilisé la fonction bidule comme une variable.
⁂

Envoyé par
atc666
Pour le send ,si je t ai bien compris , il doit être après que le readystate soit passé a 4 ?
Non, je voulais dire que pour que ça marche, il faut placer le code de traitement dans la fonction de rappel, puis appeler send. Cela dit, tu as bien corrigé ça dans ton nouveau code, à un détail près : dans le cas où la réponse est déjà dans le cache du navigateur, elle arrivera presque instantanément, et à ce moment-là, peut-être que ta fonction de rappel onreadystatechange ne sera pas encore attachée. Pour corriger cette légère erreur, place ton appel à send après avoir attaché la fonction. En clair :
1 2 3 4
| xhr.onreadystatechange = function() {
...
}
xhr.send(...); |
⁂

Envoyé par
atc666
concernant le "setRequestHeader" j'avoue que je le désignais par pur ignorance

je n'ai pas été foutu de trouver un seul site m'expliquant à quoi il sert et surtout pas quelles paramètres il prend à par celui qu'il a dans mon code
C'est ce qu'on appelle un header HTTP. Un message HTTP est composé de deux parties : les en-têtes (headers) et le corps (body). À ne pas confondre avec le <head> et le <body> d'une page HTML, qui se trouvent tous deux dans le corps du message HTTP. Les en-têtes contiennent des informations telles que le type MIME (content-type), l'encodage (charset), la politique de cache (cache-control ou pragma), les cookies, etc.
En théorie, une requête AJAX en mode post est capable d'envoyer tout type de contenu. Pour indiquer au serveur qu'il s'agit de variables de formulaire, on envoie le type application/x-www-form-urlencoded. C'est le même type MIME que les formulaires HTML classiques. Les données y sont représentées comme dans les requêtes get :
param1=value1¶m2=value2¶m3=value3...
⁂

Envoyé par
atc666
comme je suis super debutant dans le web programming je ne connais aucun outils de débogage ...
Pourtant, c'est pas ça qui manque
Sous Firefox, il y a l'extension Firebug. Tu l'installes, tu relances Firefox et tu fais F12.
Sous IE7+, c'est intégré, fais F12.
Sous Safari, Chrome et Opera, c'est intégré aussi, je me souviens plus exactement mais il y a un menu qui s'appelle « outils de développement » ou quelque chose du genre.
Bref. Tous ces outils sont disponibles pour JS sous la forme de la variable globale console, tu peux donc émettre des informations de déboguage avec la fonction console.log entre autres. Et si tu as déjà fait du déboguage pas-à-pas, ça existe aussi en JS ! Tu peux même forcer un breakpoint en utilisant le mot-clé debugger dans ton code source. Comme tu vois, ce ne sont pas les possiblités qui manquent
Partager