Clonage d'un élément avec la méthode clone()

Citation:

---

Envoyé par popo

Je vais également inviter psychadelic à essayer le C# pour qu'il se rende compte du gouffre séparant JavaScript et C# dans l'utilisation et la gestion des pointeurs.

---

T'es gentil, mais je ne t'ai pas attendu pour savoir programmer en C#.
Je ne vais pas te faire la liste de mes connaissances sur plus d'une trentaine de langages, de librairies, objets ou non, de frameworks, etc..,
et bien sur tous dans un cadre professionnel et sur plusieurs années parce que j'ai commencé à coder bien avant l'arrivée de la micro-informatique.

Perso, j'ai toujours aimé découvrir de nouveaux langages, et je ne me suis jamais offusqué comme tu le fais sur pour un bête problème de syntaxe qui ne colle pas avec ta façon de penser.

PS: la gestions des pointeurs en C#, c'est de la rigolade à coté des doubles pointeurs qu'on devait gérer sous le Finder d'Apple :ptdr:

« La connaissance n'est rien à côté de l'ignorance !  »

Amener à chercher l'explication au travers de traduction à grand coup de dictionnaires est à mon sens limite une hérésie.

Essayons de lever la confusion qui est faite au travers de cette discussion.

Le Javascript et le DOM sont deux choses différentes qui sont en relation.

Le JavaScript est un langage de scripting du Web, connu sous le nom de ECMAScript, et permet une interaction avec la page HTML.

Le DOM (Document Object Model) est un ensemble d'interfaces indépendant de tout langage.

Il fournit les méthodes et les propriétés nécessaires à la lecture/modification etc des éléments du document grâce à son interface Document.

L'IDL DOM est implémenté dans des langages tel que PHP, Python, PERL, C/C++, C# et d'autres encore, alors arrêtez de « casser » JavaScript pour ce dont il n'est pas responsable.

• Document Object Model (Core) Level 1
• PHP -> DOMNode::appendChild
• Python -> The Document Object Model API
• Perl -> HTML::DOM

Ceci étant merci d'arrêter de délirer et recentrez, si il en est encore besoin, vos discours et surtout ne mélangez pas tout !

Pensée très personnelle :
Il ne me dérange/choque pas lorsque j'ajoute un oeuf à mon panier que celui-ci disparaisse de l'étal du volailler.

Il est clair qu'il faut remettre les choses dans leur contexte et revenir sur le bout de documentation qui a déclenché la polémique.
C'était une doc en allemand mais la voici traduite :

Citation:

---

La raison en est la façon dont JavaScript transmet les paramètres. Lorsque vous travaillez avec un objet, JavaScript passe une référence à l'objet, pas une copie de l'objet. Cela signifierait l'ajout d'un pointeur sur le clone créé précédemment, pas une nouvelle copie. Le résultat final est que si nous n'appelions pas clone () une seconde fois, nous essayerions de replacer exactement le même objet dans le conteneur, pas une toute nouvelle copie. En appelant à nouveau clone (), nous enverrons une copie de notre formulaire utilisateur, pas un pointeur sur celui que nous avons déjà utilisé.

---

Il est donc question de JavaScript et de pointeurs et par conséquent d'adresses mémoire.
Et l'unique référence au DOM est le conteneur qui une NodeList (et donc une liste ou une collection).

Puisque apparemment tu est familier d'une trentaine de langages dont C#, tu admettras qu'en ajoutant deux fois la même référence à un objet sur une collection ou une liste, on obtient une liste ou une collection avec deux enregistrements et non pas un seul qui s'est déplacé et que toute modification sur cet objet sera visible sur les deux enregistrements.
Il s'agit donc d'une particularité imposée par le contrat des interfaces DOM et les langages s'adaptent à cette particularité pour respecter le contrat.

Donc OK, cela n'a rien à voir avec JavaScript, cela à avoir avec le DOM.

Mais la plus grosse polémique portait sur le nom de la méthode.
Puisque l'objectif est d'ajouter à la fin mais que pour cela je dois d'abord supprimer cet élément s'il existe ailleurs, alors oui append est un nom ambigu car ça ne fait pas uniquement ce qu'indique ce nom.

Et il ne s'agit pas de syntaxe, mais bien de vocabulaire.
Append = ajouter à la fin <> ajouter à la fin en déplaçant si déjà existant


Pour résumer, c'est une particularité du DOM qui n'a rien à voir avec JavaScript et le nom est ambigu car il n'indique pas ce que ça fait exactement.

Citation:

---

Pensée très personnelle :
Il ne me dérange/choque pas lorsque j'ajoute un oeuf à mon panier que celui-ci disparaisse de l'étal du volailler.

---

D'un autre coté si j'applique deux fois le même tampon sur un document, j'aurai deux coups de tampons...

