Discussion :

[psychadelic]

Pour ma part je maintiens que c'est une mauvaise utilisation d'Ajax, je ne vois pas de demande client au serveur ce qui est quand même la base de l'utilisation d'Ajax où c'est le client qui demande la mise à jour.

Je me suis aussi posé la question, et je me suis juste cantonné à la problématique d'une "boucle infinie" qui ne boufferai pas trop la mémoire du navigateur.
mais effectivement quand j'ai vu qu'il s'agissait d'une lecture répétée d'un même fichier XML...

Il existe bien d'autres techniques pour ce genre de chose, le « long polling », les « WebSockets » ou encore, et cela tombe bien attendu que tu utilises Chrome, les « server-sent events ».

C'est sans doute la la meilleur solution.

[Watilin]

Bonjour,

vu l’environnement et la puissance de calcul relativement limitée, il serait intéressant de songer à optimiser le script. En l’état, ta fonction de callback est maladroite :

• boucles .each() imbriquées,
• nombreux appels $(this) sans passer par une variable intermédiaire,
• utilisation de .html() là où .text() suffirait,
• etc.

Déjà, tu as l’avantage de développer une application qui tournera toujours sur le même navigateur, tu peux donc tirer parti des spécificités de ce navigateur. Cela rend l’utilisation de jQuery moins importante, car l’un des rôles de jQuery est de lisser les incompatibilités entre navigateurs.

De plus, jQuery, comme n’importe quel framework, présente une petite mais inévitable surcharge de calcul par rapport à du code vanilla (c’est-à-dire sans framework). Et sans savoir exactement (*) ce que fait $.ajax, on ne peut pas avoir la garantie que les « fuites de mémoire » ne viennent pas de là.

(*) On pourrait examiner le code source, mais là j’avoue que j’ai la flemme.

Voici mes conseils :

• débarrasse-toi de jQuery et réécris ta callback en vanilla ;
• adopte la solution async/await proposée par psychadelic ; utilise XMLHttpRequest pour les requêtes ou fetch qui est plus récent et plus simple ;
• adopte les server-sent events comme le suggère NoSmoking.

[psychadelic]

utilise XMLHttpRequest pour les requêtes ou fetch qui est plus récent et plus simple 

J'ai cherché à mettre un fetch dans mon exemple, mais il me semble que cette nouvelle fonction ne fait pas le support pour les retours en xml.
Si qq1 à un exemple, ça m’intéresserai de savoir, je suis tous chiffoné de ne pas avoir réussi à y caser un fetch

[Watilin]

Ah oui en effet. C’est amusant de constater que XMLHttpRequest a une méthode pour traiter le XML mais pas le JSON, et que pour fetch c’est l’inverse. On peut y voir une inversion de tendance dans l’évolution de JavaScript…

Je crois que le mieux est de demander le format texte et de faire la conversion en XML avec d’autres techniques. Il y a DOMParser mais je ne sais pas si c’est la solution idéale. J’avoue que je n’ai pas l’habitude de manipuler du XML côté client…

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
function goFetch() {
  fetch("sample.xml")
    .then((resp) => resp.text())
    .then((text) => {
      var parser = new DOMParser();
      var xml = parser.parseFromString(text, "application/xml");
      console.log(xml);
    });
}

… En version async/await :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
async function goFetch() {
  var resp = await fetch("sample.xml");
  var text = await resp.text();
  var parser = new DOMParser();
  var xml = parser.parseFromString(text, "application/xml");
  console.log(xml);
}

Alternativement on peut utiliser .parseFromString(text, "text/html") qui nous donnera un objet héritant de HTMLDocument, exactement comme l’objet document dont on a l’habitude.

Dans les deux cas (XMLDocument ou HTMLDocument), on dispose des méthodes querySelector et querySelectorAll ; et je pense que jQuery est capable de traiter les deux — je n’ai pas vérifié cela dit.

[manoss]

Voici mes conseils :

• débarrasse-toi de jQuery et réécris ta callback en vanilla ;
• adopte la solution async/await proposée par psychadelic ; utilise XMLHttpRequest pour les requêtes ou fetch qui est plus récent et plus simple ;
• adopte les server-sent events comme le suggère NoSmoking.

Bonjour,

Je vais mettre en application ces recommandations. J'ai actuellement une solution fonctionnelle mais qui ne plait pas dans son fonctionnement.
Je vais réécrire cela.

Je reviendrais vers vous après cela.

[manoss]

Je suis en train de regarder les server-Sent Events :
https://www.html5rocks.com/en/tutori...from_locale=fr

J'ai un soucis semble t-il dans le le if suivant car je passe systématiquement dans le else

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
if (req.headers.accept && req.headers.accept == 'text/event-stream')

Bon après n'utilisant que chromium le test me semble superflu.

Au niveau de l'architecture que me conseillez-vous ?

Je pars d'un XML mal formaté (inchangeable car doit être compatible avec le matériel en place).
Je pensais le convertir en JSON pour envoyer le résultat via un server-sent events au navigateur (sur lequel j'aurais des traitements a faire de pagination + animation)

Dois-je tout faire en JS avec une solution nodeJS ? Passer par nginx et du php voire python ?

D'avance merci

[NoSmoking]

Pour le test je pense qu'un simple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
if ("EventSource" in window) {
  // initialisation et action
} 
else {
  // message d'erreur
}
}

devrait effectivement suffire.

Pour ma part je ferais le boulot côté serveur mais ne livrerais côté client qu'un objet format JSON pour mise en forme.
Tu peux également livrer du HTML mais je dirais que c'est à toi de voir ce qui t'es le plus facile à manipuler/travailler suivant le domaine dans lequel tu te sens le plus à l'aise.

[manoss]

J'ai mis en place une solution nodeJS et SSE basique afin de tester le comportement de la mémoire dans le temps.

En effet, je vais faire le maximum côté serveur.
La solution actuellement en test passe par un JSON mais je vais essayer de faire au plus simple.

Pour l'usage de nodeJS en brut, sans express par exemple vous me conseillé quoi comme site ou livre ?

[psychadelic]

Pour l'usage de nodeJS en brut, sans express par exemple vous me conseillé quoi comme site ou livre ?

je cherche aussi

sinon il y a le tutoriel sur grafikart, mais à la fin il bloque sur la maniere d'en une appli , alors que c'est tout bête il suffit de les gZipper ensemble et de changer la valeur de l'extension .gzip en .NODES, si ma mémoire est bonne

[NoSmoking]

Je me pose quand même la question de pourquoi utiliser Node dans ton application attendu que tu n'as pas besoin des avantages que peuvent te procurer sa conception asynchrone, sa gestion des i/o ou ses performances plus élevées.

Si c'est pour la satisfaction intellectuelle alors soit, sinon pour une requête toutes les 8 secondes ...