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())

Note: il est fortement déconseillé d'accéder aux variables d'instances ou de classe directement ; le fonctionnement interne de cette API peut changer avec le temps, ainsi que la définition et l'usage de ces variables.

Note 2: il est possible d'enrichir ces classes en y ajoutant des variables et/ou des méthodes ; attention néammoins au choix des noms et des préfixe pour minimiser les risques de collision. Le module "call.js", par exemple, enrichit la classe cComHub de quelques méthodes supplémentaires.

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);
});