Le problème ici c’est que le DOM est quelque chose d’abstrait. Ce n’est pas une structure en mémoire bien ordonnée comme une liste chaînée ou une pile. Les relations entre les nœuds ne sont pas des références ni des pointeurs, mais des liens contenant-contenu ou parent-enfant. Par exemple, un nœud aussi courant que le <body> a une bonne dizaine de relations :

• parentElement, le <html> ;
• firstChild, qui est souvent un nœud texte ne contenant que des espaces blancs, et firstElementChild qui ne renvoie que les nœuds de type^(*) Element ;
• lastChild et lastElementChild ;
• previousSibling, previousElementSibling, nextSibling et nextElementSibling ;
• les collections childNodes et children ;
• et j’en oublie certainement.

On parle souvent d’arbre DOM mais en fait, selon le genre de relation qu’on considère, ça peut très bien être un graphe avec des arcs qui vont dans tous les sens.

Ces relations ne sont pas des références. En revanche, les objets JavaScript qui représentent les nœuds DOM (par exemple document.body, de type HTMLBodyElement) ont des références les uns vers les autres.

J’insiste sur « représentent » : il y a d’un côté le DOM, qui est abstrait, et de l’autre côté les objets JavaScript, qui vivent dans la mémoire du navigateur.

Il faut garder à l’esprit que JavaScript ne permet pas les manipulations de mémoire, et que la gestion des références est laissée à la discrétion du moteur. Par exemple, si on regarde la propriété firstChild des nœuds :

Code:

---

1 2	Object.getOwnPropertyDescriptor(Node.prototype, "firstChild") // Object { get: get firstChild(), set: undefined, enumerable: true, configurable: true }

---

On voit bien que la propriété est un getter. Ainsi, on ne sait pas quelles manipulations fait le moteur avant de nous renvoyer la référence qu’on demande.

Comme l’a fait remarquer NoSmoking, c’est la spécification du DOM qui exige que append soit un déplacement et non une copie. Et la spécification porte sur le DOM abstrait, pas sur les implémentations.

Je ne sais pas exactement comment les navigateurs gèrent leurs représentations du DOM en interne, mais ça ne peut pas avoir une structure trop rigide car les relations entre les nœuds changent souvent. J’imagine que ça a la forme d’un tas désordonné. Supposons qu’il existe une méthode qui clone un nœud et l’ajoute à un endroit donné, appelons-la appendClone, cette méthode ferait deux opérations :

1. Une copie abstraite du nœud : création d’un nouveau nœud de même nature, avec les mêmes attributs, mais pas exactement les mêmes propriétés. En particulier ses relations avec les autres nœuds, car à ce moment il n’est pas encore inséré dans le DOM, il existe seulement dans le contexte JavaScript.

2. Une mise à jour des relations entre les nœuds, au moment où le clone est inséré : les propriétés du clone, mais aussi celles de ses parents, voisins, etc. Bref, tous les nœuds qui sont affectés par l’insertion.

On voit que c’est quand même une opération non triviale, assez différente d’une copie d’objets en mémoire. Je pense que c’est pour cette raison que append ne fait pas de clonage automatiquement.

(*) Quand je dis « type » je ne veux pas relancer le débat sur JS est-il un langage typé ou pas, c’est juste un abus de langage pour aller plus vite. « Bidule est de type X » veut dire en fait « Bidule implémente l’interface X. »

Citation:

---

Envoyé par Watilin

Je ne sais pas exactement comment les navigateurs gèrent leurs représentations du DOM en interne, ...

---

Il n’y a pas 36 manières de coder ça.

Imagine un <DIV> avec 5 paragraphes <P> de texte-simple.
En mémoire tu retrouves donc tes 5 texte-simple(s) ayant chacun une allocation mémoire, et 5 objets <P> ayant chacun un pointeur vers chacun de ces textes,
en plus les éléments propres aux éléments <P> (propriétés, méthodes…)

l’élément <DIV> est lui même un objet contenant en plus une liste ordonnée des pointeurs dédiés vers chacun des 5 objets <P>

Ensuite tu peux bâtir toute ta page web avec tous les éléments HTML possibles, avoir plusieurs DIV, des tableaux, des formulaires etc. et le tout dans un <BODY>.

L’opération d’un Append d’un élément <P> <DIV> dans un autre <DIV> (ou autres), c’est juste copier la valeur d’un pointeur d’une liste (et l’effacer) pour l’ajouter a la fin d’une autre liste.

l’objet « déplacé » reste à la même place mémoire, il est juste référencé par un autre parent.

Le gros du boulot c’est pour la réorganisation de l’affichage.

Cela peut en intéresser certains : Dans les coulisses des navigateurs Web modernes traduction sur DVP de l'article How Browsers Work: Behind the scenes of modern web browsers.

Waw, cet article est très complet. Je le mets dans mes marque-page, il mérite d’être lu et relu.
Merci pour ce partage !