Version imprimable
bonjour,
developpez.net/forums/d1948570/javascript/general-javascript/utilisation-innerhtml/#post10801124
dans ce post : Watilin fait reference aux elements du DOM
bien que les "selecteurs" soient les memes, les references non
=> exist-il un moyen de recuperer ces references (uniques) en JS ?
heu, je vois pas trop, pour moi Watilin parle de "référence" dans un sens imagé, et ne s'est pas aventuré à décortiquer le mécanisme du software interne des différents moteurs d'interprétation HTML et JS
le navigateur semble faire la difference en un element issue d'un selecteur (exemple document.getElementById()) et l'element du dom a proprement parler qu'il manipuleCitation:
Envoyé par Watilin
ca va etre grossier, mais voici ce que j'essaye de dire :
pour le navigateur : le span1 aura un genre d'id interne A, le span2 B et le span3 CCode:
2
3
si maintenant on applique :le resultat sera sensiblement le meme (j'ai juste mis "new span 2" en textContent qu'on voit bien que le span change)Code:
2
3
4
5
6
7
ce que dis Watilin, c'est que de faire ca, change la reference de l'element (bien que le selecteur de notre cote soit le meme)
pour le navigateur : span2 aura un id interne D (et non B comme avant)
ça reste des élucubrations, et perso, je doute qu'il existe une table d'allocation mémoire pour chaque élément, mais plutôt une pile, plus pratique pour la gestion de bac à sable avec le passage d'un onglet à un autre, et qui devient une gestion de mémoire dynamique ou on oublie les adresse fixes qui prévalaient aux premiers temps de l'informatique.
De toutes façons c'est la cuisine interne de chaque marque de navigateur, ce qui pourrait marcher sur un Firefox à peu de chance de fonctionner sur chrome ou Edge, ou IE, ou Konqueror...
si c'est pas possible, tant pis ^^
merci de me l'avoir confirme :)
Bonjour,
je dois admettre que je n'ai absolument rien compris aux propos tenus :aie:
Ce qui est dit par Watilin, si je ne m'abuse, c'est que tu « perds » l'objet initialement contenu qui est remplacé par un nouvel élément recrée lors de l'utilisation de innerHTML.
Ceci étant ton élément substitué existe toujours comme tu as une référence à celui-ci, dans ton cas var span2, tu donc peux encore l'utiliser.
Fait simplement ce test sur base de cette structure
exécute ce scriptCode:
2
3
4
5
Code:
2
3
4
5
6
7
8
9
10
11
12
Nota: je déplace vers JavaScript ce qui semble plus indiqué.
ok, donc quand on passe par les methodes prevues pour (append/remove/etc) l'object est toujours la
tandis que le innerHTML, lui, supprime tout... c'etait cette subtilitee que je n'avais pas saisie (j'utilise quasiment pas le innerHTML)
merci pour cet eclairsissement (et le deplacement dans le bon forum^^)
Tu peux composer suivant ce que tu fais, par exemple un transfert de données
bien sûr cela peut se faire en une seule opération mais c'est juste pour montrer que tous les éléments seront dans ce cas référencés et donc réutilisable.Code:
2
3
4
5
6
7
8
9
10
Même exemple en ne recopiant que des noeuds de type Node.ELEMENT_NODECode:
2
3
4
5
6
Si on veut trois span comme au début il faudrait remplacer span3.insertBefore(newSpan2, span3.firstChild); (avec cette instruction la span "newSpan2" sera à l'intérieur de span#span3) par span3.parentNode.insertBefore(newSpan2, span3); (avec cette instruction la span "newSpan2" sera placée après span#span1 et avant de span#span3 ce qui correspond à la structure de départ).Citation:
Envoyé par Doksuri
Mais même dans ce cas il me semble que la span "newSpan2" et span#span2 n'ont rien à voir l'un avec l'autre...
------
Par contre il y a une chose qui rejoint le sujet du fil Les fuites de mémoire...
EDIT : j'ai déplacé ce passage dans le fil indiqué ici : #4
Apparemment non, dans les deux cas on a le même problème, j'ai testé ce code pour voir :Citation:
Envoyé par Doksuri
Code:
2
3
4
5
6
7
8
9
Eh bien la span#span2 est bel est bien affichée dans la console malgré l'instruction : document.body.innerHTML = "";...
Je crois que c'est pareil avec le bouton dans l'exemple de Watilin, il faudrait que je vérifie si le gestionnaire associé existe toujours...
EDIT : J'ai fait le test ici : #16 le bouton et son gestionnaire ne sont pas complètement supprimés (ils sont juste retirés du DOM mais conservés en mémoire apparemment)...
Bon, à la base la question de Doksuri portait sur un moyen pour établir une liste référençant tous les « éléments du DOM ».
Pour poser sa question il part de la phrase de Watilin :Et il livre l’exemple suivant pour étayer son propos (j’ai juste regroupé son code) :Citation:
Ce n’est plus le même élément DOM, et les références sont brisées, en particulier les gestionnaires d’évènements qui y étaient attachés. Dans mon exemple, le gestionnaire de "click" ne fonctionnera plus.
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Si vous testez ce code, vous verrez bien que le "click" sur le bouton ne produira rien.
Et pour en revenir avec les posts qui ont suivi ici, j’ai fait un autre exemple, donnant le même effet :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
ici aussi le bouton restera muet, même s’il existe toujours dans le DOM ( et reste aussi présent sur l’affichage ).
Et la fonction rattachée au clic sur l’élément n’a pas disparu non plus ( fct_Msg_Click(); ).
et le click sur le bouton ne produira toujours rien.
1) Watilin parle de référence brisée entre l’objet <button> et l’attribution du "click" qui lui est faite,
2) Doksuri fait une confusion sur le terme référence tel que l’a employé Watilin , avec quelque chose qui serait une sorte de table d’allocation sur les éléments dans le genre :
[ Ref-1 ] <=> <div id="exemple">
[ Ref-2 ] <=> <button> ( 1er de l’élément [ Ref-1 ]
qui doit exister sous une forme ou une autre à dans le code source des navigateurs, mais qui n’est absolument pas accessible en JavaScript.
tu lis dans mes pensees (et t'as reussi a mieux l'exprimer :aie: )Citation:
Envoyé par psychadelic
et du coup, tu as aussi repondu a la question
:ccool:
Justement comme déjà dit j'ai fait un test ici : #16 le bouton et son gestionnaire ne sont pas complètement supprimés (ils sont juste retirés du DOM mais conservés en mémoire apparemment)...Citation:
Envoyé par psychadelic
Ce que je veux dire c'est que je pense qu'en fait le lien entre le bouton et le gestionnaire onclick existe toujours, il n'est pas brisé même si comme tu l'as dit "vous verrez bien que le "click" sur le bouton ne produira rien" car je pense que la raison de cela c'est que ce n'est pas le même bouton, ce n'est pas le bouton auquel on a associé le gestionnaire onclick, pour reprendre le nom dans ton code : ce n'est pas le bouton ayant pour id : "Click-Btn".
Ce bouton qui est affiché, c'en est un autre, c'est celui qui est "crée" lors de l'instruction : divExemple.innerHTML += "<p>Du texte en plus</p>"; et aucun gestionnaire onclick ne lui est associé il est donc normal qu'il ne se passe rien quand on clique dessus.
Par contre si (comme dans mon test) on remet dans le DOM le bouton ayant pour id : "Click-Btn" (document.body.appendChild(ClikButton);) on peut constater en cliquant dessus que son lien avec le gestionnaire onclick existe toujours...
Oui, et alors*???? :roll:
Le sujet initial reste l’intérêt de Doksuri pour obtenir de possibles références uniques sur chacun des éléments du DOM, en se basant sur une mauvaise interprétation des propos de Watilin.
Que le bouton soit en réalité «*refait*» ou non est hors sujet.
D'ailleurs Watilin à déjà expliqué ce point dans son postFaire des digression sur un sujet, pourquoi pas, mais la ça commence à faire un peu lourd, et que ça ne fait qu'ajouter à la confusion qui semble régner dans ce sujet.Citation:
Le contenu entier de la div va être recréé. L’ancien <button> est supprimé, et un nouveau est recréé à partir de sa représentation HTML textuelle
Lol, ben je pensais que c'était clair, j'ai cité ton passage :Citation:
Envoyé par psychadelic
Pour faire court : non aucune référence n'est brisée.Citation:
Watilin parle de référence brisée entre l’objet <button> et l’attribution du "click" qui lui est faite,
Pour les détails relire mon message précédent...
Bon, on va faire autrement :
Ce qu’explique Watilin c’est qu’entre le visuel du bouton dans l’interface, et l’eventListener existant, il n’y a plus de relation entre eux, et à ce titre il utilise le terme de référence brisée, que Doksuri extrapole par erreur de sa part comme étant un système de référencement interne auquel il espère accéder, car il imagine que ce système fonctionne avec des uid.
Donc pour résumer :
1) Watilin utilise le terme "référence" parce qu'il utilise le Français, et que dans cette langue ce terme relève d'une abstraction. ex: " faire référence à l'éternel "
2) Doksuri comprend de travers le mot référence en se bornant uniquement à son sens en informatique, et imagine qu'il s'agit d'un système d'adressage
3) Beginner ne regarde que le code et s'acharne à faire du hors-sujet avec ses remarques sur les fonctionnalité des interpréteurs JS, avec quelques métros de retard, puisque Watilin avait déjà expliqué tout cela dans son post auquel Doksuri faisait référence dans son sujet
.. alors que depuis le début le sujet est basé sur erreur sémantique.:roll:
Salut psychadelic, je t’apprécie tu sais et tu es marrant des fois (je ne dis pas ça méchamment)...
Je ne crois pas faire de hors-sujet et je ne répondais pas non plus à Watilin mais à toi (ce sont tes propos que j'ai cités et auxquels je répondais), je pense avoir compris ce que Watilin a expliqué mais le problème n'est pas là, son but n'était pas de rentrer dans les détails et il ne cherchait pas à traiter de ce point particulier en profondeur mais par la suite d'autres fils ont été ouverts et j'ai posté un test alors à partir de là on pouvait donner certains détails et préciser les choses et il n'y a pas de mal à cela, enfin c'est ce que je croyais du moins...
Sinon ben cela peut induire en erreur, ce n'est pas ce que tu veux, non ?
Oui parce qu'en te lisant on comprend que le bouton qui est affiché à la fin de l'exécution du script ne répond "plus" au click parce que son lien avec le gestionnaire du onclick est brisé.
Sauf que par la suite le test montre qu'en réalité si ce bouton ne répond pas ("pas" et non "plus" en réalité) au click c'est parce que c'est un autre bouton, un nouveau bouton auquel aucun gestionnaire onclick n'a été associé.
Et le premier bouton auquel un gestionnaire onclick avait été associé existe toujours en mémoire et on peut d'ailleurs l'insérer de nouveau dans le DOM et on voit alors qu'il répond bel et bien au click.
Donc quand tu répètes encore ceci :
Eh bien je te dis encore que ce n'est pas "...il n’y a plus de relation entre eux" c'est plutôt qu'il n'y en a jamais eu car ce bouton que l'on voit c'en est un autre.Citation:
Envoyé par psychadelic
Voilà c'est tout, je sais qu'il y a eu de la confusion, j'ai juste voulu clarifier les choses parce que j'ai cherché à comprendre plus en profondeur ce que tout le monde ne souhaite pas forcément faire, c'est noté... Alors désolé de vous avoir pris la tête...
Coucou,
effectivement j’ai utilisé le terme « référence » dans un sens assez vague et je vais tenter d’expliquer un peu mieux ce que je voulais dire.
Donc reprenons notre situation de départ : on a un <button>, ou plus exactement sa représentation DOM, palpable, manipulable via du code JavaScript.
Sur ce bouton, on a attaché un gestionnaire d’évènement "click".
Sans entrer dans les détails d’implémentation de tel ou tel navigateur, il est raisonnable de penser que le gestionnaire d’évènement garde un pointeur ou autre mécanisme qui lui permet d’avoir accès au bouton, car il doit le rendre disponible via le mot-clé this dans la fonction de rappel. C’est ça que j’appelle une référence.
Réciproquement, le bouton a une sorte de référence sur le gestionnaire de "click", peut-être plus abstraite, du genre le navigateur maintient une table de quels évènements sont associés à quels éléments du DOM, je n’en sais rien.
Quand on « écrase » le bouton avec une instruction innerHTML, c’est un nouveau bouton qui le remplace, et ce nouveau bouton n’a pas de gestionnaire de "click" associé, car on n’en a jamais attaché sur celui-là. L’ancien gestionnaire d’évènement est dans les faits « désactivé » car le bouton sur lequel il était censé agir n’existe plus. Là, je disais « les références sont brisées » dans un sens plus symbolique, et c’était peut-être abusif. J’espère que vous voyez mieux l’idée maintenant ;)
Pour être plus précis et pour tenter de répondre à la question initiale de Doksuri, je vais parler de l’identité des objets. Toute valeur non primitive en JavaScript a une identité qui lui est propre, une sorte d’étiquette interne qui n’est pas accessible en JS, mais dont on peut se rendre compte en utilisant la comparaison == ou ===, ou la méthode Object.is().
Par exemple, si je déclare deux objets ayant exactement les mêmes propriétés, ils seront tout de même différents :
Si j’instancie deux éléments <button>, ils seront différents :Code:
2
3
Et si j’utilise innerHTML, ça crée des objets DOM différents comme on peut s’en rendre compte ici :Code:
2
3
Code:
2
3
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
Merci Watilin pour ces éclaircissements...
Et oui pour reprendre l'exemple de Doksuri (avec le changement que j'ai signalé au message ) : si on retire un élément (la span #span2) du DOM et qu'à sa place on insère un autre élément (la span "newSpan2") eh bien malgré que le deuxième occupe dans le DOM la place du premier il n'en reste pas moins que ce sont deux éléments différents...
C'est ce que j'essayais d'expliquer (en vain apparemment) notamment aux messages #9 et #10 mais peut-être qu'avec le message de Watilin ce sera plus clair...