utilitaire pour trouver le meilleur chemin dans l'arbre DOM
11 réponses
Olivier Masson
Bonjour,
Comme j'utilise toujours sizzle pour trouver mes éléments, je n'ai
aucune habitude de la recherche "manuelle".
Existe-t-il des outils, probablement dans firebug, permettant d'avoir
les chemins, voire le meilleur (le plus rapide en terme de perf)
conduisant à un élément sélectionné ? Chemin qui devra être compatible
avec IE7&8.
Comme j'utilise toujours sizzle pour trouver mes éléments, je n'ai aucune habitude de la recherche "manuelle".
Connaissais pas "sizzle". J'ai souvenir de "behavior", je crois, qui faisait la même chose.
Existe-t-il des outils, probablement dans firebug, permettant d'avoir les chemins, voire le meilleur (le plus rapide en terme de perf) conduisant à un élément sélectionné ? Chemin qui devra être compatible avec IE7&8.
Comprends pas, il s'agit de traverser le DOM, c'est ça ? Et la méthode serait toujours la même, ou dépend-elle de l'élément recherché ? Faut-il passer par la classe CSS ou seulement l'ID ?
Bon, à défaut, la façon la plus rapide et pertinente de trouver un élément dans un DOM est d'abord de lui coller un identifiant unique (ID), puis de lancer la méthode "document.getElementById(ID)".
Curieusement, cette méthode est même plus rapide que les accès au DOM d'origine (alias DOM-0), tels que "document.forms[name].elements[name]". Voir test en ligne : [http://jsperf.com/getelementbyid-and-forms]. Je suppose qu'il en va de même pour les "images", "links", etc.
-- Cordialement, Pascal
Le 22/07/2011 08:28, Olivier Masson a écrit :
Bonjour,
Bonjour,
Comme j'utilise toujours sizzle pour trouver mes éléments, je n'ai
aucune habitude de la recherche "manuelle".
Connaissais pas "sizzle". J'ai souvenir de "behavior", je crois, qui
faisait la même chose.
Existe-t-il des outils, probablement dans firebug, permettant d'avoir
les chemins, voire le meilleur (le plus rapide en terme de perf)
conduisant à un élément sélectionné ? Chemin qui devra être compatible
avec IE7&8.
Comprends pas, il s'agit de traverser le DOM, c'est ça ?
Et la méthode serait toujours la même, ou dépend-elle de l'élément
recherché ? Faut-il passer par la classe CSS ou seulement l'ID ?
Bon, à défaut, la façon la plus rapide et pertinente de trouver un
élément dans un DOM est d'abord de lui coller un identifiant unique
(ID), puis de lancer la méthode "document.getElementById(ID)".
Curieusement, cette méthode est même plus rapide que les accès au DOM
d'origine (alias DOM-0), tels que "document.forms[name].elements[name]".
Voir test en ligne : [http://jsperf.com/getelementbyid-and-forms].
Je suppose qu'il en va de même pour les "images", "links", etc.
Comme j'utilise toujours sizzle pour trouver mes éléments, je n'ai aucune habitude de la recherche "manuelle".
Connaissais pas "sizzle". J'ai souvenir de "behavior", je crois, qui faisait la même chose.
Existe-t-il des outils, probablement dans firebug, permettant d'avoir les chemins, voire le meilleur (le plus rapide en terme de perf) conduisant à un élément sélectionné ? Chemin qui devra être compatible avec IE7&8.
Comprends pas, il s'agit de traverser le DOM, c'est ça ? Et la méthode serait toujours la même, ou dépend-elle de l'élément recherché ? Faut-il passer par la classe CSS ou seulement l'ID ?
Bon, à défaut, la façon la plus rapide et pertinente de trouver un élément dans un DOM est d'abord de lui coller un identifiant unique (ID), puis de lancer la méthode "document.getElementById(ID)".
Curieusement, cette méthode est même plus rapide que les accès au DOM d'origine (alias DOM-0), tels que "document.forms[name].elements[name]". Voir test en ligne : [http://jsperf.com/getelementbyid-and-forms]. Je suppose qu'il en va de même pour les "images", "links", etc.
-- Cordialement, Pascal
SAM
Le 22/07/11 08:28, Olivier Masson a écrit :
Bonjour,
Comme j'utilise toujours sizzle pour trouver mes éléments,
Parce que tu ne sais pas comment tu les as organisés ? Tu as oublié de leur donner une identification ?
Je n'ai malheureusement pas trouvé de mode d'emploi ici : <http://sizzlejs.com/> ni même un seul exemple de manipulation ... (c'est loin d'avoir une explication en fr)
ça a l'air d'être une espèce de jquery spécialisé (mais à quoi, et pourquoi ?)
je n'ai aucune habitude de la recherche "manuelle". Existe-t-il des outils, probablement dans firebug, permettant d'avoir les chemins, voire le meilleur (le plus rapide en terme de perf) conduisant à un élément sélectionné ?
keskecé un "chemin" "conduisant" à ... (si l'élément est sélectionné ... on a besoin de sa position dans l'arbre DOM ?) Firebug te montre le document (le code html) et en panneau latéral les css correspondant à l'élément inspecté dans le html. Le chemin vers l'élément y est directement visible par l'ouverture des balises imbriquées.
Chemin qui devra être compatible avec IE7&8.
Je pense qu'ils doivent être capables de comprendre : var el = document.getElementById('elemtId'); (même si c'est tout récent) et même : var td = el.getElementsByTagName('TD'), n = td.length; if(n && n>0) while(n--) { if(td[n] ...) return 'cool' }
À l'inverse ils doivent aussi savoir faire : var contener = this.parentNode; while(contener.tagName != 'TD') contener = contener.parentNode;
Merci.
Le + rapide doit certainement être : getElementById pour tout élément dont l'ID est renseigné, et : document.forms[index ou name].element[name] pour tout élément de formulaire (à ce que je crois, l'arbre des forms est systématiquement construit lors du parsage du fichier, tout comme celui du DOM)
Après quand on joue avec des documents dont la reconnaissance des éléments se fait par leur(s) classe(s) ... là y a plus ka tirer l'échelle question performances ! :-(
Mais ... qqu'un se soucie encore de performances ? Tout le monde sur Terre n'a pas le câble ? Tout le monde n'a pas d'ordi à processeur i25 ?
-- Stéphane Moriaux avec/with iMac-intel
Le 22/07/11 08:28, Olivier Masson a écrit :
Bonjour,
Comme j'utilise toujours sizzle pour trouver mes éléments,
Parce que tu ne sais pas comment tu les as organisés ?
Tu as oublié de leur donner une identification ?
Je n'ai malheureusement pas trouvé de mode d'emploi ici :
<http://sizzlejs.com/>
ni même un seul exemple de manipulation ...
(c'est loin d'avoir une explication en fr)
ça a l'air d'être une espèce de jquery spécialisé
(mais à quoi, et pourquoi ?)
je n'ai aucune habitude de la recherche "manuelle".
Existe-t-il des outils, probablement dans firebug, permettant d'avoir
les chemins, voire le meilleur (le plus rapide en terme de perf)
conduisant à un élément sélectionné ?
keskecé un "chemin" "conduisant" à ...
(si l'élément est sélectionné ... on a besoin de sa position dans
l'arbre DOM ?)
Firebug te montre le document (le code html) et en panneau latéral les
css correspondant à l'élément inspecté dans le html.
Le chemin vers l'élément y est directement visible par l'ouverture des
balises imbriquées.
Chemin qui devra être compatible avec IE7&8.
Je pense qu'ils doivent être capables de comprendre :
var el = document.getElementById('elemtId');
(même si c'est tout récent)
et même :
var td = el.getElementsByTagName('TD'), n = td.length;
if(n && n>0) while(n--) { if(td[n] ...) return 'cool' }
À l'inverse ils doivent aussi savoir faire :
var contener = this.parentNode;
while(contener.tagName != 'TD') contener = contener.parentNode;
Merci.
Le + rapide doit certainement être :
getElementById
pour tout élément dont l'ID est renseigné,
et :
document.forms[index ou name].element[name]
pour tout élément de formulaire
(à ce que je crois, l'arbre des forms est systématiquement construit
lors du parsage du fichier, tout comme celui du DOM)
Après quand on joue avec des documents dont la reconnaissance des
éléments se fait par leur(s) classe(s) ... là y a plus ka tirer
l'échelle question performances ! :-(
Mais ... qqu'un se soucie encore de performances ?
Tout le monde sur Terre n'a pas le câble ?
Tout le monde n'a pas d'ordi à processeur i25 ?
Comme j'utilise toujours sizzle pour trouver mes éléments,
Parce que tu ne sais pas comment tu les as organisés ? Tu as oublié de leur donner une identification ?
Je n'ai malheureusement pas trouvé de mode d'emploi ici : <http://sizzlejs.com/> ni même un seul exemple de manipulation ... (c'est loin d'avoir une explication en fr)
ça a l'air d'être une espèce de jquery spécialisé (mais à quoi, et pourquoi ?)
je n'ai aucune habitude de la recherche "manuelle". Existe-t-il des outils, probablement dans firebug, permettant d'avoir les chemins, voire le meilleur (le plus rapide en terme de perf) conduisant à un élément sélectionné ?
keskecé un "chemin" "conduisant" à ... (si l'élément est sélectionné ... on a besoin de sa position dans l'arbre DOM ?) Firebug te montre le document (le code html) et en panneau latéral les css correspondant à l'élément inspecté dans le html. Le chemin vers l'élément y est directement visible par l'ouverture des balises imbriquées.
Chemin qui devra être compatible avec IE7&8.
Je pense qu'ils doivent être capables de comprendre : var el = document.getElementById('elemtId'); (même si c'est tout récent) et même : var td = el.getElementsByTagName('TD'), n = td.length; if(n && n>0) while(n--) { if(td[n] ...) return 'cool' }
À l'inverse ils doivent aussi savoir faire : var contener = this.parentNode; while(contener.tagName != 'TD') contener = contener.parentNode;
Merci.
Le + rapide doit certainement être : getElementById pour tout élément dont l'ID est renseigné, et : document.forms[index ou name].element[name] pour tout élément de formulaire (à ce que je crois, l'arbre des forms est systématiquement construit lors du parsage du fichier, tout comme celui du DOM)
Après quand on joue avec des documents dont la reconnaissance des éléments se fait par leur(s) classe(s) ... là y a plus ka tirer l'échelle question performances ! :-(
Mais ... qqu'un se soucie encore de performances ? Tout le monde sur Terre n'a pas le câble ? Tout le monde n'a pas d'ordi à processeur i25 ?
-- Stéphane Moriaux avec/with iMac-intel
SAM
Le 22/07/11 10:28, Pascal Poncet a écrit :
Bon, à défaut, la façon la plus rapide et pertinente de trouver un élément dans un DOM est d'abord de lui coller un identifiant unique (ID), puis de lancer la méthode "document.getElementById(ID)".
Curieusement, cette méthode est même plus rapide que les accès au DOM d'origine (alias DOM-0), tels que "document.forms[name].elements[name]". Voir test en ligne : [http://jsperf.com/getelementbyid-and-forms]. Je suppose qu'il en va de même pour les "images", "links", etc.
Heu ... ça a l'air de bien dépendre du navigateur, non ?
Ha?! Mais ce sont pas des vitesses qui sont exprimées ! Alors, oui, en effet c'est surprenant.
Il eût été intéressant d'avoir le même test avec le form profondément imbriqué dans le DOM.
-- Stéphane Moriaux avec/with iMac-intel
Le 22/07/11 10:28, Pascal Poncet a écrit :
Bon, à défaut, la façon la plus rapide et pertinente de trouver un
élément dans un DOM est d'abord de lui coller un identifiant unique
(ID), puis de lancer la méthode "document.getElementById(ID)".
Curieusement, cette méthode est même plus rapide que les accès au DOM
d'origine (alias DOM-0), tels que "document.forms[name].elements[name]".
Voir test en ligne : [http://jsperf.com/getelementbyid-and-forms].
Je suppose qu'il en va de même pour les "images", "links", etc.
Heu ... ça a l'air de bien dépendre du navigateur, non ?
Ha?! Mais ce sont pas des vitesses qui sont exprimées !
Alors, oui, en effet c'est surprenant.
Il eût été intéressant d'avoir le même test avec le form profondément
imbriqué dans le DOM.
Bon, à défaut, la façon la plus rapide et pertinente de trouver un élément dans un DOM est d'abord de lui coller un identifiant unique (ID), puis de lancer la méthode "document.getElementById(ID)".
Curieusement, cette méthode est même plus rapide que les accès au DOM d'origine (alias DOM-0), tels que "document.forms[name].elements[name]". Voir test en ligne : [http://jsperf.com/getelementbyid-and-forms]. Je suppose qu'il en va de même pour les "images", "links", etc.
Heu ... ça a l'air de bien dépendre du navigateur, non ?
Ha?! Mais ce sont pas des vitesses qui sont exprimées ! Alors, oui, en effet c'est surprenant.
Il eût été intéressant d'avoir le même test avec le form profondément imbriqué dans le DOM.
-- Stéphane Moriaux avec/with iMac-intel
Pierre Goiffon
On 22/07/2011 08:28, Olivier Masson wrote:
Comme j'utilise toujours sizzle pour trouver mes éléments, je n'ai aucune habitude de la recherche "manuelle". Existe-t-il des outils, probablement dans firebug, permettant d'avoir les chemins, voire le meilleur (le plus rapide en terme de perf) conduisant à un élément sélectionné ? Chemin qui devra être compatible avec IE7&8.
Je ne connais pas trop d'articles sur le sujet, et pourtant il a son importance... (et c'est la même chose avec les sélecteurs css)
Avec des librairies comme JQuery on écrit en peu de lignes des traitements qui vont lancer des parcours intensifs et potentiellement écrouler les perf sur des navigateurs !
Juste tombé sur cette règle sur le site yahoo perf : http://developer.yahoo.com/performance/rules.html#dom_access
On 22/07/2011 08:28, Olivier Masson wrote:
Comme j'utilise toujours sizzle pour trouver mes éléments, je n'ai
aucune habitude de la recherche "manuelle".
Existe-t-il des outils, probablement dans firebug, permettant d'avoir
les chemins, voire le meilleur (le plus rapide en terme de perf)
conduisant à un élément sélectionné ? Chemin qui devra être compatible
avec IE7&8.
Je ne connais pas trop d'articles sur le sujet, et pourtant il a son
importance... (et c'est la même chose avec les sélecteurs css)
Avec des librairies comme JQuery on écrit en peu de lignes des
traitements qui vont lancer des parcours intensifs et potentiellement
écrouler les perf sur des navigateurs !
Juste tombé sur cette règle sur le site yahoo perf :
http://developer.yahoo.com/performance/rules.html#dom_access
Comme j'utilise toujours sizzle pour trouver mes éléments, je n'ai aucune habitude de la recherche "manuelle". Existe-t-il des outils, probablement dans firebug, permettant d'avoir les chemins, voire le meilleur (le plus rapide en terme de perf) conduisant à un élément sélectionné ? Chemin qui devra être compatible avec IE7&8.
Je ne connais pas trop d'articles sur le sujet, et pourtant il a son importance... (et c'est la même chose avec les sélecteurs css)
Avec des librairies comme JQuery on écrit en peu de lignes des traitements qui vont lancer des parcours intensifs et potentiellement écrouler les perf sur des navigateurs !
Juste tombé sur cette règle sur le site yahoo perf : http://developer.yahoo.com/performance/rules.html#dom_access
Olivier Masson
Le 22/07/2011 08:28, Olivier Masson a écrit :
Bonjour,
Comme j'utilise toujours sizzle pour trouver mes éléments, je n'ai aucune habitude de la recherche "manuelle". Existe-t-il des outils, probablement dans firebug, permettant d'avoir les chemins, voire le meilleur (le plus rapide en terme de perf) conduisant à un élément sélectionné ? Chemin qui devra être compatible avec IE7&8.
Merci.
Bon, j'ai dû mal m'exprimer. Je fais donc suite à mon propre message.
Mettre des id, je suis tout à fait d'accord avec vous, ça rend la manip simple et c'est ce qu'il y a de plus rapide. Mais je ne vais pas mettre des id partout. Et partons du principe que je ne peux pas toucher le code HTML. Donc, s'il y a un id, l'outil devrait me renvoyer getElementById, sinon un chemin rapide.
Le 22/07/2011 08:28, Olivier Masson a écrit :
Bonjour,
Comme j'utilise toujours sizzle pour trouver mes éléments, je n'ai
aucune habitude de la recherche "manuelle".
Existe-t-il des outils, probablement dans firebug, permettant d'avoir
les chemins, voire le meilleur (le plus rapide en terme de perf)
conduisant à un élément sélectionné ? Chemin qui devra être compatible
avec IE7&8.
Merci.
Bon, j'ai dû mal m'exprimer. Je fais donc suite à mon propre message.
Mettre des id, je suis tout à fait d'accord avec vous, ça rend la manip
simple et c'est ce qu'il y a de plus rapide.
Mais je ne vais pas mettre des id partout. Et partons du principe que je
ne peux pas toucher le code HTML.
Donc, s'il y a un id, l'outil devrait me renvoyer getElementById, sinon
un chemin rapide.
Comme j'utilise toujours sizzle pour trouver mes éléments, je n'ai aucune habitude de la recherche "manuelle". Existe-t-il des outils, probablement dans firebug, permettant d'avoir les chemins, voire le meilleur (le plus rapide en terme de perf) conduisant à un élément sélectionné ? Chemin qui devra être compatible avec IE7&8.
Merci.
Bon, j'ai dû mal m'exprimer. Je fais donc suite à mon propre message.
Mettre des id, je suis tout à fait d'accord avec vous, ça rend la manip simple et c'est ce qu'il y a de plus rapide. Mais je ne vais pas mettre des id partout. Et partons du principe que je ne peux pas toucher le code HTML. Donc, s'il y a un id, l'outil devrait me renvoyer getElementById, sinon un chemin rapide.
Olivier Masson
Le 22/07/2011 10:32, SAM a écrit :
ça a l'air d'être une espèce de jquery spécialisé (mais à quoi, et pourquoi ?)
C'est l'inverse : jQuery utilise sizzle. Avec sizzle, tu as tous les sélecteurs CSS existants et d'autres. Tu ne te préoccupes pas de la compatibilité. C'est très rapide. En fait, c'est assez idéal, mais parfois, comme je n'ai besoin du chemin que pour deux ou trois éléments dans le JS, c'est un peu disproprotionné d'utiliser sizzle.
Le 22/07/2011 10:32, SAM a écrit :
ça a l'air d'être une espèce de jquery spécialisé
(mais à quoi, et pourquoi ?)
C'est l'inverse : jQuery utilise sizzle.
Avec sizzle, tu as tous les sélecteurs CSS existants et d'autres. Tu ne
te préoccupes pas de la compatibilité. C'est très rapide.
En fait, c'est assez idéal, mais parfois, comme je n'ai besoin du chemin
que pour deux ou trois éléments dans le JS, c'est un peu disproprotionné
d'utiliser sizzle.
ça a l'air d'être une espèce de jquery spécialisé (mais à quoi, et pourquoi ?)
C'est l'inverse : jQuery utilise sizzle. Avec sizzle, tu as tous les sélecteurs CSS existants et d'autres. Tu ne te préoccupes pas de la compatibilité. C'est très rapide. En fait, c'est assez idéal, mais parfois, comme je n'ai besoin du chemin que pour deux ou trois éléments dans le JS, c'est un peu disproprotionné d'utiliser sizzle.
Pascal Poncet
Le 25/07/2011 10:46, Olivier Masson a écrit :
Donc, s'il y a un id, l'outil devrait me renvoyer getElementById, sinon un chemin rapide.
Si j'ai bien tout compris, tu veux un outil qui, partant d'un chemin XPath, te donne le JS correspondant, c'est ça ?
Firebug te donne déjà le chemin XPath, dans le panneau HTML, quand tu survoles un élément du DOM. Tu peux même copier ce chemin, dans la syntaxe XPath, par le menu contextuel (clic droit sur l'élément).
Par exemple, tu voudrais que le chemin "/html/body/div[3]/p[2]" soit transformé en :
Avec une fonction getChildNodesByTagName() qui reste à définir car la fonction DOM-W3C getElementsByTagName() va chercher dans tous les descendants, et non pas seulement les enfants (hélas).
Je ne connais pas l'outil que tu cherches, mais il y a des extensions à Firebug et peut-être que tu y trouveras ton bonheur. [http://getfirebug.com/wiki/index.php/Firebug_Extensions]
-- Cordialement, Pascal
Le 25/07/2011 10:46, Olivier Masson a écrit :
Donc, s'il y a un id, l'outil devrait me renvoyer getElementById, sinon
un chemin rapide.
Si j'ai bien tout compris, tu veux un outil qui, partant d'un chemin
XPath, te donne le JS correspondant, c'est ça ?
Firebug te donne déjà le chemin XPath, dans le panneau HTML, quand tu
survoles un élément du DOM.
Tu peux même copier ce chemin, dans la syntaxe XPath, par le menu
contextuel (clic droit sur l'élément).
Par exemple, tu voudrais que le chemin "/html/body/div[3]/p[2]" soit
transformé en :
Avec une fonction getChildNodesByTagName() qui reste à définir car la
fonction DOM-W3C getElementsByTagName() va chercher dans tous les
descendants, et non pas seulement les enfants (hélas).
Je ne connais pas l'outil que tu cherches, mais il y a des extensions à
Firebug et peut-être que tu y trouveras ton bonheur.
[http://getfirebug.com/wiki/index.php/Firebug_Extensions]
Donc, s'il y a un id, l'outil devrait me renvoyer getElementById, sinon un chemin rapide.
Si j'ai bien tout compris, tu veux un outil qui, partant d'un chemin XPath, te donne le JS correspondant, c'est ça ?
Firebug te donne déjà le chemin XPath, dans le panneau HTML, quand tu survoles un élément du DOM. Tu peux même copier ce chemin, dans la syntaxe XPath, par le menu contextuel (clic droit sur l'élément).
Par exemple, tu voudrais que le chemin "/html/body/div[3]/p[2]" soit transformé en :
Avec une fonction getChildNodesByTagName() qui reste à définir car la fonction DOM-W3C getElementsByTagName() va chercher dans tous les descendants, et non pas seulement les enfants (hélas).
Je ne connais pas l'outil que tu cherches, mais il y a des extensions à Firebug et peut-être que tu y trouveras ton bonheur. [http://getfirebug.com/wiki/index.php/Firebug_Extensions]
-- Cordialement, Pascal
Olivier Masson
Le 25/07/2011 13:15, Pascal Poncet a écrit :
Le 25/07/2011 10:46, Olivier Masson a écrit :
Donc, s'il y a un id, l'outil devrait me renvoyer getElementById, sinon un chemin rapide.
Si j'ai bien tout compris, tu veux un outil qui, partant d'un chemin XPath, te donne le JS correspondant, c'est ça ?
Oui et non. Le but est bien d'atteindre l'élément en JS, mais également le plus rapidement possible. Déjà pour des raisons de perf, mais aussi pour apprendre, petit à petit, quels sont les sélecteurs a utilisé en priorité.
Avec une fonction getChildNodesByTagName() qui reste à définir car la fonction DOM-W3C getElementsByTagName() va chercher dans tous les descendants, et non pas seulement les enfants (hélas).
Exactement, c'est bien le problème.
Je ne connais pas l'outil que tu cherches, mais il y a des extensions à Firebug et peut-être que tu y trouveras ton bonheur. [http://getfirebug.com/wiki/index.php/Firebug_Extensions]
Ah ben merci, je ne connaissais même pas ce site !
Le 25/07/2011 13:15, Pascal Poncet a écrit :
Le 25/07/2011 10:46, Olivier Masson a écrit :
Donc, s'il y a un id, l'outil devrait me renvoyer getElementById, sinon
un chemin rapide.
Si j'ai bien tout compris, tu veux un outil qui, partant d'un chemin
XPath, te donne le JS correspondant, c'est ça ?
Oui et non. Le but est bien d'atteindre l'élément en JS, mais également
le plus rapidement possible. Déjà pour des raisons de perf, mais aussi
pour apprendre, petit à petit, quels sont les sélecteurs a utilisé en
priorité.
Avec une fonction getChildNodesByTagName() qui reste à définir car la
fonction DOM-W3C getElementsByTagName() va chercher dans tous les
descendants, et non pas seulement les enfants (hélas).
Exactement, c'est bien le problème.
Je ne connais pas l'outil que tu cherches, mais il y a des extensions à
Firebug et peut-être que tu y trouveras ton bonheur.
[http://getfirebug.com/wiki/index.php/Firebug_Extensions]
Ah ben merci, je ne connaissais même pas ce site !
Donc, s'il y a un id, l'outil devrait me renvoyer getElementById, sinon un chemin rapide.
Si j'ai bien tout compris, tu veux un outil qui, partant d'un chemin XPath, te donne le JS correspondant, c'est ça ?
Oui et non. Le but est bien d'atteindre l'élément en JS, mais également le plus rapidement possible. Déjà pour des raisons de perf, mais aussi pour apprendre, petit à petit, quels sont les sélecteurs a utilisé en priorité.
Avec une fonction getChildNodesByTagName() qui reste à définir car la fonction DOM-W3C getElementsByTagName() va chercher dans tous les descendants, et non pas seulement les enfants (hélas).
Exactement, c'est bien le problème.
Je ne connais pas l'outil que tu cherches, mais il y a des extensions à Firebug et peut-être que tu y trouveras ton bonheur. [http://getfirebug.com/wiki/index.php/Firebug_Extensions]
Ah ben merci, je ne connaissais même pas ce site !
Pascal Poncet
Le 25/07/2011 15:19, Olivier Masson a écrit :
Le 25/07/2011 13:15, Pascal Poncet a écrit :
Avec une fonction getChildNodesByTagName() qui reste à définir car la fonction DOM-W3C getElementsByTagName() va chercher dans tous les descendants, et non pas seulement les enfants (hélas).
Exactement, c'est bien le problème.
A ce propos, comme j'ai déjà rencontré ce genre de problème, j'en ai profité pour mettre au point la fonction susdite. Je mets le code en partage, au cas où ça intéresserait.
La définition de la fonction : ----------------------------
function getChildNodesByTagName(tagName) { if (! this.nodeType && this.nodeType != 1) return null; tagName = tagName.toLowerCase(); var currentNode = this.firstChild, resultChilds = []; do { if ( currentNode.nodeType == 1 && currentNode.tagName.toLowerCase() == tagName) { resultChilds.push(currentNode); } } while (currentNode = currentNode.nextSibling); return resultChilds; }
Un bout de HTML pour test : -------------------------
<body> <p>1er para</p> <p>2e para</p> <p>3e para avec <span>1er span</span> et <span>2e span</span></p> <p>Résultat : <span id="result"></span></p> </body>
Et le script qui appelle la fonction : ------------------------------------
!!! Testé sous Firefox 5.0 et Chrome 11.0 uniquement.
Basé sur un mélange personnel des propositions suivantes : - [http://michhimself.com/blog/javascript-getchildnodesbytagname/] - [http://markmail.org/download.xqy?id®bxduxdaucy3atm&number=1]
-- Cordialement, Pascal
Le 25/07/2011 15:19, Olivier Masson a écrit :
Le 25/07/2011 13:15, Pascal Poncet a écrit :
Avec une fonction getChildNodesByTagName() qui reste à définir car la
fonction DOM-W3C getElementsByTagName() va chercher dans tous les
descendants, et non pas seulement les enfants (hélas).
Exactement, c'est bien le problème.
A ce propos, comme j'ai déjà rencontré ce genre de problème, j'en ai
profité pour mettre au point la fonction susdite.
Je mets le code en partage, au cas où ça intéresserait.
La définition de la fonction :
----------------------------
function getChildNodesByTagName(tagName) {
if (! this.nodeType && this.nodeType != 1) return null;
tagName = tagName.toLowerCase();
var currentNode = this.firstChild,
resultChilds = [];
do {
if ( currentNode.nodeType == 1 &&
currentNode.tagName.toLowerCase() == tagName) {
resultChilds.push(currentNode);
}
} while (currentNode = currentNode.nextSibling);
return resultChilds;
}
Un bout de HTML pour test :
-------------------------
<body>
<p>1er para</p>
<p>2e para</p>
<p>3e para avec <span>1er span</span> et <span>2e span</span></p>
<p>Résultat : <span id="result"></span></p>
</body>
Et le script qui appelle la fonction :
------------------------------------
!!! Testé sous Firefox 5.0 et Chrome 11.0 uniquement.
Basé sur un mélange personnel des propositions suivantes :
- [http://michhimself.com/blog/javascript-getchildnodesbytagname/]
- [http://markmail.org/download.xqy?id®bxduxdaucy3atm&number=1]
Avec une fonction getChildNodesByTagName() qui reste à définir car la fonction DOM-W3C getElementsByTagName() va chercher dans tous les descendants, et non pas seulement les enfants (hélas).
Exactement, c'est bien le problème.
A ce propos, comme j'ai déjà rencontré ce genre de problème, j'en ai profité pour mettre au point la fonction susdite. Je mets le code en partage, au cas où ça intéresserait.
La définition de la fonction : ----------------------------
function getChildNodesByTagName(tagName) { if (! this.nodeType && this.nodeType != 1) return null; tagName = tagName.toLowerCase(); var currentNode = this.firstChild, resultChilds = []; do { if ( currentNode.nodeType == 1 && currentNode.tagName.toLowerCase() == tagName) { resultChilds.push(currentNode); } } while (currentNode = currentNode.nextSibling); return resultChilds; }
Un bout de HTML pour test : -------------------------
<body> <p>1er para</p> <p>2e para</p> <p>3e para avec <span>1er span</span> et <span>2e span</span></p> <p>Résultat : <span id="result"></span></p> </body>
Et le script qui appelle la fonction : ------------------------------------
!!! Testé sous Firefox 5.0 et Chrome 11.0 uniquement.
Basé sur un mélange personnel des propositions suivantes : - [http://michhimself.com/blog/javascript-getchildnodesbytagname/] - [http://markmail.org/download.xqy?id®bxduxdaucy3atm&number=1]
-- Cordialement, Pascal
Olivier Masson
Le 25/07/2011 16:57, Pascal Poncet a écrit :
A ce propos, comme j'ai déjà rencontré ce genre de problème, j'en ai profité pour mettre au point la fonction susdite. Je mets le code en partage, au cas où ça intéresserait.
Ben moi déjà. Merci. Parce que malheureusement, les extensions firebug ne permettent que de connaitre le XPath, l'expression CSS voire le chemin sizzle (pas du tout optimisé). Rien ne permettant ce que je souhaite.
Le 25/07/2011 16:57, Pascal Poncet a écrit :
A ce propos, comme j'ai déjà rencontré ce genre de problème, j'en ai
profité pour mettre au point la fonction susdite.
Je mets le code en partage, au cas où ça intéresserait.
Ben moi déjà. Merci.
Parce que malheureusement, les extensions firebug ne permettent que de
connaitre le XPath, l'expression CSS voire le chemin sizzle (pas du tout
optimisé). Rien ne permettant ce que je souhaite.
A ce propos, comme j'ai déjà rencontré ce genre de problème, j'en ai profité pour mettre au point la fonction susdite. Je mets le code en partage, au cas où ça intéresserait.
Ben moi déjà. Merci. Parce que malheureusement, les extensions firebug ne permettent que de connaitre le XPath, l'expression CSS voire le chemin sizzle (pas du tout optimisé). Rien ne permettant ce que je souhaite.
