Dans le deuxième cas, on ne peut ni avoir de méthode, ni de propriété privés, tout est public.
C'est la voie du Javascript : pas d'encapsulation.
La deuxième méthode est celle qui doit être utilisée. La raison est simple : performance. De plus, avec la première méthode, tu risques d'avoir des références cycliques, qui ne sont pas bien nettoyées par les garbage collector des moteurs Javascript.
Personnellement, je définis mes objets comme suit :
Dans le deuxième cas, on ne peut ni avoir de méthode, ni de propriété
privés, tout est public.
C'est la voie du Javascript : pas d'encapsulation.
La deuxième méthode est celle qui doit être utilisée. La raison est
simple : performance. De plus, avec la première méthode, tu risques
d'avoir des références cycliques, qui ne sont pas bien nettoyées par les
garbage collector des moteurs Javascript.
Personnellement, je définis mes objets comme suit :
Dans le deuxième cas, on ne peut ni avoir de méthode, ni de propriété privés, tout est public.
C'est la voie du Javascript : pas d'encapsulation.
La deuxième méthode est celle qui doit être utilisée. La raison est simple : performance. De plus, avec la première méthode, tu risques d'avoir des références cycliques, qui ne sont pas bien nettoyées par les garbage collector des moteurs Javascript.
Personnellement, je définis mes objets comme suit :
Dans le deuxième cas, on ne peut ni avoir de méthode, ni de propriété privés, tout est public.
C'est la voie du Javascript : pas d'encapsulation.
La deuxième méthode est celle qui doit être utilisée. La raison est simple : performance. De plus, avec la première méthode, tu risques d'avoir des références cycliques, qui ne sont pas bien nettoyées par les garbage collector des moteurs Javascript.
Personnellement, je définis mes objets comme suit :
// Lecture du fichier xml var xhr = new XMLHttpRequest(); xhr.overrideMimeType('text/xml'); xhr.open("GET", this.XMLfile, true); xhr.onreadystatechange = function(){alert("ok");this.readXML_callback(xhr);} xhr.send(null); }
Dans le deuxième cas, on ne peut ni avoir de méthode, ni de propriété
privés, tout est public.
C'est la voie du Javascript : pas d'encapsulation.
La deuxième méthode est celle qui doit être utilisée. La raison est
simple : performance. De plus, avec la première méthode, tu risques
d'avoir des références cycliques, qui ne sont pas bien nettoyées par les
garbage collector des moteurs Javascript.
Personnellement, je définis mes objets comme suit :
// Lecture du fichier xml
var xhr = new XMLHttpRequest();
xhr.overrideMimeType('text/xml');
xhr.open("GET", this.XMLfile, true);
xhr.onreadystatechange =
function(){alert("ok");this.readXML_callback(xhr);}
xhr.send(null);
}
Dans le deuxième cas, on ne peut ni avoir de méthode, ni de propriété privés, tout est public.
C'est la voie du Javascript : pas d'encapsulation.
La deuxième méthode est celle qui doit être utilisée. La raison est simple : performance. De plus, avec la première méthode, tu risques d'avoir des références cycliques, qui ne sont pas bien nettoyées par les garbage collector des moteurs Javascript.
Personnellement, je définis mes objets comme suit :
// Lecture du fichier xml var xhr = new XMLHttpRequest(); xhr.overrideMimeType('text/xml'); xhr.open("GET", this.XMLfile, true); xhr.onreadystatechange = function(){alert("ok");this.readXML_callback(xhr);} xhr.send(null); }
Le problème c'est la fonction readXML_callback n'est jamais appelée par contre je passe bien dans le onreadystatechange (ou j'ai mis un alert)
Merci encore,
Matt...
Pascal
bertrand a écrit :
Le problème c'est la fonction readXML_callback n'est jamais appelée par contre je passe bien dans le onreadystatechange (ou j'ai mis un alert)
Bonjour,
Le mieux serait de passer la fonction de "callback" en argument, et que celle-ci soit totalement extérieure à l'objet "MyRequeteMulti".
Par exemple :
<code>
// passage de la fonction de retour en 2e argument MyRequeteMulti.prototype.readXML = function(XMLfile, callback) { /* (création de l'objet xhr) ... */ xhr.onreadystatechange = function() { // la gestion complète de l'état est incorporée ici if(xhr.readyState == 4) { if(xhr.status == 200) { // réussite => appel de la fn de retour avec la réponse en arg callback(xhr.responseXML); } else { alert("Erreur"); } } } xhr.send(null); }
// définition externe de la fonction de retour function xhrCallback(xhrResponse) { /* (traitement de la réponse) ... */ }
// création de l'objet et passage du callback var myRM = new MyRequeteMulti(); myRM.readXML("hostedFile", xhrCallback);
</code>
Cordialement, Pascal
bertrand a écrit :
Le problème c'est la fonction readXML_callback n'est jamais appelée par
contre je passe bien dans le onreadystatechange (ou j'ai mis un alert)
Bonjour,
Le mieux serait de passer la fonction de "callback" en argument, et que
celle-ci soit totalement extérieure à l'objet "MyRequeteMulti".
Par exemple :
<code>
// passage de la fonction de retour en 2e argument
MyRequeteMulti.prototype.readXML = function(XMLfile, callback) {
/* (création de l'objet xhr) ... */
xhr.onreadystatechange = function() {
// la gestion complète de l'état est incorporée ici
if(xhr.readyState == 4) {
if(xhr.status == 200) {
// réussite => appel de la fn de retour avec la réponse en arg
callback(xhr.responseXML);
} else {
alert("Erreur");
}
}
}
xhr.send(null);
}
// définition externe de la fonction de retour
function xhrCallback(xhrResponse) {
/* (traitement de la réponse) ... */
}
// création de l'objet et passage du callback
var myRM = new MyRequeteMulti();
myRM.readXML("hostedFile", xhrCallback);
Le problème c'est la fonction readXML_callback n'est jamais appelée par contre je passe bien dans le onreadystatechange (ou j'ai mis un alert)
Bonjour,
Le mieux serait de passer la fonction de "callback" en argument, et que celle-ci soit totalement extérieure à l'objet "MyRequeteMulti".
Par exemple :
<code>
// passage de la fonction de retour en 2e argument MyRequeteMulti.prototype.readXML = function(XMLfile, callback) { /* (création de l'objet xhr) ... */ xhr.onreadystatechange = function() { // la gestion complète de l'état est incorporée ici if(xhr.readyState == 4) { if(xhr.status == 200) { // réussite => appel de la fn de retour avec la réponse en arg callback(xhr.responseXML); } else { alert("Erreur"); } } } xhr.send(null); }
// définition externe de la fonction de retour function xhrCallback(xhrResponse) { /* (traitement de la réponse) ... */ }
// création de l'objet et passage du callback var myRM = new MyRequeteMulti(); myRM.readXML("hostedFile", xhrCallback);
</code>
Cordialement, Pascal
bertrand
Pascal a écrit :
Le mieux serait de passer la fonction de "callback" en argument, et que celle-ci soit totalement extérieure à l'objet "MyRequeteMulti".
Par exemple :
<code>
// passage de la fonction de retour en 2e argument MyRequeteMulti.prototype.readXML = function(XMLfile, callback) { /* (création de l'objet xhr) ... */ xhr.onreadystatechange = function() { // la gestion complète de l'état est incorporée ici if(xhr.readyState == 4) { if(xhr.status == 200) { // réussite => appel de la fn de retour avec la réponse en arg callback(xhr.responseXML); } else { alert("Erreur"); } } } xhr.send(null); }
// définition externe de la fonction de retour function xhrCallback(xhrResponse) { /* (traitement de la réponse) ... */ }
// création de l'objet et passage du callback var myRM = new MyRequeteMulti(); myRM.readXML("hostedFile", xhrCallback);
</code>
Cordialement, Pascal
Bonsoir,
Ok, mais je veux que le traitement fasse partie intégrante de l'objet donc voici ce que j'ai adopté :
Par ailleurs, pourquoi ma fonction n'était pas appelée ???
Merci,
Matt...
Pascal a écrit :
Le mieux serait de passer la fonction de "callback" en argument, et que
celle-ci soit totalement extérieure à l'objet "MyRequeteMulti".
Par exemple :
<code>
// passage de la fonction de retour en 2e argument
MyRequeteMulti.prototype.readXML = function(XMLfile, callback) {
/* (création de l'objet xhr) ... */
xhr.onreadystatechange = function() {
// la gestion complète de l'état est incorporée ici
if(xhr.readyState == 4) {
if(xhr.status == 200) {
// réussite => appel de la fn de retour avec la réponse en arg
callback(xhr.responseXML);
} else {
alert("Erreur");
}
}
}
xhr.send(null);
}
// définition externe de la fonction de retour
function xhrCallback(xhrResponse) {
/* (traitement de la réponse) ... */
}
// création de l'objet et passage du callback
var myRM = new MyRequeteMulti();
myRM.readXML("hostedFile", xhrCallback);
</code>
Cordialement,
Pascal
Bonsoir,
Ok, mais je veux que le traitement fasse partie intégrante de l'objet
donc voici ce que j'ai adopté :
Le mieux serait de passer la fonction de "callback" en argument, et que celle-ci soit totalement extérieure à l'objet "MyRequeteMulti".
Par exemple :
<code>
// passage de la fonction de retour en 2e argument MyRequeteMulti.prototype.readXML = function(XMLfile, callback) { /* (création de l'objet xhr) ... */ xhr.onreadystatechange = function() { // la gestion complète de l'état est incorporée ici if(xhr.readyState == 4) { if(xhr.status == 200) { // réussite => appel de la fn de retour avec la réponse en arg callback(xhr.responseXML); } else { alert("Erreur"); } } } xhr.send(null); }
// définition externe de la fonction de retour function xhrCallback(xhrResponse) { /* (traitement de la réponse) ... */ }
// création de l'objet et passage du callback var myRM = new MyRequeteMulti(); myRM.readXML("hostedFile", xhrCallback);
</code>
Cordialement, Pascal
Bonsoir,
Ok, mais je veux que le traitement fasse partie intégrante de l'objet donc voici ce que j'ai adopté :
Par ailleurs, pourquoi ma fonction n'était pas appelée ???
Merci,
Matt...
Pascal
bertrand a écrit :
Ok, mais je veux que le traitement fasse partie intégrante de l'objet
C'est dommage, car de ce fait l'objet, qui traite principalement de la création d'une requête type Ajax, n'est pas réutilisable pour d'aut res traitements possibles de la réponse.
Par ailleurs, pourquoi ma fonction n'était pas appelée ???
Parce que le contexte de "this" n'était pas créé au moment de la définition de la fonction appelée par l'évènement "onreadystatech ange". Il devait certainement y avoir un message d'erreur, du genre : "this n'est pas défini".
Pascal
bertrand a écrit :
Ok, mais je veux que le traitement fasse partie intégrante de l'objet
C'est dommage, car de ce fait l'objet, qui traite principalement de la
création d'une requête type Ajax, n'est pas réutilisable pour d'aut res
traitements possibles de la réponse.
Par ailleurs, pourquoi ma fonction n'était pas appelée ???
Parce que le contexte de "this" n'était pas créé au moment de la
définition de la fonction appelée par l'évènement "onreadystatech ange".
Il devait certainement y avoir un message d'erreur, du genre : "this
n'est pas défini".
Ok, mais je veux que le traitement fasse partie intégrante de l'objet
C'est dommage, car de ce fait l'objet, qui traite principalement de la création d'une requête type Ajax, n'est pas réutilisable pour d'aut res traitements possibles de la réponse.
Par ailleurs, pourquoi ma fonction n'était pas appelée ???
Parce que le contexte de "this" n'était pas créé au moment de la définition de la fonction appelée par l'évènement "onreadystatech ange". Il devait certainement y avoir un message d'erreur, du genre : "this n'est pas défini".
Pascal
bertrand
bertrand a écrit :
Ok, mais je veux que le traitement fasse partie intégrante de l'objet donc voici ce que j'ai adopté :
Je comprends pas trop le "new this.sStructure...", étant donné qu'il est défini comme une méthode de "MyRequeteMulti". Si c'est vraiment un nouvel objet qui doit être créé, je préfèr e le voir défini en dehors, mais bon, il y a peut-être une raison que j'ignore.
Ensuite, je modifierai mon objet pour le faire avec des prototypes...
Autant le faire tout de suite, ça ne gâche rien, au contraire.
Cordialement, Pascal
bertrand a écrit :
Je voudrais savoir si ma façon de faire est bien :
A quel point de vue, codification, fonctionnalités, autre ?
Je comprends pas trop le "new this.sStructure...", étant donné qu'il est
défini comme une méthode de "MyRequeteMulti".
Si c'est vraiment un nouvel objet qui doit être créé, je préfèr e le voir
défini en dehors, mais bon, il y a peut-être une raison que j'ignore.
Ensuite, je modifierai mon objet pour le faire avec des prototypes...
Autant le faire tout de suite, ça ne gâche rien, au contraire.
Je comprends pas trop le "new this.sStructure...", étant donné qu'il est défini comme une méthode de "MyRequeteMulti". Si c'est vraiment un nouvel objet qui doit être créé, je préfèr e le voir défini en dehors, mais bon, il y a peut-être une raison que j'ignore.
Ensuite, je modifierai mon objet pour le faire avec des prototypes...
Autant le faire tout de suite, ça ne gâche rien, au contraire.
Cordialement, Pascal
Mickaël Wolff
bertrand a écrit :
bertrand a écrit :
Bonsoir,
Je voudrais savoir si ma façon de faire est bien :
C'est une manière de faire. Elle peut se justifier. Cependant, ici, on ne comprend pas l'intérêt de toute cette complexité. Sans commentaires, sans justification, on peut difficilement critiquer ton design.
Je voudrais savoir si ma façon de faire est bien :
C'est une manière de faire. Elle peut se justifier. Cependant, ici,
on ne comprend pas l'intérêt de toute cette complexité. Sans
commentaires, sans justification, on peut difficilement critiquer ton
design.
Je voudrais savoir si ma façon de faire est bien :
C'est une manière de faire. Elle peut se justifier. Cependant, ici, on ne comprend pas l'intérêt de toute cette complexité. Sans commentaires, sans justification, on peut difficilement critiquer ton design.