Introduction aux cadres d'application (Portail, Contrôle Accès, ServicesWeb)

Un article de ScriptdigitalWiki.

Jump to: navigation, search

Sommaire

Le parcours de l'utilisateur, du portail au cours

On peut découper en plusieurs étapes le parcours que fait l'utilisateur du portail à un cours.

  1. Identification auprès du portail.
  2. Choix du cours dans le portail.
  3. Identification et renseignements supplémentaires sur le statut de l'élève et de son formateur si l'utilisateur accède au cours pour la première fois.
  4. Redirection vers le cours.
  5. Page d'entrée du cours différente selon le statut de l'utilisateur et s'il accède au cours pour la première fois.

Du point de vue de la programmation, ces étapes sont prises en charge par trois cadres d'applications:

  • Portail (1-2)
  • Contrôle Accès (3-4)
  • ServicesWeb (5)

Portail, Contrôle Accès et ServicesWeb

Le cadre d'application Portail permets à l'utilisateur de s'authentifier, de choisir des cours et de gérer ceux-ci à partir de son dossier personnel. Quand dans son dossier personnel, l'utilisateur clique sur le nom d'un cours pour y accéder, Portail envoie une requête à Contrôle Accès qui comporte des informations sur l'utilisateur tels que son nom, son statut (apprenant, formateur en encadrement, formateur en exploration), et le sigle du cours choisi.

Lorsque le cadre d'application Contrôle Accès réponds à une requête de Portail concernant l'accès d'un apprenant à un cours, il vérifie en premier lieu si l'apprenant accède pour la première fois à ce cours. Si c'est le cas, l'apprenant est d'abord dirigé vers l'interface Tunnel où il aura à compléter des renseignements comme entre autres son statut comme élève et le formateur qu'il a choisi pour l'encadrer. Ensuite, l'apprenant pourra accéder au cours. Controle Accès déterminera aussi si le formateur est en encadrement ou en exploration. S'il est en encadrement, l'information sera passée à ServicesWeb qui affichera le cours avec les interfaces du formateur. Si le formateur est en exploration, ce dernier est considéré comme un apprenant par ServicesWeb, le formateur ne voit donc pas, par exemple, les interfaces de correction. La seule différence entre le formateur en exploration et l'apprenant étant que le formateur peut accéder à toutes les pages (pas de contrôle d'avancement comme avec l'apprenant).

Le cadre d'application ServicesWeb prend ensuite le relais de Contrôle Accès et produit l'environnement dynamique utilisé par le cours. En particulier, ServicesWeb génère les divers éléments dynamiques selon l'activité en cours (contrôle d'avancement, feuille de route, activités notées, forum, quiz, etc.) et le statut de l'utilisateur (apprenant, formateur en encadrement, formateur en exploration).

Les interactions entre les cadres d'application

