Bonjour,
 
Je souhaite développer une application javascript coté client qui communique très régulièrement avec le serveur pour mettre à jour les informations affichées.
Je pense avoir besoin d'une routine qui demande des news du serveur toutes les n secondes.
 
Je suis familier avec JQuery, et je ne connais pas Dojo.
 
Sur Wikipedia, je lis :

... ce qui correspond à merveille à mes besoins.
 
Dojo semble d'après cette description disposer de fonctionnalités "toute faites" pour mon système de "feed", ce qui m'évite de tout recoder.
JQuery quant à lui, ne semble pas, d'après la connaissance que j'en ai, disposer de telles fonctionnalités.
 
Ma démarche générale est d'éviter au maximum de réinventer la roue, et de systématiquement rechercher l'existance d'un outil permettant de répondre à mes besoins les plus standards.
Je souhaite construire un client propre, modulaire et facilement codable.
 
Si ce n'est JQuery ou Dojo, connaissez-vous d'autres outils, bibliothèques ou framework qui pourraient m'intéresser ?
 
Que pensez-vous de Google Web Toolkit ?
 
Merci pour votre patience  

Ca se fait tres bien en JQuery et ca possede l'avantage d'etre du standard.  
Tu effectue ton appel AJAX avec JQuery dans une fonction que tu mets dans un set_timeout et basta, je ne vois pas l'interet d'apprendre un nouveau framework si c'est juste pour ca.

Je pensais par exemple à un système de cache des données envoyées, un envoi du "diff" des données locales seulement. Bref, des trucs standards pour faire joli.
Si je peux éviter de le recoder, ca m'arrangerait.
Après, peut-etre que Dojo ne propose pas ce genre de fonctionnalités. Le cas échéant, jQuery fera effectivement l'affaire.

Voici un exemple avec jQuery : http://jsfiddle.net/agHpu/1/

Oui c'est ce que j'ai fait finalement
 
Merci

et pourquoi ne pas regarder du côté des websockets  ?
plutot que de faire du polling ( ton client qui va vaoir toutes les secodnen même s'il n'y a rien ), c'est le serveur qui distribue les news quand elles arrivent.
Ensuite, tu récupères du json et tu le traite avec dojo/jquery/whatever  pour construire ta page ( ou mode gros porc, tu envoies directement le html et tu le pose avec un innerhtml )

Je ne connaissais pas ce nouveau protocole, ca a l'air très intéressant.
 
Mais connais-tu les compatibilités avec les navigateurs ? L'appli est destinée au grand public. Cette page (http://captain-expresso.fr/j2ee/html-5-les-websockets/) indique que IE est compatible seulement à partir de la version 9. C'est problématique.
 
Si j'ai bien compris, cela implique que le serveur tourne de façon permanente ; exit les communications http asynchrone.
Après tout, pourquoi pas.
 
Si tu es familier avec les websockets, as-tu une implémentation que tu me conseillerais, entre jWebSocket, GNU WebSocket, APE, phpWebSocket, .. ?
 
Merci

Comme je dev en php, tu as ta réponse
 Et si, c'est de l asynchrone :ton code client continue a vivre sa vie entre deux messages.
Ça peut être un mode push accessible aux utilisateurs d'un navigateur récents. Les autres font du polling.
L'imple n'est pas si différente si tu l'intègre du début.

Les websockets dans ce cas c'est un peu trop je pense. Dans certains cas d'usage avec "peu" de clients et un besoin de rafraîchissement très rapide pourquoi pas. Mais là, je pense que de l'ajax avec pourquoi pas du cache coté serveur, est plus indiqué.

 
D'après ce que j'ai compris, il n'est que plus rapide, puisqu'il ne fait pas de requete inutile et il n'utilise pas de headers interminables.
Pourquoi le websocket serait moins adapté que le polling dans certains cas ?

 
Parce qu'il faut garder une connexion ouverte par client, ainsi que tout l'état associé côté serveur. À moins de rafraichir très souvent, ça risque bien d'être plus couteux en ressources que des requêtes Ajax stateless.

Le point important c'est ça : "ainsi que tout l'état associé côté serveur".
Cela complique beaucoup la logique serveur (cf les discussions entre serveurs stateless et statefull).

L'utilisation pour le client sera une connexion a une page contenant une appli javascript qui communiquera intensément (temps reel) avec le serveur, puis l'arret net de toute communication a la fin de l'utilisation.
Un socket me semble fort adapte, non ?

 
versus
 

 
Toutes les "n" secondes, ça ne me paraît pas intense avec n > 15. Ou alors les news sont tellement fréquentes qu'il est indispensable de les afficher dans la seconde? Un peu étrange.
 
   
 
Le terme "temps réel" n'a pas sa place ici : on peut faire du temps réel avec une granularité d'une minute et inversément, avoir une granularité de 1ms sans temps réel.
 
WebSocket peut être un choix adapté à condition de prendre en compte :
 
* Le support plus limité des navigateurs
* Les proxies foireux, et dieu sait s'ils sont légion en entreprise
* Le maintien de l'état côté serveur, avec heartbeat et nettoyage si le client s'est barré
 
Tu peux aussi prévoir un fallback pour les cas où WebSocket ne passerait pas mais c'est double travail (implémenter WebSocket + implémenter une solution en jQuery). En plus de la détection des conditions d'échecs pour activer le fallback (certains proxies sont fourbes dès qu'ils voient des headers inhabituels).
 
Donc une question de choix temps+coût de développement / compatibilité / vitesse
 
   

C'est bien vu. En réalité, j'ignorais l'existence des websockets avant ce topic, c'est pourquoi je me tournais initialement vers une solution de polling.
J'ignorais egalement le mot "polling" pour designer le concept dont j'avais besoin ; "toute les n secondes" etait plus une maniere de decrire le concept.
 
J'ai besoin d'un rafraichissement d'1 a 2 fois par seconde.
 
Le websocket est-il alors inadapte ? trop gourmant en ressource ? en bande passante ?
 
Les deux solutions ont leurs avantages, et je suis tres indecis. Si vous pouviez trancher pour moi ca serait gentil
 
La difference d'implementation des deux solutions n'a pas d'importance, sachant que je m'adapterai en fonction.