Organisation de l'API COMHUB/js
Modules
Fichier | Requis | Fonction |
---|---|---|
comhub.js | oui | Noyau central de l'API. Ce module gère les intgeractions avec le serveur COMHUB et fournit via le global TbComHub un objet interface dont les méthodes permettent d'accéder à la plupart des fonctions COMHUB. |
event.js | oui | Ce module permet de simplifier l'échange d'évenements à travers les différents composants de l'application du coté navigateur. Elle permet notablement l'échange d'évenements entre les multiples documents (fenetres) d'une même application. |
call.js | non | Ce module offre une vision haut niveau des appels en cours en corrélants les divers évenements COMHUB. Chaque appel est matérialisé par une instance de la classe cCall ; l'état de chaque instance suit le déroulement des appels sur le serveur (avec un léger délai du au système AJAX client/serveur). La gestion des appels s'en trouve grandement facilitée pour les applications désirant fournir ce genre d'interface (suivi des appels, controles des appels, etc) |
jquery/* | non | Divers utilitaires (voir section "debugging") |
Classes, instances, variables, méthodes
- Les classes sont nommées avec un préfixe "c" (ex: "cCall")
- Les instances globales sont préfixées avec "Tb" (ex: TbComHub)
- Les variables d'instances sont préfixées avec "m_" (ex: TbComHub.m_userid)
- Les variables de classe sont préfixées avec "cm_" (ex: cClass.cm_count)
- Les méthodes d'instances ou de classe ne sont pas préfixées ; les méthodes de classe s'utilisent directement avec le nom de la classe (ex: var nb=cCall.count())
Traitements synchrones & asynchrones
Un grand nombre de méthodes font appel à des ressources ou des fonctions disponibles sur le serveur COMHUB, et nécéssitent par conséquent un échange AJAX. Ces opérations sont généralements très courtes, mais en cumulant les temps de transit sur le réseau et le temps d'éxécution sur le serveur, on peut facilement arriver a plusieurs dizaines ou mêmes centaines de millisecondes, voire plusieurs secondes pour les traitements les plus lourds.
Il est généralement conseillé de ne pas utiliser de requetes HTTP synchrones, mais plutot de positionner des fonctions "callback" qui seront exécutées une fois les données de retour récupérées. L'expérience utilisateur s'en trouve améliorée par une sensation de bonne réponse de l'interface. A contrario, les requêtes synchrones "bloquent" complètement l'interface du navigateur, jusqu'à la fin du traitement, ce qui peut être assez déroutant pour les utilisateurs.
Il peut néammoins arriver qu'on ait besoin, pour simplifier un développement, ou encore pour être certains d'un enchainement, d'avoir à effectuer des requetes synchrones. L'API "comhub/js" propose les deux modes, automatiquement sélectionnés en fonction des paramètres passés. La présence d'une callback entraine le mode asynchrone.
Synchrones
var callid=TbComHub.callDial("0179858585"); alertf("Appel en cours / ID=%s",callid)
Asynchrones
TbComHub.callDial("0179858585", function(callid) { alertf("Appel en cours / ID=%s",callid); });