Si on exeécute ce code :
<SCRIPT>
for (var o in window) document.write(o +" : " + typeof(window[o]) + "<BR>")
</SCRIPT>
On obtient une liste des objets contenus dans window, avec leur type.
Ça marche au poil dans Opera, Mozilla et Safari, mais avec MSIE (7),
il me manque toutes les fonctions.
Y a-t-il un meilleur truc pour avoir la collection complète ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Méta-MCI \(MVP\)
Bonjour !
De quelles fonctions parles-tu ? S'il s'agit des évènements (OnLoad, OnKeyPress, ...), ils y sont bien. S'il s'agit de fonctions contenues dans des scripts, alors, c'est normal, car javascript (comme vbscript, pythonscript, rubyscript, etc.) ne fait pas partie du DOM (même s'il peut l'utiliser).
@-salutations -- Michel Claveau
Bonjour !
De quelles fonctions parles-tu ? S'il s'agit des évènements (OnLoad,
OnKeyPress, ...), ils y sont bien.
S'il s'agit de fonctions contenues dans des scripts, alors, c'est
normal, car javascript (comme vbscript, pythonscript, rubyscript, etc.)
ne fait pas partie du DOM (même s'il peut l'utiliser).
De quelles fonctions parles-tu ? S'il s'agit des évènements (OnLoad, OnKeyPress, ...), ils y sont bien. S'il s'agit de fonctions contenues dans des scripts, alors, c'est normal, car javascript (comme vbscript, pythonscript, rubyscript, etc.) ne fait pas partie du DOM (même s'il peut l'utiliser).
@-salutations -- Michel Claveau
Claude Schneegans
>>De quelles fonctions parles-tu ?
TOUTES : Toutes les fonctions dites "in-line", comme abort () add () addBehavior () AddChannel () AddDesktopComponent () addElement () AddFavorite () addImport () ...alouette, de même que les fonctions globales comme : alert () atob () back () blur () btoa ()... et même les méthodes du DOM : getElementById () getElementsByName () getElementsByTagName ()...
Avec Opera, Safari, Mords-zy-la, elles sont toutes listées dans la collection sur window ou document, avec IE c'est peau de zébi.
J'ai fini par trouver un truc : je les liste toutes dans un tableau à partir de la doc chez Microsoft, et je vais les examiner en plus des autre objets trouvés dans la collection. Mais c'est vraiment une entourloupe.
>>De quelles fonctions parles-tu ?
TOUTES :
Toutes les fonctions dites "in-line", comme
abort ()
add ()
addBehavior ()
AddChannel ()
AddDesktopComponent ()
addElement ()
AddFavorite ()
addImport ()
...alouette, de même que les fonctions globales comme :
alert ()
atob ()
back ()
blur ()
btoa ()...
et même les méthodes du DOM :
getElementById ()
getElementsByName ()
getElementsByTagName ()...
Avec Opera, Safari, Mords-zy-la, elles sont toutes listées dans la
collection sur window ou document,
avec IE c'est peau de zébi.
J'ai fini par trouver un truc :
je les liste toutes dans un tableau à partir de la doc chez Microsoft,
et je vais les examiner
en plus des autre objets trouvés dans la collection.
Mais c'est vraiment une entourloupe.
TOUTES : Toutes les fonctions dites "in-line", comme abort () add () addBehavior () AddChannel () AddDesktopComponent () addElement () AddFavorite () addImport () ...alouette, de même que les fonctions globales comme : alert () atob () back () blur () btoa ()... et même les méthodes du DOM : getElementById () getElementsByName () getElementsByTagName ()...
Avec Opera, Safari, Mords-zy-la, elles sont toutes listées dans la collection sur window ou document, avec IE c'est peau de zébi.
J'ai fini par trouver un truc : je les liste toutes dans un tableau à partir de la doc chez Microsoft, et je vais les examiner en plus des autre objets trouvés dans la collection. Mais c'est vraiment une entourloupe.
Claude Schneegans
>>Per exemple, exécute le code ci-dessous,
avec Morzilla tu trouves 72 fonctions, avec Opera : 61, avec Safari : 67, et même le très jeune Chrome de chez Glouglou t'en retourne 58. Mais chez Microstuff, on est muet :-(
<SCRIPT> var type, txt = "", tot = 0; for (var o in document) { try { type = typeof(document[o]) } catch(e){type=""} if (type == "function") { txt += o +" : " + type + "<BR>"; tot++; } } if (tot) document.write(txt + "total = " + tot) else document.write("Peau de zébi") </SCRIPT>
>>Per exemple, exécute le code ci-dessous,
avec Morzilla tu trouves 72 fonctions,
avec Opera : 61,
avec Safari : 67,
et même le très jeune Chrome de chez Glouglou t'en retourne 58.
Mais chez Microstuff, on est muet :-(
<SCRIPT>
var type, txt = "", tot = 0;
for (var o in document)
{
try
{
type = typeof(document[o])
}
catch(e){type=""}
if (type == "function")
{
txt += o +" : " + type + "<BR>";
tot++;
}
}
if (tot) document.write(txt + "total = " + tot)
else document.write("Peau de zébi")
</SCRIPT>
avec Morzilla tu trouves 72 fonctions, avec Opera : 61, avec Safari : 67, et même le très jeune Chrome de chez Glouglou t'en retourne 58. Mais chez Microstuff, on est muet :-(
<SCRIPT> var type, txt = "", tot = 0; for (var o in document) { try { type = typeof(document[o]) } catch(e){type=""} if (type == "function") { txt += o +" : " + type + "<BR>"; tot++; } } if (tot) document.write(txt + "total = " + tot) else document.write("Peau de zébi") </SCRIPT>
Méta-MCI \(MVP\)
Re !
Les fonctions que tu cites sont des fonctions (du noyau) de Javascript. AMHA, elles n'on rien à faire avec l'objet window, et ne font pas partie du DOM (même si certaines servent à utiliser le DOM).
D'ailleurs, dans les navigateurs que tu cites, la plupart n'acceptent qu'un seul langage de script (Javascript). Alors que IE en accepte une bonne dizaine, dont plusieurs qui ne sont pas d'origine/gérés pas Microsoft. Difficile de mettre les centaines (milliers ?) de fonctions des différents langages.
Donc, pour moi, la réaction de IE est correcte.
@-salutations -- Michel Claveau
Re !
Les fonctions que tu cites sont des fonctions (du noyau) de Javascript.
AMHA, elles n'on rien à faire avec l'objet window, et ne font pas partie
du DOM (même si certaines servent à utiliser le DOM).
D'ailleurs, dans les navigateurs que tu cites, la plupart n'acceptent
qu'un seul langage de script (Javascript). Alors que IE en accepte une
bonne dizaine, dont plusieurs qui ne sont pas d'origine/gérés pas
Microsoft. Difficile de mettre les centaines (milliers ?) de fonctions
des différents langages.
Les fonctions que tu cites sont des fonctions (du noyau) de Javascript. AMHA, elles n'on rien à faire avec l'objet window, et ne font pas partie du DOM (même si certaines servent à utiliser le DOM).
D'ailleurs, dans les navigateurs que tu cites, la plupart n'acceptent qu'un seul langage de script (Javascript). Alors que IE en accepte une bonne dizaine, dont plusieurs qui ne sont pas d'origine/gérés pas Microsoft. Difficile de mettre les centaines (milliers ?) de fonctions des différents langages.
Donc, pour moi, la réaction de IE est correcte.
@-salutations -- Michel Claveau
Claude Schneegans
>>et ne font pas partie du DOM (même si certaines servent à utiliser
le DOM).
Ben voyons, document.getElementById() ça ne fait pas partie du document dans le DOM ?
>>Alors que IE en accepte une bonne dizaine, dont plusieurs qui ne sont pas d'origine/gérés pas Microsoft. Difficile de mettre les centaines (milliers ?) de fonctions des différents langages.
Je ne lui en demande pas tant, puisque mon code se trouve dans une balise <SCRIPT, il s'agit forcément de Javascript par défaut.
>>Donc, pour moi, la réaction de IE est correcte
Mouais... Pour « for ... in », la doc dit : « Executes one or more statements for each property of an object, or each element of an array » donc en toute logique, ça ne devrait pas s'exécuter pour les objets, seulement pour les propriétés. Selon moi, cette restriction est assez débile, pourquoi seulement les propriétés ? D'ailleurs tous les autres navigateurs ont décidé d'élargir la boucle à tous les éléments de l'objet, Microsoft ne l'a fait que pour les objets, mais pas les méthodes,... pas très logique, et non conforme aux specs non plus de toute façon.
>>et ne font pas partie du DOM (même si certaines servent à utiliser
le DOM).
Ben voyons, document.getElementById() ça ne fait pas partie du document
dans le DOM ?
>>Alors que IE en accepte une bonne dizaine, dont plusieurs qui ne sont
pas d'origine/gérés pas Microsoft. Difficile de mettre les centaines
(milliers ?) de fonctions des différents langages.
Je ne lui en demande pas tant, puisque mon code se trouve dans une
balise <SCRIPT, il s'agit forcément de Javascript par défaut.
>>Donc, pour moi, la réaction de IE est correcte
Mouais...
Pour « for ... in », la doc dit : « Executes one or more statements for
each property of an object, or each element of an array »
donc en toute logique, ça ne devrait pas s'exécuter pour les objets,
seulement pour les propriétés.
Selon moi, cette restriction est assez débile, pourquoi seulement les
propriétés ?
D'ailleurs tous les autres navigateurs ont décidé d'élargir la boucle à
tous les éléments de l'objet,
Microsoft ne l'a fait que pour les objets, mais pas les méthodes,... pas
très logique,
et non conforme aux specs non plus de toute façon.
>>et ne font pas partie du DOM (même si certaines servent à utiliser
le DOM).
Ben voyons, document.getElementById() ça ne fait pas partie du document dans le DOM ?
>>Alors que IE en accepte une bonne dizaine, dont plusieurs qui ne sont pas d'origine/gérés pas Microsoft. Difficile de mettre les centaines (milliers ?) de fonctions des différents langages.
Je ne lui en demande pas tant, puisque mon code se trouve dans une balise <SCRIPT, il s'agit forcément de Javascript par défaut.
>>Donc, pour moi, la réaction de IE est correcte
Mouais... Pour « for ... in », la doc dit : « Executes one or more statements for each property of an object, or each element of an array » donc en toute logique, ça ne devrait pas s'exécuter pour les objets, seulement pour les propriétés. Selon moi, cette restriction est assez débile, pourquoi seulement les propriétés ? D'ailleurs tous les autres navigateurs ont décidé d'élargir la boucle à tous les éléments de l'objet, Microsoft ne l'a fait que pour les objets, mais pas les méthodes,... pas très logique, et non conforme aux specs non plus de toute façon.
Méta-MCI \(MVP\)
Re !
document.getElementById() ça ne fait pas partie du document dans le DOM ?
Non. Le DOM décrit une hiérarchie de propriétés. getElementById() est une méthode Javascript ; une méthode de l'objet (javascript) document, qui est mappé sur l'élément document du DOM. Mais, mappé ne veut pas dire identique. Pour résoudre un appel, qu'une implémentation d'un couple javascript+navigateur utilise la délégation, et un autre l'héritage, montre bien qu'il ne faut pas généraliser à partir d'un cas particulier.
@-salutations
Michel Claveau
Re !
document.getElementById() ça ne fait pas partie du document dans le
DOM ?
Non. Le DOM décrit une hiérarchie de propriétés. getElementById() est
une méthode Javascript ; une méthode de l'objet (javascript) document,
qui est mappé sur l'élément document du DOM. Mais, mappé ne veut pas
dire identique.
Pour résoudre un appel, qu'une implémentation d'un couple
javascript+navigateur utilise la délégation, et un autre l'héritage,
montre bien qu'il ne faut pas généraliser à partir d'un cas particulier.
document.getElementById() ça ne fait pas partie du document dans le DOM ?
Non. Le DOM décrit une hiérarchie de propriétés. getElementById() est une méthode Javascript ; une méthode de l'objet (javascript) document, qui est mappé sur l'élément document du DOM. Mais, mappé ne veut pas dire identique. Pour résoudre un appel, qu'une implémentation d'un couple javascript+navigateur utilise la délégation, et un autre l'héritage, montre bien qu'il ne faut pas généraliser à partir d'un cas particulier.
@-salutations
Michel Claveau
Claude Schneegans
>>Mais, mappé ne veut pas dire identique.
Le terme « mappé » que tu utilises ici est sans doute une tentative de « traduction » de « binded » pour lerquel le terme de « lié » me semblerait plus approprié, en plus de présenter l'avantage d'être vraiment une traduction.
De plus ces méthodes pour « relier » le DOM au standard ECMAScript sont décrites avec le DOM (voir http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html ), et non avec ECMAScript.
Mais ok, laissons getElementById(), prenons la méthode addEventListener() par exemple : http://www.w3.org/TR/DOM-Level-2-Events/events.html Et que dire de nextNode(), ... Elles sont décrites en toutes lettres dans le DOM, et en font partie intégrante.
D'ailleurs, le DOM se définit lui-même comme un API : « The DOM is simply an API », et définit de plus un API : « An API is an application programming interface, a set of functions or methods used to access some functionality. » alors ne jouons pas sur les mots : le DOM comporte bien des fonctions ou méthodes...
C'est l'essence de ma question : Pourquoi l'énnncé for .. in de Microsoft ne liste pas ces fonctions alors que tous les autres le font ? Parce que d'après la doc for ... in ne liste que les propriété ? Admettons, mais toujours d'après les specs ECMA, une méthode n'est rien d'autre qu'une fonction faisant partie d'une propriété : « Properties are containers that hold other objects, primitive values, or methods. [...] and a method is a function associated with an object via a property. »
Et ailleurs : « An object is a member of the type Object. It is an unordered collection of properties each of which contains a primitive value, object, or function. A function stored in a property of an object is called a method. » Donc l'énoncé for ... in qui liste les propriétés d'un objet devrait les lister toutes, que ces propriétés contiennent une valeur, un autre objet ou une méthode.
Par contre, ECMA spécifie également qu'une propriété peut avoir l'attribut « DontEnum : The property is not to be enumerated by a for-in enumeration » Bon, alors là on tient une explication : chez Microstuff, on aurait mis le DontEnum sur toutes les méthodes du DOM, c'est ça la différence. CQFD.
C'est ça la différence, mais c'est non seulement injustifié, c'est idiot : Qu'est-ce que ça peut bien leur foutre qu'on en ait la liste des ces méthodes, puisqu'elles existent et qu'on peut les utiliser ?
>>Mais, mappé ne veut pas dire identique.
Le terme « mappé » que tu utilises ici est sans doute une tentative de «
traduction » de « binded »
pour lerquel le terme de « lié » me semblerait plus approprié, en plus
de présenter l'avantage d'être vraiment une traduction.
De plus ces méthodes pour « relier » le DOM au standard ECMAScript sont
décrites avec le DOM
(voir http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html ),
et non avec ECMAScript.
Mais ok, laissons getElementById(), prenons la méthode
addEventListener() par exemple :
http://www.w3.org/TR/DOM-Level-2-Events/events.html
Et que dire de nextNode(), ...
Elles sont décrites en toutes lettres dans le DOM, et en font partie
intégrante.
D'ailleurs, le DOM se définit lui-même comme un API : « The DOM is
simply an API »,
et définit de plus un API : « An API is an application programming
interface, a set of functions or methods used to access some
functionality. »
alors ne jouons pas sur les mots : le DOM comporte bien des fonctions ou
méthodes...
C'est l'essence de ma question :
Pourquoi l'énnncé for .. in de Microsoft ne liste pas ces fonctions
alors que tous les autres le font ?
Parce que d'après la doc for ... in ne liste que les propriété ?
Admettons, mais toujours d'après les specs ECMA, une méthode n'est rien
d'autre qu'une fonction faisant
partie d'une propriété :
« Properties are containers that hold other objects, primitive values,
or methods.
[...] and a method is a function associated with an object via a property. »
Et ailleurs :
« An object is a member of the type Object. It is an unordered
collection of properties each of which
contains a primitive value, object, or function. A function stored in a
property of an object is called a
method. »
Donc l'énoncé for ... in qui liste les propriétés d'un objet devrait les
lister toutes, que ces propriétés
contiennent une valeur, un autre objet ou une méthode.
Par contre, ECMA spécifie également qu'une propriété peut avoir l'attribut
« DontEnum : The property is not to be enumerated by a for-in enumeration »
Bon, alors là on tient une explication :
chez Microstuff, on aurait mis le DontEnum sur toutes les méthodes du
DOM, c'est ça la différence.
CQFD.
C'est ça la différence, mais c'est non seulement injustifié, c'est idiot :
Qu'est-ce que ça peut bien leur foutre qu'on en ait la liste des ces
méthodes, puisqu'elles existent
et qu'on peut les utiliser ?
Le terme « mappé » que tu utilises ici est sans doute une tentative de « traduction » de « binded » pour lerquel le terme de « lié » me semblerait plus approprié, en plus de présenter l'avantage d'être vraiment une traduction.
De plus ces méthodes pour « relier » le DOM au standard ECMAScript sont décrites avec le DOM (voir http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html ), et non avec ECMAScript.
Mais ok, laissons getElementById(), prenons la méthode addEventListener() par exemple : http://www.w3.org/TR/DOM-Level-2-Events/events.html Et que dire de nextNode(), ... Elles sont décrites en toutes lettres dans le DOM, et en font partie intégrante.
D'ailleurs, le DOM se définit lui-même comme un API : « The DOM is simply an API », et définit de plus un API : « An API is an application programming interface, a set of functions or methods used to access some functionality. » alors ne jouons pas sur les mots : le DOM comporte bien des fonctions ou méthodes...
C'est l'essence de ma question : Pourquoi l'énnncé for .. in de Microsoft ne liste pas ces fonctions alors que tous les autres le font ? Parce que d'après la doc for ... in ne liste que les propriété ? Admettons, mais toujours d'après les specs ECMA, une méthode n'est rien d'autre qu'une fonction faisant partie d'une propriété : « Properties are containers that hold other objects, primitive values, or methods. [...] and a method is a function associated with an object via a property. »
Et ailleurs : « An object is a member of the type Object. It is an unordered collection of properties each of which contains a primitive value, object, or function. A function stored in a property of an object is called a method. » Donc l'énoncé for ... in qui liste les propriétés d'un objet devrait les lister toutes, que ces propriétés contiennent une valeur, un autre objet ou une méthode.
Par contre, ECMA spécifie également qu'une propriété peut avoir l'attribut « DontEnum : The property is not to be enumerated by a for-in enumeration » Bon, alors là on tient une explication : chez Microstuff, on aurait mis le DontEnum sur toutes les méthodes du DOM, c'est ça la différence. CQFD.
C'est ça la différence, mais c'est non seulement injustifié, c'est idiot : Qu'est-ce que ça peut bien leur foutre qu'on en ait la liste des ces méthodes, puisqu'elles existent et qu'on peut les utiliser ?
Méta-MCI \(MVP\)
Re !
Ne pas oublier que la norme ECMAscript est sortie AVANT les spécifications du DOM niveau-2 du W3C. ECMAscript ne pouvant pas s'appuyer sur ces spécifications, et le DOM niveau 0 (le précédent du W3C) étant complètement dépassé, il ne restait, à l'époque que le "DOM-IE4", qui était devenu un standard de fait.
Ce qui est dommage, c'est que le W3C ait pondu un truc incompatible avec l'existant.
@-salutations -- Michel Claveau
Re !
Ne pas oublier que la norme ECMAscript est sortie AVANT les
spécifications du DOM niveau-2 du W3C.
ECMAscript ne pouvant pas s'appuyer sur ces spécifications, et le DOM
niveau 0 (le précédent du W3C) étant complètement dépassé, il ne
restait, à l'époque que le "DOM-IE4", qui était devenu un standard de
fait.
Ce qui est dommage, c'est que le W3C ait pondu un truc incompatible avec
l'existant.
Ne pas oublier que la norme ECMAscript est sortie AVANT les spécifications du DOM niveau-2 du W3C. ECMAscript ne pouvant pas s'appuyer sur ces spécifications, et le DOM niveau 0 (le précédent du W3C) étant complètement dépassé, il ne restait, à l'époque que le "DOM-IE4", qui était devenu un standard de fait.
Ce qui est dommage, c'est que le W3C ait pondu un truc incompatible avec l'existant.
@-salutations -- Michel Claveau
Claude Schneegans
>>Ne pas oublier que la norme ECMAscript est sortie AVANT les
spécifications du DOM niveau-2 du W3C. ECMAscript ne pouvant pas s'appuyer sur ces spécifications.
Peut-être, mais je ne vois pas le rapport, et raison de plus : ECMAscript n'a pas à s'occuper du DOM qui est une implantation dans ECMAscript, ou tout autre langage compatible. Quand le DOM a été défini, il est venu avec tous ses objets, ses propriétés et ses méthodes permettant de les gérer, c'est normal et ce n'est pas à ECMAscript de s'en soucier.
>>Ne pas oublier que la norme ECMAscript est sortie AVANT les
spécifications du DOM niveau-2 du W3C.
ECMAscript ne pouvant pas s'appuyer sur ces spécifications.
Peut-être, mais je ne vois pas le rapport, et raison de plus :
ECMAscript n'a pas à s'occuper du DOM qui est une implantation dans
ECMAscript,
ou tout autre langage compatible.
Quand le DOM a été défini, il est venu avec tous ses objets, ses
propriétés et ses méthodes
permettant de les gérer, c'est normal et ce n'est pas à ECMAscript de
s'en soucier.
>>Ne pas oublier que la norme ECMAscript est sortie AVANT les
spécifications du DOM niveau-2 du W3C. ECMAscript ne pouvant pas s'appuyer sur ces spécifications.
Peut-être, mais je ne vois pas le rapport, et raison de plus : ECMAscript n'a pas à s'occuper du DOM qui est une implantation dans ECMAscript, ou tout autre langage compatible. Quand le DOM a été défini, il est venu avec tous ses objets, ses propriétés et ses méthodes permettant de les gérer, c'est normal et ce n'est pas à ECMAscript de s'en soucier.