L'instruction node.innerHTML = ... plante sous IE (mais pas sous FF) !
Quelqu'un saurait-il d'où vient le problème ?
En attendant de trouver une solution je réécris entièrement le tableau
(id="refreshable" placé sur la balise <table>), ce qui provoque un
clignotement lors du rafraichissement.
En attendant de trouver une solution je réécris entièrement le tableau (id="refreshable" placé sur la balise <table>), ce qui provoque un clignotement lors du rafraichissement.
Pour info, les scripts de tri de tableau n'utilisent généralement pas innerHTML, trop gourmand en ressources et donc subséquemment bien lent, mais suivent plutôt un fonctionnement en deux étapes:
[1] récupération des données de façon optimisée, constitution d'une liste triable de type {élément de comparaison; référence vers la ligne (TR) correspondante}, tri de la liste en utilisant Array.prototype.sort(comparateur efficace); possibilité de conserver un cache;
[2] réorganisation des lignes (TR) en fonction de leur position triée, en utilisant les méthodes de manipulation de nodes (insertBefore, appendChild) - avec un intérêt sous Gecko à effecter cette opération en détachant préalablement l'arbre représentant la table complète, de l'arborescence globale.
En attendant de trouver une solution je réécris entièrement le tableau
(id="refreshable" placé sur la balise <table>), ce qui provoque un
clignotement lors du rafraichissement.
Pour info, les scripts de tri de tableau n'utilisent généralement pas
innerHTML, trop gourmand en ressources et donc subséquemment bien lent,
mais suivent plutôt un fonctionnement en deux étapes:
[1] récupération des données de façon optimisée, constitution d'une
liste triable de type {élément de comparaison; référence vers la ligne
(TR) correspondante}, tri de la liste en utilisant
Array.prototype.sort(comparateur efficace); possibilité de conserver un
cache;
[2] réorganisation des lignes (TR) en fonction de leur position triée,
en utilisant les méthodes de manipulation de nodes (insertBefore,
appendChild) - avec un intérêt sous Gecko à effecter cette opération en
détachant préalablement l'arbre représentant la table complète, de
l'arborescence globale.
En attendant de trouver une solution je réécris entièrement le tableau (id="refreshable" placé sur la balise <table>), ce qui provoque un clignotement lors du rafraichissement.
Pour info, les scripts de tri de tableau n'utilisent généralement pas innerHTML, trop gourmand en ressources et donc subséquemment bien lent, mais suivent plutôt un fonctionnement en deux étapes:
[1] récupération des données de façon optimisée, constitution d'une liste triable de type {élément de comparaison; référence vers la ligne (TR) correspondante}, tri de la liste en utilisant Array.prototype.sort(comparateur efficace); possibilité de conserver un cache;
[2] réorganisation des lignes (TR) en fonction de leur position triée, en utilisant les méthodes de manipulation de nodes (insertBefore, appendChild) - avec un intérêt sous Gecko à effecter cette opération en détachant préalablement l'arbre représentant la table complète, de l'arborescence globale.
Pour info, les scripts de tri de tableau n'utilisent généralement pas innerHTML, trop gourmand en ressources et donc subséquemment bien lent, mais suivent plutôt un fonctionnement en deux étapes:
En quoi innerHTML est-il gourmand en ressources ? Avez-vous un article la dessus ?
[1] récupération des données de façon optimisée, constitution d'une liste triable de type {élément de comparaison; référence vers la ligne (TR) correspondante}, tri de la liste en utilisant Array.prototype.sort(comparateur efficace); possibilité de conserver un cache;
[2] réorganisation des lignes (TR) en fonction de leur position triée, en utilisant les méthodes de manipulation de nodes (insertBefore, appendChild) - avec un intérêt sous Gecko à effecter cette opération en détachant préalablement l'arbre représentant la table complète, de l'arborescence globale.
Pour info, les scripts de tri de tableau n'utilisent généralement pas
innerHTML, trop gourmand en ressources et donc subséquemment bien lent,
mais suivent plutôt un fonctionnement en deux étapes:
En quoi innerHTML est-il gourmand en ressources ? Avez-vous un article la
dessus ?
[1] récupération des données de façon optimisée, constitution d'une
liste triable de type {élément de comparaison; référence vers la
ligne (TR) correspondante}, tri de la liste en utilisant
Array.prototype.sort(comparateur efficace); possibilité de conserver un
cache;
[2] réorganisation des lignes (TR) en fonction de leur position triée,
en utilisant les méthodes de manipulation de nodes (insertBefore,
appendChild) - avec un intérêt sous Gecko à effecter cette opération
en détachant préalablement l'arbre représentant la table complète,
de l'arborescence globale.
Pour info, les scripts de tri de tableau n'utilisent généralement pas innerHTML, trop gourmand en ressources et donc subséquemment bien lent, mais suivent plutôt un fonctionnement en deux étapes:
En quoi innerHTML est-il gourmand en ressources ? Avez-vous un article la dessus ?
[1] récupération des données de façon optimisée, constitution d'une liste triable de type {élément de comparaison; référence vers la ligne (TR) correspondante}, tri de la liste en utilisant Array.prototype.sort(comparateur efficace); possibilité de conserver un cache;
[2] réorganisation des lignes (TR) en fonction de leur position triée, en utilisant les méthodes de manipulation de nodes (insertBefore, appendChild) - avec un intérêt sous Gecko à effecter cette opération en détachant préalablement l'arbre représentant la table complète, de l'arborescence globale.
En quoi innerHTML est-il gourmand en ressources ? Avez-vous un article la dessus ?
Hm non, et je pense m'être avancé un peu vite, après réflexion :)
En fait, la propriété innerHTML fait appel à un parser qui doit traiter une chaîne pour en désérialiser des nodes, puis les insérer dans le document, alors que les méthodes DOM peuvent manipuler directement les éléments, sans besoin d'interprétation lexicale, et de façon "chirugicale".
Dans le cas qui nous occupe, le problème d'innerHTML est alors que tout le tableau doit être retracé, alors que certaines lignes sont peut-être déjà triées (le repositionnement n'est alors pas impératif) - j'en imaginais donc un potentiel hit de performance.
Toutefois, et mon argument pèche un peu ici je l'avoue, il serait erroné de déduire de façon générale la supériorité de méthodes DOM sur innerHTML ou le contraire; tout dépend de l'utilisation qui en est faite et de la plate-forme cible (sous réserve que les méthodes DOM et/ou innerHTML soient supportés).
Dans notre cas, tout dépendrait du nombre de lignes à déplacer, et il ne m'apparait plus nécessairement comme un mauvais choix d'utiliser la mécanique interne de innerHTML pour retracer la totalité de la table efficacement, plutôt que de déplacer les nodes qui doivent l'être (car ils peuvent être nombreux, ce qui implique un overhead "javascript" potentiellement lourd, résultat d'appels multiples de méthodes DOM au lieu d'un appel unique à innerHTML).
FWIW. HTH.
David JOURAND wrote:
En quoi innerHTML est-il gourmand en ressources ? Avez-vous un article la
dessus ?
Hm non, et je pense m'être avancé un peu vite, après réflexion :)
En fait, la propriété innerHTML fait appel à un parser qui doit traiter
une chaîne pour en désérialiser des nodes, puis les insérer dans le
document, alors que les méthodes DOM peuvent manipuler directement les
éléments, sans besoin d'interprétation lexicale, et de façon "chirugicale".
Dans le cas qui nous occupe, le problème d'innerHTML est alors que tout
le tableau doit être retracé, alors que certaines lignes sont peut-être
déjà triées (le repositionnement n'est alors pas impératif) - j'en
imaginais donc un potentiel hit de performance.
Toutefois, et mon argument pèche un peu ici je l'avoue, il serait erroné
de déduire de façon générale la supériorité de méthodes DOM sur
innerHTML ou le contraire; tout dépend de l'utilisation qui en est faite
et de la plate-forme cible (sous réserve que les méthodes DOM et/ou
innerHTML soient supportés).
Dans notre cas, tout dépendrait du nombre de lignes à déplacer, et il ne
m'apparait plus nécessairement comme un mauvais choix d'utiliser la
mécanique interne de innerHTML pour retracer la totalité de la table
efficacement, plutôt que de déplacer les nodes qui doivent l'être (car
ils peuvent être nombreux, ce qui implique un overhead "javascript"
potentiellement lourd, résultat d'appels multiples de méthodes DOM au
lieu d'un appel unique à innerHTML).
En quoi innerHTML est-il gourmand en ressources ? Avez-vous un article la dessus ?
Hm non, et je pense m'être avancé un peu vite, après réflexion :)
En fait, la propriété innerHTML fait appel à un parser qui doit traiter une chaîne pour en désérialiser des nodes, puis les insérer dans le document, alors que les méthodes DOM peuvent manipuler directement les éléments, sans besoin d'interprétation lexicale, et de façon "chirugicale".
Dans le cas qui nous occupe, le problème d'innerHTML est alors que tout le tableau doit être retracé, alors que certaines lignes sont peut-être déjà triées (le repositionnement n'est alors pas impératif) - j'en imaginais donc un potentiel hit de performance.
Toutefois, et mon argument pèche un peu ici je l'avoue, il serait erroné de déduire de façon générale la supériorité de méthodes DOM sur innerHTML ou le contraire; tout dépend de l'utilisation qui en est faite et de la plate-forme cible (sous réserve que les méthodes DOM et/ou innerHTML soient supportés).
Dans notre cas, tout dépendrait du nombre de lignes à déplacer, et il ne m'apparait plus nécessairement comme un mauvais choix d'utiliser la mécanique interne de innerHTML pour retracer la totalité de la table efficacement, plutôt que de déplacer les nodes qui doivent l'être (car ils peuvent être nombreux, ce qui implique un overhead "javascript" potentiellement lourd, résultat d'appels multiples de méthodes DOM au lieu d'un appel unique à innerHTML).
L'instruction node.innerHTML = ... plante sous IE (mais pas sous FF) !
Quelqu'un saurait-il d'où vient le problème ?
En attendant de trouver une solution je réécris entièrement le tableau (id="refreshable" placé sur la balise <table>), ce qui provoque un clignotement lors du rafraichissement.
Bonjour,
en consultant msdn à l'adresse http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/innerhtml.asp?frame=true il apparait que innerHTML est une propriété accessible par IE, mais pour construire une table, MS demande d'utiliser les methodes propres aux tables "dynamiques" (insertrow, createthead ....) G ps: je suppose que la fonction $ fait getElementById !!
L'instruction node.innerHTML = ... plante sous IE (mais pas sous FF) !
Quelqu'un saurait-il d'où vient le problème ?
En attendant de trouver une solution je réécris entièrement le tableau
(id="refreshable" placé sur la balise <table>), ce qui provoque un
clignotement lors du rafraichissement.
Bonjour,
en consultant msdn à l'adresse
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/innerhtml.asp?frame=true
il apparait que
innerHTML est une propriété accessible par IE, mais pour construire une
table, MS demande d'utiliser les methodes propres aux tables
"dynamiques" (insertrow, createthead ....)
G
ps: je suppose que la fonction $ fait getElementById !!
L'instruction node.innerHTML = ... plante sous IE (mais pas sous FF) !
Quelqu'un saurait-il d'où vient le problème ?
En attendant de trouver une solution je réécris entièrement le tableau (id="refreshable" placé sur la balise <table>), ce qui provoque un clignotement lors du rafraichissement.
Bonjour,
en consultant msdn à l'adresse http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/innerhtml.asp?frame=true il apparait que innerHTML est une propriété accessible par IE, mais pour construire une table, MS demande d'utiliser les methodes propres aux tables "dynamiques" (insertrow, createthead ....) G ps: je suppose que la fonction $ fait getElementById !!
Toutefois, et mon argument pèche un peu ici je l'avoue, il serait erroné de déduire de façon générale la supériorité de méthodes DOM sur innerHTML ou le contraire; tout dépend de l'utilisation qui en est faite et de la plate-forme cible (sous réserve que les méthodes DOM et/ou innerHTML soient supportés).
J'ai quand même l'impression qu'utiliser les méthodes DOM empêche le "clignotement" observé avec innerHTML...
Dans notre cas, tout dépendrait du nombre de lignes à déplacer, et il ne m'apparait plus nécessairement comme un mauvais choix d'utiliser la mécanique interne de innerHTML pour retracer la totalité de la table efficacement, plutôt que de déplacer les nodes qui doivent l'être (car ils peuvent être nombreux, ce qui implique un overhead "javascript" potentiellement lourd, résultat d'appels multiples de méthodes DOM au lieu d'un appel unique à innerHTML).
Comment évaluer l'efficacité de chacune des méthode ?
-- David Jourand
Toutefois, et mon argument pèche un peu ici je l'avoue, il serait erroné
de déduire de façon générale la supériorité de méthodes DOM sur
innerHTML ou le contraire; tout dépend de l'utilisation qui en est faite
et de la plate-forme cible (sous réserve que les méthodes DOM et/ou
innerHTML soient supportés).
J'ai quand même l'impression qu'utiliser les méthodes DOM empêche le
"clignotement" observé avec innerHTML...
Dans notre cas, tout dépendrait du nombre de lignes à déplacer, et il
ne m'apparait plus nécessairement comme un mauvais choix d'utiliser la
mécanique interne de innerHTML pour retracer la totalité de la table
efficacement, plutôt que de déplacer les nodes qui doivent l'être
(car ils peuvent être nombreux, ce qui implique un overhead
"javascript" potentiellement lourd, résultat d'appels multiples de
méthodes DOM au lieu d'un appel unique à innerHTML).
Comment évaluer l'efficacité de chacune des méthode ?
Toutefois, et mon argument pèche un peu ici je l'avoue, il serait erroné de déduire de façon générale la supériorité de méthodes DOM sur innerHTML ou le contraire; tout dépend de l'utilisation qui en est faite et de la plate-forme cible (sous réserve que les méthodes DOM et/ou innerHTML soient supportés).
J'ai quand même l'impression qu'utiliser les méthodes DOM empêche le "clignotement" observé avec innerHTML...
Dans notre cas, tout dépendrait du nombre de lignes à déplacer, et il ne m'apparait plus nécessairement comme un mauvais choix d'utiliser la mécanique interne de innerHTML pour retracer la totalité de la table efficacement, plutôt que de déplacer les nodes qui doivent l'être (car ils peuvent être nombreux, ce qui implique un overhead "javascript" potentiellement lourd, résultat d'appels multiples de méthodes DOM au lieu d'un appel unique à innerHTML).
Comment évaluer l'efficacité de chacune des méthode ?
-- David Jourand
David JOURAND
innerHTML est une propriété accessible par IE, mais pour construire une table, MS demande d'utiliser les methodes propres aux tables "dynamiques" (insertrow, createthead ....)
Exact...
ps: je suppose que la fonction $ fait getElementById !!
Tout à fait c'est une fonction définie par la librairie Prototype (http://prototype.conio.net/)
-- David Jourand
innerHTML est une propriété accessible par IE, mais pour construire une
table, MS demande d'utiliser les methodes propres aux tables
"dynamiques" (insertrow, createthead ....)
Exact...
ps: je suppose que la fonction $ fait getElementById !!
Tout à fait c'est une fonction définie par la librairie Prototype
(http://prototype.conio.net/)
innerHTML est une propriété accessible par IE, mais pour construire une table, MS demande d'utiliser les methodes propres aux tables "dynamiques" (insertrow, createthead ....)
Exact...
ps: je suppose que la fonction $ fait getElementById !!
Tout à fait c'est une fonction définie par la librairie Prototype (http://prototype.conio.net/)
-- David Jourand
Elegie
David JOURAND wrote:
Comment évaluer l'efficacité de chacune des méthode ?
Une foi votre choix théorique effectué, la seule façon d'en évaluer l'efficacité est d'effectuer quelques benchs sur un cas de tests simple, sur différents navigateurs.
Typiquement, le cas de tests suivant permet de donner quelques éléments de réponse, en fonction de 3 facteurs: [1] le nombre de lignes total à retracer, [2] le nombre de colones de la table (innerHTML retraçant par nature toutes les cellules), [3] le nombre de lignes effectivement déplacées (optimisation possible avec les méthodes DOM).
Le cas de test ci-dessous, avec les paramètres indiqués, donne les résultats suivants.
En conclusion, je recommanderais d'utiliser les méthodes DOM plutôt que innerHTML, simplement car seulement l'approche technique me paraît plus propre.
--- <script type="text/javascript"> var FACTEUR_NBR_LIGNES = 1000; var FACTEUR_NBR_COL = 10; var FACTEUR_NBR_REORG = 500;
Comment évaluer l'efficacité de chacune des méthode ?
Une foi votre choix théorique effectué, la seule façon d'en évaluer
l'efficacité est d'effectuer quelques benchs sur un cas de tests simple,
sur différents navigateurs.
Typiquement, le cas de tests suivant permet de donner quelques éléments
de réponse, en fonction de 3 facteurs:
[1] le nombre de lignes total à retracer,
[2] le nombre de colones de la table (innerHTML retraçant par nature
toutes les cellules),
[3] le nombre de lignes effectivement déplacées (optimisation possible
avec les méthodes DOM).
Le cas de test ci-dessous, avec les paramètres indiqués, donne les
résultats suivants.
En conclusion, je recommanderais d'utiliser les méthodes DOM plutôt que
innerHTML, simplement car seulement l'approche technique me paraît plus
propre.
---
<script type="text/javascript">
var FACTEUR_NBR_LIGNES = 1000;
var FACTEUR_NBR_COL = 10;
var FACTEUR_NBR_REORG = 500;
Comment évaluer l'efficacité de chacune des méthode ?
Une foi votre choix théorique effectué, la seule façon d'en évaluer l'efficacité est d'effectuer quelques benchs sur un cas de tests simple, sur différents navigateurs.
Typiquement, le cas de tests suivant permet de donner quelques éléments de réponse, en fonction de 3 facteurs: [1] le nombre de lignes total à retracer, [2] le nombre de colones de la table (innerHTML retraçant par nature toutes les cellules), [3] le nombre de lignes effectivement déplacées (optimisation possible avec les méthodes DOM).
Le cas de test ci-dessous, avec les paramètres indiqués, donne les résultats suivants.
En conclusion, je recommanderais d'utiliser les méthodes DOM plutôt que innerHTML, simplement car seulement l'approche technique me paraît plus propre.
--- <script type="text/javascript"> var FACTEUR_NBR_LIGNES = 1000; var FACTEUR_NBR_COL = 10; var FACTEUR_NBR_REORG = 500;
En conclusion, je recommanderais d'utiliser les méthodes DOM plutôt que innerHTML, simplement car seulement l'approche technique me paraît plus propre.
Je crois que 80 % des utilisateurs sont sous IE... par conséquent, aucune hésitation : innerHTML !
-- David Jourand
Comment évaluer l'efficacité de chacune des méthode ?
Le cas de test ci-dessous, avec les paramètres indiqués, donne les
résultats suivants.
En conclusion, je recommanderais d'utiliser les méthodes DOM plutôt que
innerHTML, simplement car seulement l'approche technique me paraît plus
propre.
Je crois que 80 % des utilisateurs sont sous IE... par conséquent, aucune
hésitation : innerHTML !
En conclusion, je recommanderais d'utiliser les méthodes DOM plutôt que innerHTML, simplement car seulement l'approche technique me paraît plus propre.
Je crois que 80 % des utilisateurs sont sous IE... par conséquent, aucune hésitation : innerHTML !
