Quand le DOM se met à jour ?

Prenons un exemple simple:

Un <div> d'attente (avec un message please wait...) est invisible.

J'ai une fonction qui va le montrer (changement de className), puis qui fait un traitment lourd sur un autre <div>.
Ce traitement terminé je cache le <div> d'attente et enfin j'affiche mon <div> avec son contenu.

C'est simple et ça parait logique.

SAUF QUE

Le changement de visibilté des <div> ne se fait qu'à la sortie de ma function.

Et donc tout l'intérêt de mon <div> d'attente disparait.

Est ce que d'autres connaissent aussi ce problème de rafraichissement de structure DOM ?

Si je temporise mon code avec des alert() alors la on voit clairement les updates du DOM et les <div> qui apparaissent et disparaissent.

Est ce que quelqu'un a une explication pour se phénomène.
Il est commun a IE et Firefox apparement.

Normal lors des traitement lourd le navigateur ne rafraichi la page que lorsque tout est fini.

un conseil balance tes fonctions via des setTimeout imbriqués


setTimeout(
function(){
mafonction1():
mafonction2():
setTimeout(
function() {
mafunc3();
mafunc4();
}, 10)
}, 10);

Sinon j'ai entendu parler de dispatchEvent/fireEvent, mais jamais testé

Il est vraiment lourd ton traitement ?
Il vaut peut-être mieux ne pas mettre de messages, ça surcharge encore plus

Salut,

C'est un comportement normal et utile des navigateurs, qui permet d'éviter de mettre à jour l'affichage à chaque petite modification de l'arbre DOM.

Pour le mettre à jour, il faut redonner la main au navigateur, par exemple comme tu as pu l'observer avec un alert. Le setTimeout permet aussi d'arriver au même résultat, mais il faut bien avoir conscience que ça ne reste qu'un hack, car l'utilisateur peut théoriquement interagir avec l'interface pendant le court temps où il a la main, ce qui peut avoir des effets non désirés.

En fait, la vraie question à te poser, c'est : "Est-ce qu'il est justifié de monopoliser la thread du navigateur pendant si longtemps ?".

Julien Royer a écrit :
Salut,

C'est un comportement normal et utile des navigateurs, qui permet d'éviter de mettre à jour l'affichage à chaque petite modification de l'arbre DOM.

Pour le mettre à jour, il faut redonner la main au navigateur, par exemple comme tu as pu l'observer avec un alert. Le setTimeout permet aussi d'arriver au même résultat, mais il faut bien avoir conscience que ça ne reste qu'un hack, car l'utilisateur peut théoriquement interagir avec l'interface pendant le court temps où il a la main, ce qui peut avoir des effets non désirés.

En fait, la vraie question à te poser, c'est : "Est-ce qu'il est justifié de monopoliser la thread du navigateur pendant si longtemps ?".

Quand on te file un XML de 460 ko je crois que ouais

Mon outil a pour but de présenter sous forme de tableau les enregistrements d'une requête.
Il y a un bon système de navigation page par page qui permet d'éviter un temps de traitement trop long.

Mais les gens du business sont ce qu'ils sont et donc il y a une option pour afficher toutes les données.

Les datas au format JSON font dans les 6 Mo ( J'ai une dizaine de fois 10 000 entrées )

Firefox, il lui faut environ 10 secondes pour me générer un tableau de 10 000 entrées.
Ce pauvre misérable IE va qu'en a lui bouffer 240 % du CPU disponible et mettre plus d'une minute pour le faire.

Ca c'est le cas extrème.

A un niveau moins grave il y a toujours un sérieux décalage entre le moment ou l'utilisateur click sur 'show all' et le moment ou les data apparaissent.

Je me suis rendu compte que ce n'est pas le traitement des données qui prend du temps mais bien le browser qui mets des plombes pour afficher le résultat final.

Mon idée était donc d'informer l'utilisateur via un 'Wait <div>' que son action va prendre du temps et qu'il doit être patient.

Je construis le tableau (dumoins la partie TBODY) avec le DOM à grand coup de createElement. Peut être que c'est cela qui est trop lent.
Peut être dois je me resoudre à utiliser un gigantesque .innerHTML.

Qu'en pensez vous ? CreateElement ? Ou innerHTML ?
Modifié par Grumelo (04 Jun 2007 - 09:50)

Bonjour,

Question stupide :es-tu obligé d'intégerer ces données côté client ? Si tu en as la possibilité, fais-le côté serveur.

Sinon, place ton avertissement directement dans le lien/le bouton qui permet l'fficahge de toutes les entrées.

Ce n'est pas une question stupide.

Je travaille dans un environnement ou aucune resources n'est disponible server side (pas de php, mysql, .net, ni quoi que ce soit).

Deplus les données et les reports qui vont avec doivent être dispos et fonctionnels OFFLINE.

Ma spécialité c'est le tout client side. Ca rend enormément de services et c'est très rapide. Sauf quand le browser n'arrive pas à suivre.

Jamais je n'aurais proposé une option du type show all, mais c'est le business qui demande et donc moi je dois trouvé une solution client-side pour informer l'utilisateurs que parfois, faut attendre.

Et donc je cherche un moyen simple de ponctuellement rendre la main au browser le temps d'afficher un message d'attente.
Au chargement d'une page c'est extrèmement simple à faire.
Mais au cours d'un traitement ça l'est beaucoup moins.