ERMI

Pour enregistrer les données des classes d’objets sont créées dont des instances sont stockées dans des tableaux. La recherche d’un objet (par exemple le nom d’une zone) revient à parcourir des tableaux (alors qu’une simple requête sous Prolog suffit, la rapidité provenant de l’organisation indexée des données). Cela conduit à réorganiser le code pour essayer d’économiser le plus possible les « requêtes ».

A noter que le passage de l’écriture prolog à PHP s’est effectuée par un remplacement très aisé, par exemple le prédicat ui(…) devient $tab_ui[$nui++] = new ui(…).

La circulation est aussi un peu simplifiée (momentanément). L’idée de rendre la réalité des couloirs est laissée en suspens.

Après d’assez longues séances de débuggage, le système fonctionne de manière relativement satisfaisante (circulation et entrée dans la salle « change » du secteur CPI). C’est comme un petit miracle dont l’accomplissement est en partie lié à la prise en charge par javascript (client) de la fin de la chaîne de transformations. Restait encore à vérifier les url générées. En effet, les fichiers xml ne sont plus “traités” automatiquement. Ils doivent être accompagnés du moteur (wwwxml.php), ce qui évite de devoir paramétrer le serveur (Note : pourquoi cette technique n’a-t-elle pas été envisagée dans la version prolog ?).

Reste également le problème des caractères accentués et autres entités de ce genre. Les entités é par exemple, sont repérées par le parseur et exclues du résultat qui est accompagné d’un warning. Que faire si l’on veut qu’elles subsistent jusqu’au navigateur ?

Les premières corrections systématiques de fichiers xml à envisager sont:

1. Ajustement des entêtes à mettre en minuscule et à compléter (modèle ui_ppmc.xml).
2. Entités caractères dans les fichiers (à étudier que faire).

Les corrections systématiques des fichiers xsl à envisager sont :

1. Ajustement des entêtes.
2. Oter la règle concernant la racine (‘/’).
3. Regrouper la structure de la page en une seule règle.
4. Fabrication préalable des variables (ou alors trouver une autre solution).
5. Remplacer les inclusions de javascript par des liens <script src=… ></script>.

Eté 2010: la faisabilité est assurée et le module wwwxml.php est réalisé (en utilisant le parser de php, quelques lignes en php contre plusieurs centaines dans la version Prolog).

Le 12 octobre, le module de « circulation » (wxgoto.php) est quasiment debuggé. Les derniers problèmes consistaient en :

1. La perte de l’orientation après passage à l’inscription. C’était un faux problème, simplement la page accueil.htm ancienne était dans le cache (gardait l’ancien nom dir à la place de ori). Mais cela a permis quelques nettoyages complémentaires.
2. La perte de l’étage et de la zone à l’entrée dans une salle. L’erreur se nichait dans un mauvais format utilisé dans la génération du script (jvs) général de la salle.

Le travail suivant a consisté à tester la navigation entre salle. Dans la 1e salle des concours, un problème de lien pour les pages liées (fenêtre link) est repéré (manque wwwxml.php). Il s’agit aussi de mettre au point qrep.xsl.

Le problème est résolu (13.10.10) ; les liens fautifs sont créés à partir du xml sous forme d’une table d’objet. Il s’agit de corriger la fonction (afficheDirectByIndex) qui les met en forme. Le problème est que xsl délivre une url sous la forme base/fichier selon la notation utilisée dans les éléments LNK. Cela ne correspond pas à l’organisation des paramètres de wwwxml.php qui a été modifié en conséquence.

Pour simplifier, les feuilles xsl sont par défaut dans $DocXML.

13.10 : Le premier concours fonctionne (cela teste qtml.xsl et qrep.xsl), y compris l’enregistrement des résultats avec concours.pl .

Questions : A quoi sert tabAct (ptTabAct) (si c’est utile, il faudra compléter la base).

14.10 : Aménagement de qrep2-2.xsl (testé avec cpi-change3.xml) qui fonctionne à peu près (à ajuster problème de l’usage de l’attribut ‘mode’). A vérifier que les CTXT fonctionnent (ça en a l’air).

18.10 : Essai des solutions trouvées sur le net concernant les entités (annexe 2) la solution b est connue pour ne pas fonctionner et pourtant c’est la seule qui marche (testé avec cpi-chg0.xml). Attendre un peu avant de transformer systématiquement tous les fichiers xml. Mais cela fonctionne à moitié avec cpi-change3.xml ( ?).

19-20.10 : Mise à jour de tout le package « concours » (et les feuilles xsl associées). Pour cela, il y a création d’outils en Perl (to8859-1 et rename). Finalement, les entités caractère sont remplacées par les caractères eux-mêmes du moment que l’on peut indiquer le charset (ou l’encoding). Debuggage de wxtelep.