L'interaction entre Portail, Contrôle Accès et ServicesWeb n'est pas seulement linéaire comme pourrait le laisser entendre la section précédente. Au cinq étapes du parcours mentionné plus haut, il faut aussi ajouter les interactions qui continuent de se produire lorsque l'utilisateur évolue dans un cours qui est géré par les trois cadres d'application mentionnés plus haut. La liste des interactions plus bas décrit ce qui se passe à chaque fois qu'un utilisateur passe d'une page à l'autre à l'intérieur d'un cours.

  • Interaction entre Portail, Contrôle Accès et ServicesWeb quand un utilisateur charge une page d'un cours
  1. La configuration globale de ServicesWeb est agrégée à la configuration locale du cours et est chargée, ce qui permet d'indiquer où ce trouvent les fichiers des cadres d'application Contrôle Accès et ServicesWeb.
  2. La configuration globale de Contrôle Accès est chargée.
  3. Le cadre d'application Contrôle Accès est instancié et vérifie auprès du cadre d'application Portail que la session de l'utilisateur est valide.
  4. Portail envoie une réponse positive ou négative à Contrôle Accès.
  5. Selon la réponse de Portail, Contrôle Accès permet à l'utilisateur de voir la page (session valide) ou le redirige vers la page d'entrée du portail (session invalide) pour que se dernier se reconnecte au portail.
  6. Si la session est valide, les macros de Contrôle Accès sont évaluées et remplacées par du code HTML (et parfois Javascript).
  7. Le cadre d'application ServicesWeb est instancié si on parvient jusqu'ici (c.-a.-d. que la session est valide et que Contrôle Accès n'a rencontré aucune erreur fatale dans l'évaluation de ses macros).
  8. ServicesWeb évalue ses macros et les remplace par du code HTML (et Javascript à l'occasion).

Du point de vue de la programmation, on peut dire qu' une page de cours supporte trois cadres d'applications qui sont étagés sur deux niveaux, le niveaux supérieur permettant de conduire au niveau inférieur. Au premier niveau, on retrouve Portail et Contrôle Accès, ce sont ces deux cadres d'applications qui déterminent si on peut passer au niveau inférieur qui est ServicesWeb.

Portail <- vérification session valide ->  Contrôle Accès
                                           --------------
                                           ServicesWeb
                                           --------------
                                           pagecours.php

Les interactions entre Portail et Contrôle Accès

Les interactions entre les cadres d'application Portail et Contrôle Accès se produisent dans les cas suivants.

  1. Dans le contexte du portail, lors du choix du cours dans le dossier personnel de l'utilisateur.
  2. Dans le contexte d'un cours, lorsque l'utilisateur clique le lien vers le dossier personnel dans le portail.
  3. Dans le contexte d'un cours, lorsqu'une page d'un cours est chargée, Contrôle Accès fait une requête auprès de Portail pour valider la session.

Les interactions 1 et 2 utilisent le protocole HTTP et le fureteur de l'utilisateur pour compléter leurs opérations. Dans le cas 1, dans le contexte de l'environnement du portail, Portail produit une URL qu'il passera au fureteur de l'utilisateur, et qui pointe vers la page centrale, le "récepteur", de Contrôle Accès qui gère les demandes de Portail. Dans le cas 2, dans le contexte de l'environnement des cours, Contrôle Accès produit une URL qui pointe vers le dossier personnel de l'utilisateur sur le portail. Dans chaque environnement, l'URL produite comporte des arguments accompagnés de valeurs et qui correspondent à ce qui est requis par chaque cadre d'application destinataire. PHP décode ces arguments en utilisant le protocole CGI (Common Gateway Interface)

L'interaction 3 utilise aussi le protocole HTTP comme canal de communication. Mais au lieu d'utiliser un fureteur pour échanger des informations, et valider ou invalider la session, Contrôle Accès ouvre une interface de connexion (socket) sur le port 80 vers le portail et échange directement les informations via PHP au lieu de décoder les arguments présents dans les URL comme dans les cas 1 et 2. En plus, les informations ne sont pas échangées en s'appuyant sur le protocole CGI mais plutôt en utilisant le protocole XML pour encoder les arguments.

Les interactions entre Contrôle Accès et ServicesWeb

Les interactions entre Contrôle Accès et ServicesWeb se produisent dans les cas suivant:

  1. Lorsque Contrôle Accès après avoir reçu une requête de Portail redirige l'utilisateur vers la page d'entrée du cours.
  2. Lorsque qu'une session est invalide et que Contrôle Accès redirige l'utilisateur vers la page d'entrée du portail.
  3. Lorsque dans le cadre des cours des macros globales de Contrôle Accès sont évaluées.

On peut dire des interactions entre Contrôle Accès et ServicesWeb que les interactions sont à sens unique, dans le sens où ServicesWeb ne peut modifier le comportement de Contrôle Accès tandis que le contraire est vrai. Les cas 1 et 2 utilisent le protocole HTTP. Dans le premier cas, Contrôle Accès informe ServicesWeb sur l'utilisateur voulant accéder au cours en encodant les informations en suivant le protocole CGI, tandis que dans le second cas, Contrôle Accès ne permet même pas à ServicesWeb de s'instancier, car il oblige le fureteur à une redirection en utilisant la balise <meta http-equiv='refresh'>.

Le cas 3 par contre utilise des éléments de partages d'information qui sont liés à l'environnement PHP, comme des variables de session, des variables globales, etc. Le parfait exemple étant les macros qui sont utilisées comme éléments dynamiques dans les pages. Celles-ci peuvent afficher simplement le nom d'un utilisateur, la date de dernière visite au cours. Comme Contrôle Accès est chargé avant ServicesWeb, les macros globales de Contrôle Accès seront accessibles dans le contexte des cours.

Apprenant, formateur en encadrement, formateur en exploration

Les trois différents statuts de l'utilisateur colorent en quelque sorte chaque cadre d'application comme nous avons déjà pu voir. Ainsi, dans Portail, Contrôle Accès et ServicesWeb, le statut de l'utilisateur déterminera la nature des interfaces.

Dans Portail, seul le statut d'apprenant et de formateur a de l'importance. Quand l'apprenant ne verra dans son dossier personnel qu'une simple liste de cours auxquels il est inscrit, le formateur lui se verra offrir deux options, qui spécifieront son statut de formateur (en encadrement ou en exploration) auprès de Contrôle Accès. Dans le dossier personnel, le premier type de lien pointant vers un cours est celui qui définit le formateur comme étant en exploration auprès de Contrôle Accès. Cette information sera passée à ServicesWeb qui désamorcera le contrôle d'avancement tout en offrant les mêmes interfaces qu'à l'apprenant. Le second type de lien pointant vers un cours comporte en vis-à-vis l'adresse courriel de l'apprenant que le formateur veut encadrer. En ce cas, Contrôle Accès passera cette information à ServicesWeb qui affichera les interfaces spécifiques au formateur (éléments de corrections, de commentaires, de transmission au forum, etc.) ainsi que les réponses de l'apprenant.

MVC: Model, View, Controler

Les cadres d'applications mentionnés plus haut sont fortement influencés par un modèle de développement intitulé MVC (Model, View, Controler).

En voici une excellente définition provenant de Wikipedia.

Model-View-Controller (MVC) is a software architecture that separates an
application's data model, user interface, and control logic into three
distinct components so that modifications to the view component can be
made with minimal impact to the data model component. This is useful
since models typically enjoy a fair degree of stability (owing to the
stability of the domain being modeled), whereas user interface code
usually undergoes frequent and sometimes dramatic change (owing to
usability problems, the need to support growing classes of users, or
simply the need to keep the application looking "fresh"). Separating the
view from the model makes the model more robust, because the developer
is less likely to "break" the model while reworking the view.
http://en.wikipedia.org/wiki/MVC

Dans le contexte des applications développées pour la SOFAD, le modèle MVC correspond à ceci dans notre vocabulaire.

View est la page Web que l'intégrateur peut modifier pour donner un "style" à la page. La page web contient en général des macros qui peuvent être déplacées dans cette page à la convenance de l'intégrateur. Les pages Web sont dans le répertoire sites et se terminent en général par .php tandis que les gabarits se terminent par .inc. Les fichiers qui se trouvent dans sites sont en général publics, et accessibles par les intégrateurs. Il faut noter par contre que le répertoire /sites/admin devrait ne permettre des accès sur le Web qu'aux administrateurs.

Model correspond aux classes du cadre d'application. Ce sont les classes qui possèdent des méthodes pour communiquer avec la banque de données, ou toutes autres méthodes qui pourraient être réutilisées par les cadres d'applications. Les fichiers des classes commencent toujours par une majuscule et leur suffixe est .inc. Ces fichiers sont dans le répertoire lib. Seuls les programmeurs peuvent accéder à ce répertoire.

Controller correspond aux contrôleurs. Un contrôleur peut gérer plusieurs pages (par exemple init_cours.inc qui est inclus dans toutes les pages sous ServicesWeb) ou une seule page. Le contrôleur ne contient pas de classes, et en général pas de fonctions. Il s'appuie sur des classes pour gérer les pages. Les fichiers des contrôleurs se terminent par _contr.inc (et parfois _proc.inc et sont dans le répertoire lib. Seuls les programmeurs peuvent accéder à ce répertoire.

Les fichiers de configurations sont dans le répertoire configurations. Ils se terminent par .inc. Par rapport au modèle MVC, on pourrait les ranger dans "Model" ou "Controller". Seuls les administrateurs peuvent accéder à ce répertoire. On notera qu'il y a toujours un fichier de configuration à la racine du répertoire configurations et que celui-ci s'appelle global.inc. On notera aussi qu'il y a des fichiers de configurations qui vont spécifier des options propres à un cours (/configurations/SIGLECOURS/global.inc) ou à un cadre d'application (/configuration/controleacces/conf_edusofad.inc).

MVC et répertoires
RépertoiresDescriptionsAccès personnelAccès serveur
/sitesPages Web et gabaritsIntégrateurAccès libre
/sites/adminPages Web: Interfaces administratives des cadres d'applicationIntégrateurAccès contrôlé
/libLibrairies (contrôleurs et classes)ProgrammeurAccès interdit
/configurationsFichiers de configurationsAdministrateurAccès interdit

Les tableaux des environnements des cadres d'application

Nous avons vu dans plus haut qu'il y a une séquence de 8 étapes quand un utilisateur charge une page de cours géré par Portail, Contrôle Accès et ServicesWeb. Nous allons maintenant nous attarder maintenant sur des aspects plus techniques liés à l'environnement PHP.

PHP a plusieurs fonctions qui permettent d'inclure d'autres fichiers dans un fichier principal. Le contenu de ce qui est inclus peut être du texte par exemple quelques lignes de HTML, ou bien, du code PHP, comme le sont les fichiers de configurations qui sont des immenses tableaux dont les valeurs peuvent être modifiées par l'administrateur. Les fichiers de configurations prennent avantage de cela, chaque cadre d'application dépend d'un fichier de configuration global qui lui permettra de retrouver. entre autres, les fichiers à inclure. Par exemple, tous les chemins vers les fichiers dont dépend ServicesWeb sont dans son fichier de configuration global qui une fois inclu par PHP produira le tableau $ENV_SERVICESWEB.

Ayant produit le tableau $ENV_SERVICESWEB, le code peut inclure le contrôleur commun à toutes les pages du cours (init_cours.inc). La première action de ce contrôleur est ensuite d'inclure le fichier de configuration de Contrôle Accès, et ensuite de charger son contrôleur qui permet entre autres de valider la session de l'utilisateur et de générer les macros globales de Contrôle Accès.

include_once ('../../configurations/global.inc');
include_once ($ENV_SERVICESWEB['init_cours_inc']);

Voici un tableau qui montre ce qui précède.

Variables d'environnement
TableauxCadres d'application globalsCadres d'applications locauxChemin vers le fichier de configuration
$ENV_SERVICESWEBVariables d'environnement de ServicesWeb Cours, Quizs, Interactivités, etc /servicesweb/configurations/global.inc
$ENV_CONTROLEACCESVariables d'environnement de Contrôle AccèsContrôle Accès: validation de la session, Tunnel; confirmation formateur appareillage apprenant-formateur/edusofad/configurations/controleacces/conf_edusofad.com
$ENV_SOFADVariables d'environnement d'EduSOFADPseudo-Portail, Contrôle Accès: récepteur, Tunnel; information supplémentaire apprenant et appareillage avec formateur/edusofad/configurations/global.inc

Portabilité

Nous avons vu dans la section précédente que le modèle MVC avait fortement influencé le modèle de développement des cadres d'application ainsi que la hiérarchie des répertoires qui contiennent pages Web, librairies et configurations. Pour des raisons de portabilité, tous les chemins menant aux fichiers (à une exception) sont des chemins relatifs. Comme tous les fichiers, concernant tant les pages web, les contrôleurs, les classes et les configurations sont regroupés dans le même répertoire principal, il est facile, après avoir édité les fichiers de configurations, d'installer le répertoire principal sur des serveurs différents et dans un répertoire principal qui peut porter un autre nom que le nom original avec lequel il a été développé.

Par exemple dans le fichier à /configurations/global.inc, il suffit de nommer le répertoire de base qui est à I:\\developpement\servicesweb\ pour que tous les chemins vers les fichiers et les URL fonctionnent. Le code PHP dans les cadres d'application ne faisant jamais de références absolues, on peut copier le cadre d'application dans un autre répertoire en autant que l'option $_nomRepBase est correctement configurée.

// Nom du repertoire de base
$_nomRepBase = 'servicesweb';



//Windows ==> OK
I:\\developpement\servicesweb\
                                                   sites\
                                                   lib\
                                                   configurations\
//Unix ==> OK
dev/servicesweb/
                                                   sites/
                                                   lib/
                                                   configurations/