Je me demande pourquoi pourquoi NodeList n'est pas une Array ?
c'est tellement plus facile en Array que j'ai implémenté une méthode
#toArray() sur NodeList :
NodeList.prototype.toArray=function(){
var a=[];
for(var i=0, l=this.length;i<l;i++){
a.push(this[i]);
}
return a;
}
--
« L'humanité qui devrait avoir six mille ans d'expérience,
retombe en enfance à chaque génération. »
(Tristan Bernard)
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
Mickaël Wolff
On 19/10/11 04:07, Une Bévue wrote:
Je me demande pourquoi pourquoi NodeList n'est pas une Array ?
Array est un type Ecmascript/Javascript. NodeList est un type générique défini par DOM. DOM a été pensé pour ne pas dépendre du langage dans lequel il est implémenté.
c'est tellement plus facile en Array que j'ai implémenté une méthode #toArray() sur NodeList : NodeList.prototype.toArray=function(){ var a=[]; for(var i=0, l=this.length;i<l;i++){ a.push(this[i]); } return a; }
En quoi est-ce plus facile ?
On 19/10/11 04:07, Une Bévue wrote:
Je me demande pourquoi pourquoi NodeList n'est pas une Array ?
Array est un type Ecmascript/Javascript. NodeList est un type
générique défini par DOM. DOM a été pensé pour ne pas dépendre du
langage dans lequel il est implémenté.
c'est tellement plus facile en Array que j'ai implémenté une méthode
#toArray() sur NodeList :
NodeList.prototype.toArray=function(){
var a=[];
for(var i=0, l=this.length;i<l;i++){
a.push(this[i]);
}
return a;
}
Je me demande pourquoi pourquoi NodeList n'est pas une Array ?
Array est un type Ecmascript/Javascript. NodeList est un type générique défini par DOM. DOM a été pensé pour ne pas dépendre du langage dans lequel il est implémenté.
c'est tellement plus facile en Array que j'ai implémenté une méthode #toArray() sur NodeList : NodeList.prototype.toArray=function(){ var a=[]; for(var i=0, l=this.length;i<l;i++){ a.push(this[i]); } return a; }
En quoi est-ce plus facile ?
unbewusst.sein
Mickaël Wolff wrote:
On 19/10/11 04:07, Une Bévue wrote: > Je me demande pourquoi pourquoi NodeList n'est pas une Array ?
Array est un type Ecmascript/Javascript. NodeList est un type générique défini par DOM. DOM a été pensé pour ne pas dépendre du langage dans lequel il est implémenté.
Ben c'est "pensé" de travers alors... De toutes façons le DOM dans un browser n'est accessible que par js non ? Aujourd'hui, il n'y a pas d'autres langages pour butineur ?
Je mets à part les tentatives CoffeeScript et Dart qui de toutes façons "compilent" en js.
> c'est tellement plus facile en Array que j'ai implémenté une méthode
<snip />
En quoi est-ce plus facile ?
ben je peut utiliser Array#concat(Array) par exemple, pour regrouper des éléments.
-- « Si tous ceux qui n'ont rien n'en demandaient pas plus, il serait bien facile de contenter tout le monde. » (Coluche)
Mickaël Wolff <mickael.wolff@laposte.net> wrote:
On 19/10/11 04:07, Une Bévue wrote:
> Je me demande pourquoi pourquoi NodeList n'est pas une Array ?
Array est un type Ecmascript/Javascript. NodeList est un type
générique défini par DOM. DOM a été pensé pour ne pas dépendre du
langage dans lequel il est implémenté.
Ben c'est "pensé" de travers alors...
De toutes façons le DOM dans un browser n'est accessible que par js non
?
Aujourd'hui, il n'y a pas d'autres langages pour butineur ?
Je mets à part les tentatives CoffeeScript et Dart qui de toutes façons
"compilent" en js.
> c'est tellement plus facile en Array que j'ai implémenté une méthode
<snip />
En quoi est-ce plus facile ?
ben je peut utiliser Array#concat(Array) par exemple, pour regrouper des
éléments.
--
« Si tous ceux qui n'ont rien n'en demandaient pas plus,
il serait bien facile de contenter tout le monde. »
(Coluche)
On 19/10/11 04:07, Une Bévue wrote: > Je me demande pourquoi pourquoi NodeList n'est pas une Array ?
Array est un type Ecmascript/Javascript. NodeList est un type générique défini par DOM. DOM a été pensé pour ne pas dépendre du langage dans lequel il est implémenté.
Ben c'est "pensé" de travers alors... De toutes façons le DOM dans un browser n'est accessible que par js non ? Aujourd'hui, il n'y a pas d'autres langages pour butineur ?
Je mets à part les tentatives CoffeeScript et Dart qui de toutes façons "compilent" en js.
> c'est tellement plus facile en Array que j'ai implémenté une méthode
<snip />
En quoi est-ce plus facile ?
ben je peut utiliser Array#concat(Array) par exemple, pour regrouper des éléments.
-- « Si tous ceux qui n'ont rien n'en demandaient pas plus, il serait bien facile de contenter tout le monde. » (Coluche)
Mickaël Wolff
On 20/10/11 07:16, Une Bévue wrote:
Ben c'est "pensé" de travers alors...
Ben non, c'est pensé de manière orthogonale :D
De toutes façons le DOM dans un browser n'est accessible que par js non ?
Non, depuis ActiveScript, depuis ActiveX, etc.
Aujourd'hui, il n'y a pas d'autres langages pour butineur ?
DOM est une spécification indépendante du langage et de l'environnement d'exécution. DOM ne sert pas que dans un navigateur. La libxml du projet GNOME implémente une version écrite en C de DOM. PHP fournit aussi une implémentation de DOM, et Python, etc.
Je sais que trop souvent, on considère /a priori/, JavaScript et DOM comme des technologies uniquement disponibles dans un navigateur Web. En réalité, ce sont des technologies qui n'y sont pas spécifiques.
ben je peut utiliser Array#concat(Array) par exemple, pour regrouper des éléments.
Ceci peut poser problème. Un NodeList n'est pas un tableau, mais une liste chainée. Chaque élément connait ses voisins, son parent et ses enfants. C'est cette structure qui est considérée dans DOM, c'est à cette structure que l'API DOM donne accès. C'est pour ça que les opérations d'insertion, de suppression ou de remplacement ne sont pas triviale : on manipule un arbre DOM.
// Le parent est nécessaire pour supprimer un nœud nodeToBeRemoved.parent.removeChild(nodeToBeRemoved);
// Pour remplacer un nœud, il faut connaître le parent // et surtout, le nœud à insérer doit être connu du document // propriétaire dans lequel il est inséré nodeToBeReplaced.parent .replaceChild(replacementNode, nodeToBeReplaced);
J'espère que tu comprends mieux le pourquoi des choix de conception de DOM. Ce n'est pas parce qu'ils ne correspondent pas à ton besoin immédiat qu'ils sont abérants ;)
On 20/10/11 07:16, Une Bévue wrote:
Ben c'est "pensé" de travers alors...
Ben non, c'est pensé de manière orthogonale :D
De toutes façons le DOM dans un browser n'est accessible que par js non
?
Non, depuis ActiveScript, depuis ActiveX, etc.
Aujourd'hui, il n'y a pas d'autres langages pour butineur ?
DOM est une spécification indépendante du langage et de
l'environnement d'exécution. DOM ne sert pas que dans un navigateur. La
libxml du projet GNOME implémente une version écrite en C de DOM. PHP
fournit aussi une implémentation de DOM, et Python, etc.
Je sais que trop souvent, on considère /a priori/, JavaScript et DOM
comme des technologies uniquement disponibles dans un navigateur Web. En
réalité, ce sont des technologies qui n'y sont pas spécifiques.
ben je peut utiliser Array#concat(Array) par exemple, pour regrouper des
éléments.
Ceci peut poser problème. Un NodeList n'est pas un tableau, mais une
liste chainée. Chaque élément connait ses voisins, son parent et ses
enfants. C'est cette structure qui est considérée dans DOM, c'est à
cette structure que l'API DOM donne accès. C'est pour ça que les
opérations d'insertion, de suppression ou de remplacement ne sont pas
triviale : on manipule un arbre DOM.
// Le parent est nécessaire pour supprimer un nœud
nodeToBeRemoved.parent.removeChild(nodeToBeRemoved);
// Pour remplacer un nœud, il faut connaître le parent
// et surtout, le nœud à insérer doit être connu du document
// propriétaire dans lequel il est inséré
nodeToBeReplaced.parent
.replaceChild(replacementNode, nodeToBeReplaced);
J'espère que tu comprends mieux le pourquoi des choix de conception
de DOM. Ce n'est pas parce qu'ils ne correspondent pas à ton besoin
immédiat qu'ils sont abérants ;)
De toutes façons le DOM dans un browser n'est accessible que par js non ?
Non, depuis ActiveScript, depuis ActiveX, etc.
Aujourd'hui, il n'y a pas d'autres langages pour butineur ?
DOM est une spécification indépendante du langage et de l'environnement d'exécution. DOM ne sert pas que dans un navigateur. La libxml du projet GNOME implémente une version écrite en C de DOM. PHP fournit aussi une implémentation de DOM, et Python, etc.
Je sais que trop souvent, on considère /a priori/, JavaScript et DOM comme des technologies uniquement disponibles dans un navigateur Web. En réalité, ce sont des technologies qui n'y sont pas spécifiques.
ben je peut utiliser Array#concat(Array) par exemple, pour regrouper des éléments.
Ceci peut poser problème. Un NodeList n'est pas un tableau, mais une liste chainée. Chaque élément connait ses voisins, son parent et ses enfants. C'est cette structure qui est considérée dans DOM, c'est à cette structure que l'API DOM donne accès. C'est pour ça que les opérations d'insertion, de suppression ou de remplacement ne sont pas triviale : on manipule un arbre DOM.
// Le parent est nécessaire pour supprimer un nœud nodeToBeRemoved.parent.removeChild(nodeToBeRemoved);
// Pour remplacer un nœud, il faut connaître le parent // et surtout, le nœud à insérer doit être connu du document // propriétaire dans lequel il est inséré nodeToBeReplaced.parent .replaceChild(replacementNode, nodeToBeReplaced);
J'espère que tu comprends mieux le pourquoi des choix de conception de DOM. Ce n'est pas parce qu'ils ne correspondent pas à ton besoin immédiat qu'ils sont abérants ;)
Une Bévue
Le 22/10/2011 04:40, Mickaël Wolff a écrit :
On 20/10/11 07:16, Une Bévue wrote:
Ben c'est "pensé" de travers alors...
Ben non, c'est pensé de manière orthogonale :D
De toutes façons le DOM dans un browser n'est accessible que par js non ?
Non, depuis ActiveScript, depuis ActiveX, etc.
Aujourd'hui, il n'y a pas d'autres langages pour butineur ?
DOM est une spécification indépendante du langage et de l'environnement d'exécution. DOM ne sert pas que dans un navigateur. La libxml du projet GNOME implémente une version écrite en C de DOM. PHP fournit aussi une implémentation de DOM, et Python, etc.
Je sais que trop souvent, on considère /a priori/, JavaScript et DOM comme des technologies uniquement disponibles dans un navigateur Web. En réalité, ce sont des technologies qui n'y sont pas spécifiques.
ben je peut utiliser Array#concat(Array) par exemple, pour regrouper des éléments.
Ceci peut poser problème. Un NodeList n'est pas un tableau, mais une liste chainée. Chaque élément connait ses voisins, son parent et ses enfants. C'est cette structure qui est considérée dans DOM, c'est à cette structure que l'API DOM donne accès. C'est pour ça que les opérations d'insertion, de suppression ou de remplacement ne sont pas triviale : on manipule un arbre DOM.
// Le parent est nécessaire pour supprimer un nœud nodeToBeRemoved.parent.removeChild(nodeToBeRemoved);
// Pour remplacer un nœud, il faut connaître le parent // et surtout, le nœud à insérer doit être connu du document // propriétaire dans lequel il est inséré nodeToBeReplaced.parent .replaceChild(replacementNode, nodeToBeReplaced);
J'espère que tu comprends mieux le pourquoi des choix de conception de DOM. Ce n'est pas parce qu'ils ne correspondent pas à ton besoin immédiat qu'ils sont abérants ;)
ouais, OK, c'est retenu !
Le 22/10/2011 04:40, Mickaël Wolff a écrit :
On 20/10/11 07:16, Une Bévue wrote:
Ben c'est "pensé" de travers alors...
Ben non, c'est pensé de manière orthogonale :D
De toutes façons le DOM dans un browser n'est accessible que par js non
?
Non, depuis ActiveScript, depuis ActiveX, etc.
Aujourd'hui, il n'y a pas d'autres langages pour butineur ?
DOM est une spécification indépendante du langage et de l'environnement
d'exécution. DOM ne sert pas que dans un navigateur. La libxml du projet
GNOME implémente une version écrite en C de DOM. PHP fournit aussi une
implémentation de DOM, et Python, etc.
Je sais que trop souvent, on considère /a priori/, JavaScript et DOM
comme des technologies uniquement disponibles dans un navigateur Web. En
réalité, ce sont des technologies qui n'y sont pas spécifiques.
ben je peut utiliser Array#concat(Array) par exemple, pour regrouper des
éléments.
Ceci peut poser problème. Un NodeList n'est pas un tableau, mais une
liste chainée. Chaque élément connait ses voisins, son parent et ses
enfants. C'est cette structure qui est considérée dans DOM, c'est à
cette structure que l'API DOM donne accès. C'est pour ça que les
opérations d'insertion, de suppression ou de remplacement ne sont pas
triviale : on manipule un arbre DOM.
// Le parent est nécessaire pour supprimer un nœud
nodeToBeRemoved.parent.removeChild(nodeToBeRemoved);
// Pour remplacer un nœud, il faut connaître le parent
// et surtout, le nœud à insérer doit être connu du document
// propriétaire dans lequel il est inséré
nodeToBeReplaced.parent
.replaceChild(replacementNode, nodeToBeReplaced);
J'espère que tu comprends mieux le pourquoi des choix de conception de
DOM. Ce n'est pas parce qu'ils ne correspondent pas à ton besoin
immédiat qu'ils sont abérants ;)
De toutes façons le DOM dans un browser n'est accessible que par js non ?
Non, depuis ActiveScript, depuis ActiveX, etc.
Aujourd'hui, il n'y a pas d'autres langages pour butineur ?
DOM est une spécification indépendante du langage et de l'environnement d'exécution. DOM ne sert pas que dans un navigateur. La libxml du projet GNOME implémente une version écrite en C de DOM. PHP fournit aussi une implémentation de DOM, et Python, etc.
Je sais que trop souvent, on considère /a priori/, JavaScript et DOM comme des technologies uniquement disponibles dans un navigateur Web. En réalité, ce sont des technologies qui n'y sont pas spécifiques.
ben je peut utiliser Array#concat(Array) par exemple, pour regrouper des éléments.
Ceci peut poser problème. Un NodeList n'est pas un tableau, mais une liste chainée. Chaque élément connait ses voisins, son parent et ses enfants. C'est cette structure qui est considérée dans DOM, c'est à cette structure que l'API DOM donne accès. C'est pour ça que les opérations d'insertion, de suppression ou de remplacement ne sont pas triviale : on manipule un arbre DOM.
// Le parent est nécessaire pour supprimer un nœud nodeToBeRemoved.parent.removeChild(nodeToBeRemoved);
// Pour remplacer un nœud, il faut connaître le parent // et surtout, le nœud à insérer doit être connu du document // propriétaire dans lequel il est inséré nodeToBeReplaced.parent .replaceChild(replacementNode, nodeToBeReplaced);
J'espère que tu comprends mieux le pourquoi des choix de conception de DOM. Ce n'est pas parce qu'ils ne correspondent pas à ton besoin immédiat qu'ils sont abérants ;)
