Discussion :

[Gruik]

Salut,

Je suis pas tres satisfait de moi quand je dois créer des gestionnaires d'evenement (ex: onclick sur un élement <input type="button">) à l'intérieur d'une autre fonction où d'une methode. J'ai les memes problèmes quand je dois créer la fonction de gestion des changement d'état HTTP avec les objets xmlHttp.
J'ai surtout des problemes avec le langage lui meme et la portée des variables et de "this", tout ça n'est pas clair dans ma tête

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
MaClasse.prototype.methode = function() {
   /* .... */
   var variable_locale = new Array();
   var entier = 54;
   elementBouton.onclick = function (e) {
      /* Que reference 'this' ici? */
      /* Que reference 'variable_locale' ici? */
      /* Que vaut 'entier' ici? */
   }
   entier = 64;
}

Pour être sur de ce que je fais, en general je crée une fonction externe (ou methode de classe, c'est pareil) pour le gestionnaire d'evenement et je passe par une propriété qui reference l'objet que je rajoute dans l'element.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
MaClasse.prototype.methode = function() {
   /* ... */
   textarea.theObjet = this;
   textarea.onkeyup = MaClasse.gestionnaireKeyUp;
}
 
MaClasse.gestionnaireKeyUp= function(e) {
   var theObj = this.theObjet;  /* this reference l'élément textarea */
   theObj.methodeXX();
   /*.... en général, plein de code qui utilise theObj ... */
}

Et c'est là que ça me choque conceptuellement : on va beaucoup utiliser "theObj" dans une fonction qui n'est pas une methode d'instance de MaClasse. J'aurais préféré utiliser "this", ou encore, faire en sorte que le gestionnaire d'evenement soit directement une methode de MaClasse, ça aurait été mieux.

Quels sont vos avis sur la chose?
Merci

[dingoth]

Alors, voici la réponse qui n'est valable que là où les questions ont été posées.

- this référence elementBouton.
- variable_locale référence le tableau vide créé dans MaClasse.prototype.methode() .
- entier vaudra toujours 64, SAUF si par un curieux hasard de synchronisation,
1) elementBouton.onclick est activé (qu'il existe ET qu'on a cliqué dessus) ET
2) le contenu de onclick (au moins jusqu'au premier appel de 'entier') est appelé
tout ça entre le moment où elementBouton.onclick = function(e) {...} est appelé et le moment où entier = 64 est appelé. Soit en gros, il y a peu de chances (infinitésimal, même), MAIS cela se peut.

En gros, javascript cherche une variable dans la section où la portion de code l'appelle. S'il ne la trouve pas, il cherche dans la section immédiatement supérieure et ainsi de suite.

Pour la deuxième partie de ta question, je ne pourrais répondre en étant absolument certain comme ci-dessus, mais je dirais que JS n'autorisera pas cela à cause de son comportement prototypé. Il existe un moyen un peu barbare de conserver le système que tu souhaites. Il consiste à passer par un intermédiaire pour forcer un appel à MaClasse.prototype.gestionnaireKeyUp() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
MaClasse.prototype.methode = function() {
   /* ... */
   var objThis = this;
   textarea.onkeyup = function(e){ objThis.gestionnaireKeyUp(this, e, param1, param2, param3); }; // fonction intermédiaire.
}
 
MaClasse.prototype.gestionnaireKeyUp = function(source, evenement, param1, param2, param3) {
  /* source vaut le textarea */
  /* evenement vaut l'événement lancé */
  /* this vaut MaClasse.prototype comme souhaité */
}

C'est un peu lourd, certes et lire cela n'est pas des plus facile, mais cela fait ce que tu souhaites comme tu le souhaites. Tu peux en outre, comme je l'ai montré placer plusieurs paramètres qui sont définis dans ta méthode methode.

[Gruik]

Merci pour les reponses, ça devient un peu plus clair

- this référence elementBouton.
- variable_locale référence le tableau vide créé dans MaClasse.prototype.methode() .
- entier vaudra toujours 64, SAUF si par un curieux hasard de synchronisation,
1) elementBouton.onclick est activé (qu'il existe ET qu'on a cliqué dessus) ET
2) le contenu de onclick (au moins jusqu'au premier appel de 'entier') est appelé
tout ça entre le moment où elementBouton.onclick = function(e) {...} est appelé et le moment où entier = 64 est appelé. Soit en gros, il y a peu de chances (infinitésimal, même), MAIS cela se peut.

Donc pour toute fonction B créée dans une fonction A, une poignée sur les variables locales de A utilisées dans B est gardée (et donc ces variables locales de A ne sont pas supprimées par le garbage collector).

En gros, javascript cherche une variable dans la section où la portion de code l'appelle. S'il ne la trouve pas, il cherche dans la section immédiatement supérieure et ainsi de suite.

Oui mais là où c'est tordu c'est que le code de la sous-fonction n'est pas executé en sequence avec le code de la fonction conteneuse..

Pour la deuxième partie de ta question, je ne pourrais répondre en étant absolument certain comme ci-dessus, mais je dirais que JS n'autorisera pas cela à cause de son comportement prototypé.

Pourant j'ai fait ça un peu partout et ça marchait bien, je pensais qu'on pouvait ajouter en live n'importe quelle propriété à n'importe quel objet. Le seul endroit où ça marchait pas (sous IE ou FF, je sais plus), c'est quand j'ai voulu ajouter une reference à mon objet dans un objet XmlHTTP..

Il existe un moyen un peu barbare de conserver le système que tu souhaites. Il consiste à passer par un intermédiaire pour forcer un appel à MaClasse.prototype.gestionnaireKeyUp() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
MaClasse.prototype.methode = function() {
   /* ... */
   var objThis = this;
   textarea.onkeyup = function(e){ objThis.gestionnaireKeyUp(this, e); }; // fonction intermédiaire.
}
 
MaClasse.prototype.gestionnaireKeyUp = function(source, evenement) {
  /* source vaut le textarea */
  /* evenement vaut l'événement lancé */
  /* this vaut MaClasse.prototype comme souhaité */
}

C'est un peu lourd, certes et lire cela n'est pas des plus facile, mais cela fait ce que tu souhaites comme tu le souhaites.

C'est ce que je faisais avant et j'avais peur qu'il se melange les pinceaux avec this, mais bon c'est peut etre mieux

[dingoth]

Merci pour les reponses, ça devient un peu plus clair

De rien

Donc pour toute fonction B créée dans une fonction A, une poignée sur les variables locales de A utilisées dans B est gardée (et donc ces variables locales de A ne sont pas supprimées par le garbage collector).

C'est exactement ça. D'ailleurs, je ne sais même pas s'il y a un garbage collector en JavaScript ^^'

Oui mais là où c'est tordu c'est que le code de la sous-fonction n'est pas executé en sequence avec le code de la fonction conteneuse..

Tout à fait. C'est la programmation événementielle, très utilisée dans les interface graphiques, un browser étant ... une interface graphique.

Pourant j'ai fait ça un peu partout et ça marchait bien, je pensais qu'on pouvait ajouter en live n'importe quelle propriété à n'importe quel objet. Le seul endroit où ça marchait pas (sous IE ou FF, je sais plus), c'est quand j'ai voulu ajouter une reference à mon objet dans un objet XmlHTTP..

C'est autorisé, j'ai peut-être utilisé un abus de langage en disant que JS n'autorisera pas cela, mais je voulais dire que JS ne comprendra pas cela de la même manière que nous. Ce sera peut-être possible de réaliser cela comme tu le souhaites avec JavaScript 2, qui sera un langage orienté objet plutôt que prototype. Mais peut-être que non pour des raisons de compatibilité ascendante. À voir.

C'est ce que je faisais avant et j'avais peur qu'il se melange les pinceaux avec this, mais bon c'est peut etre mieux

C'est également ce que j'utilise.