20.10 (suite) : Migration de plusieurs feuilles de style et adaptation des entêtes de mathbas0, calcul2 et concours (cpi en cours). Les tests donnent l’occasion de repérer de subtils bugs. Par exemple une fonction PHP retourne une variable booléenne à l’intention de javascript : « l’erreur » return(TRUE) au lieu de return(‘true’) conduit au fonctionnement attendu, mais pas return(FALSE) au lieu de return(‘false’).

21.10 : Continuation de la migration des feuilles de style. Introduction d’un fichier init.xsl. Les compléments javascript des feuilles de style sont déplacés dans le répertoire ‘scripts’.

23.10 : Installation de ce qu’il faut sur le site ermitage pour pouvoir tester en mode « tout PHP » la navigation en général et la salle des concours. Pas mal d’embrouilles entre toutes les versions. Retrouvé des erreurs déjà corrigées ( ?). A vérifier salle.jx : certains liens concernant les activités de la salle semblent incorrectes (wwwxml.php manque) (suivre tabActAdj). Mais quand sont-ils employés ? Problème à régler : affichage des salles quand on n’a pas le level requis (ne devrait pas s’afficher dans le couloir + problème dans la zone des autres salles). Diagnostic partielle : Lorsqu’une salle est ouverte à un niveau, first_activity (wxpartie) délivre la première activité trouvée indépendamment de son niveau. Il faudrait chercher une activité du bon niveau (quitte à afficher « pas d’activités dans la salle »). Mais en principe, il faudrait ajuster le niveau des salles à celui des activités.

24.10 : Migration de l’enregistrement du suivi. L’écriture et lecture des fichiers personnels reste en Perl. La migration de nouvelles feuilles xsl montre quelques différences entre le moteur initial et le moteur basé sur les bibliothèques PHP (qui elles-mêmes ne sont pas totalement abouties selon certains avis). Il faut parfois ajouter un template qui ne fait rien (pour éviter le fonctionnement d’une règle par défaut, voir qrep-qcm3.xsl). Le traitement différencié de deux occurrences d’un même élément placer à des niveaux différents est aussi délicat.

26.10: Installation sur le site ce qu'il faut pour les concours et la zone cpi. A tester.

29.10 : Test et correction de bugs sur qcm?.xsl qrep-qcm.xsl (problème des variables xsl locales et autres coquilles), correction de touchpad.xsl et touchpad2.xsl avec l’impression de bricolage (voir remarque concernant qrep-qcm3.xsl ci-dessus et note LOP291010 dans touchpad2.xsl).

30.10 : Enregistrement, création de groupes, inscription gérés par mySQL (a nécessité une réorganisation de l’algorithme pour éviter des requêtes redondantes).

01.11 : Fin de la migration des fichiers xml (il s’agit en fait de changer l’entête). Correction de puzzle.xsl. Réaménagement de « salles » de l’ermitage.

05-11.11 : Debuggage. Les erreurs sont souvent dues à des coquilles introduites dans les feuilles de style. Seul problème, le & (par exemple dans CPI & AF) parfois utilisé, mais qui se trouve dans les scripts. Problème additionné au fait que la suppression automatique des entités a « bousillé » les fins de ligne de, par exemple, return a && b ; (devenu return a &). Introduction dans salle.jx de and2, and3, and4 et and5.

