Interactivités (Web Services)

Un article de ScriptdigitalWiki.

Jump to: navigation, search

Inscription des moteurs d'interactivités - Protocole Voter - Protocole Enquêter - Protocole Justifier


Sommaire

Introduction

Les interactivités Voter, Enquêter et Justifier se servent d'un client Flash pour envoyer des données à un serveur, qui les compile, et retourne au client Flash ces données compilées. Ces données peuvent être des votes ou des opinions qui sont insérées dans des mini-forum.

Selon l'activité, le client Flash communique avec le serveur via la méthode HTTP GET ou POST. La réponse du serveur est du type: Content-type: application/x-www-urlformencoded.

Pour communiquer avec le serveur, le client Flash utilise des arguments définis dans l'URL qui vont indiquer le type de demande qu'il fera au serveur, ainsi, que de valider si le client Flash est inscrit auprès du serveur. En effet, le client Flash ne peut insérer et compiler des données auprès du serveur que si l'URL du client Flash est inscrite dans l'interface Web administrative qui correspond à son type d'activité.

Les étapes pour le développeur Flash sont les suivantes:

  • Inscrire l'URL du client Flash dans l'interface Web administrative.
  • Construire les méthodes selon le type d'interactivité pour communiquer avec le serveur. Il faut suivre en cela les protocoles qui correspondent à chaque activité.
  • S'assurer que le fichier de configuration principal de ServicesWeb est bien configuré. Cela peut être pris en charge par l'administrateur.

Interface Web administrative

Quand un client Flash communique avec le serveur, il doit envoyer au serveur son URL, ce qui permet de vérifier que ce client Flash est bien inscrit auprès du serveur.

Il y a trois interfaces administratives.

  • Voter
    • /servicesweb2/sites/admin/interactivites_admin/voter_admin.php
  • Enquêter
    • /servicesweb2/sites/admin/interactivites_admin/enqueter_admin.php
  • Justifier
    • /servicesweb2/sites/admin/interactivites_admin/justifier_admin.php

Les interfaces administratives possèdent deux zones:

  • Zone d'inscription du client Flash
  • Zone listant les clients Flash inscrits

Dans la zone d'inscription, les URL des clients Flash doivent être uniques. Mais les URL des cours peuvent être similaires. D'autre part, la zone listant les clients Flash permet désinscrire un client Flash.

Protocoles

Chaque client Flash doit suivre le protocole correspondant à son activité pour communiquer avec le serveur. À quelques détails près, les protocoles pour Voter, Enquêter et Justifier sont similaires.

Pour les tests, j'ai créé avec PHP trois pages simulants les interfaces du client Flash. Les pages des tests afficheront le résultat de la requête faite au serveur.

Protocole Voter

Le client Flash envoie le choix de l'utilisateur et le serveur retourne une répartition des votes en pourcentage.

Protocole Enquêter

Le client Flash envoit l'opinion d'un utilisateur au serveur et ce dernier retourne les n dernières opinions envoyées au serveur.

Protocole Justifier

Le client Flash envoie le choix de l'utilisateur ainsi que son opinion et le serveur retourne une répartition des votes en pourcentages et les n dernières opinions appuyant chaque choix.

Configurations

On peut configurer globalement certaines options spécifiant le comportement des interactivités.

  • Le nombre d'opinions à retourner au client Flash.
  • Le format du texte contenant les n dernières opinions.

Il serait avisé de continuer le développement pour ajouter la possibilité d'avoir (a) des configurations propres aux cours, et d'en outre, (b) de permettre au serveur de retourner un format XML.

Fichier

/configurations/global.inc


Exemple

// INTERACTIVITES (enqueter, justifier) //

// Maximum messages a afficher pour les interactivites
$maxMessages = 10;

// blocReponse pour Flash 5 qui n'accepte que les balises suivantes:
//  a, b font color, font face, font size, i, p , u
// Attention de respecter exactement ###DATE### et ###REPONSE### pour la substitution
$blocReponse = "<p><b>###DATE###</b></p><p>###REPONSE###</p>\n";

Schémas de la banque de données

À l'origine, les schémas de la banque de données devaient refléter les éléments XML du protocole RSS 2.0. C'est pour cela que les noms des colonnes, à une exception près (la colonne "forum"), seront familiers à ceux qui ont déjà regardé un fil RSS 2.0.

La table interactivites_domaines est l'endroit où est enregistré le client Flash. (Le 'channel' dans RSS 2.0)

La table interactivites_elements contient les données (Les 'items' en RSS 2.0) associées à un domaine ('channel').

Quand le client Flash fait une requête, la première chose que font les interactivités est de vérifier que l'URL qui est envoyée par le client Flash est bien enregistrée dans la table interactivites_domaines.

Si l'inscription du client Flash est valide, le serveur retourne les données liées à l'interactivité qui sont dans la table interactivites_elements.


interactivites_domaines

Field Type Allow Null Default Value
channel_key int(10) No <null>
title varchar(100) No
link text No
description varchar(255) No
category_name varchar(100) No
category_domain text No

interactivites_elements

Field Type Allow Null Default Value
channel_key int(10) No 0
description text No
guid int(10) No <null>
forum text No
pubDate datetime NULL

Améliorations

REST et XML

Elles peuvent être de deux ordres, majeures ou mineures.

Une amélioration majeure serait de produire un seul protocole pour les interactivités qui utiliseraient les méthodes du protocole REST. Cela impliquerait que le client Flash pourrait envoyer en POST des données au format XML au serveur, tandis que ce dernier retournerait aussi les données compilées au format XML avec cette en-tête: Content-type: text/xml.

Une amélioration mineure serait de permettre au serveur de retourner le texte des opinions au format XML. La réponse du serveur continuerait d'être au format www-urlform-encoded, mais uniquement le contenu de la variable reponses serait encodé en XML.

Content-type: application/x-www-form-urlencoded

status =   ok&
vote_1=10&
vote_2=40&
vote_3=50&
reponses =  <?xml version="1.0" encoding="ISO-8859-1"?>
<textes>
<date>14/01/2006 10:22:27 AM<date/> <texte>ceci est un réponse</texte>
<date>14/01/2006 10:20:07 AM<date/><texte>une autre réponse</texte>
<date>14/01/2006 07:34:23 AM<date/><texte>encore une réponse</texte>
etc.

Configuration locale à chaque cours

Qu'il s'agisse de faire une amélioration majeure ou mineure, celles-ci exigent, aux fins de compatibilité, qu'on puisse avoir des fichiers de configurations pour les interactivités propres à chaque cours. Cette formule à été implantée avec succès dans d'autres cadres d'applications et permet à un fichier spécifique à un cours de redéfinir les options globales du fichier de configuration central de ServicesWeb.

Fil RSS

Il serait aisé de créer un fil RSS pour chaque interactivité. Le fil RSS d'une interactivité comme Justifier permettrait au chargé de projet d'avoir une mise à jour régulière de l'ensemble des opinions formulées par les utilisateurs. Le fil RSS pourrait ainsi comprendre la répartition en pourcentage des votes ainsi que les dernières opinions appuyant toutes les options disponibles dans cette interactivité.