23.11 : Debuggage (élément BLOC dans qrep2-2.xsl, défi sous forme de xsl :include). Petit bricolage (fichier plat pour la correspondance sobriquet – nom) pour pouvoir utiliser les noms dans les certificats avec les anciennes procédure Perl (adaptation en conséquence de inscript.php, suivi.pl, result.pl). Attention : la fonction profil utilise encore wexp.php fichier des groupes et utilisateurs (dans restriction_zone et restriction_salle). De toute façon ces deux dernières fonctions ont été déconnectées et sont à revoir (restriction_XX (transformée en autorisation_XX).

24.11 : Debuggage de feuilles de style et utilisation plus systématique de xsl:include (attribut, bloc, links, varlist, val-var). A modifier les « template » SPAN, NOTE et CARTOUCHE (utilisés par exemple dans dftml.xsl) selon l’exemple de BLOC (dans l’état actuel de la spécification de xsl toutes les règles sont utilisées et donc la dernière écrase les autres le cas échéant, ce qui n’était pas l’algorithme proposé dans l’ancienne version).

26.11 : Refait SPAN dans qrep2-2. Fait de même dans vtml-2p, vtml-2s et dftml. De plus fait NOTE et CARTOUCHE (sous la forme de xsl :include) dans vtml-2p , vtml-2s et dftml. Pas copiés, à tester. A voir les autres feuilles utilisant ces templates.

27.11 : Copie faite et test rapide. Amélioré le look de mathbas0/ui_778.htm et ui_785.htm (ajout d’un troisième layer). A voir si cette présentation ne devrait pas être généralisée sous la forme d’une feuille de style css (cela a-t-il été fait ?). Explication à propos de la répétition des pages vtml. L’une sert pour la partie texte. L’autre pour les notes. Dans ce deuxième cas, les links (év. cachés) sont ajoutés à ceux qui existent déjà. L’important est que les autres (ceux de la partie texte) subsistent.

La section Bugs, idées, nouveautés, ... contient la suite du journal.

html

Les fichiers welcom*.htm, ermitage.htm, accueil.htm, accueil2.htm, etc. sont identiques à l’ancienne version.

php

1. wxgoto : récupération des données et lancement de la circulation
2. inc/init-goto : quelques variables globales
3. inc/traitement : plaque tournante pour la prise en charge des différentes requêtes de circulation
4. inc/wxpartie : circulation générale
5. inc/controle : gestion des restrictions
6. inc/structure : structure du musée. Dans la version prolog, les prédicats pouvaient être utilisés pour créer un véritable réseau. En php, la version actuelle propose des fonctions unidirectionnelles. A voir pour une amélioration (transformation en une bd).
7. inc/wxsalle : création des salles
8. inc/wxtelep : création du menu général (téléporteur)
9. inc/lexique : nomenclature (ontologie)
10. inc/relation : données concernant les salles :sorties, les adjacences, les interfaces
11. inc/activites : table des activités
12. inc/inscript : gestion de l’inscription
13. inc/panneau : affichage de panneaux dans les couloirs
14. inc/print_html : création de morceaux de html
15. inc/wexp : base des utilisateurs
16. wwwxml : transformation des pages xml
17. inc/init : initialisation (à regrouper avec init-goto ?)

Le document initial welcome.htm qui ouvre une fenêtre et y fait figurer welcom1.htm. On peut démarrer avec welcom1.htm qui utilise le navigateurs standard, ce qui pourrait créer des problèmes avec les options générales (Back).

En cliquant sur entrée, le document ermitage.htm est chargé. C’est un système de frame à un seul frame dans lequel toute la suite va se dérouler. Son utilité est de charger des données javascript globales à l’ensemble du musée et quelques fonctions de base.

La première page, comme toutes les suivantes lorsqu’on navigue dans le musée sont créées dynamiquement par wxgoto.php (principalement le fichier inclus wxpartie.php). Elles dépendent des paramètres :

1. dep : type de déplacement
2. partie, floor, zone, salle : l’endroit
3. level : niveau de l’utilisateur
4. sobriquet : sobriquet de l’utilisateur
5. ori : son orientation (dev. futur)
6. langue : langue (dev. futur)

La page contient des styles (à mettre dans un lien) et le javascript nécessaire à l’entretien des variables globales « client » : parent.wxPartie, parent.wxFloor, parent.wxZone, parent.wxSalle, parent.wxCurrentUi , parent.wxOri.

La page est constituée d’un tableau, avec des liens spécifiques dans chaque partie. Ces liens sont fabriqués sur la base d’une structure (structure.php). Certaines restrictions peuvent exister, par exemple une salle ne contenant pas d’activité n’est pas affichée (contrôle.php). Dans la version « tout PHP » ces restrictions qui peuvent ralentir le fonctionnement sont en nombre limité.

Tous les appels de pages se font avec la « méthode » get sauf lorsque l’on sort de la “réception” (identification).

Quelques éléments de navigation se font par l’appel à des pages statiques (cafet, plan, bureau de l’administrateur, etc.).

Lors de l’appel sur une salle celle-ci est « créée » par wxsalle.php . Cela consiste en un frameset de cinq fenêtres :

1. texte : fenêtre d’information principale présentant (théorie, exercice, etc.)
2. info : fenêtre d’information complémentaire
3. navi : navigation dans le musée (sortie, changement de salle)
4. next : autres activités de la salle
5. link : liens pour accéder aux informations complémentaires

Ce frameset contient également en tête une bibliothèque javascript (salle.jx) commune à la salle et de fonctions de mise à jour des variables javascript globales. Les fonctions de wxsalle.php chargent également un fichier dans la zone « texte » (fichiers html ou xml transformé) et les informations pour “navi” et “next”. Le fichier principal est accompagné du code javascript spécifique à l’activité. Il se charge de peupler les frames “info” et “link”.

Dans la disposition “salle”, le système est donc constitué de trois « couches » (figure 2).

Fig 2. Les couches de présentation