Principes généraux

Un navigateur Web mémorise l'historique des pages Web visitées pour chaque onglet ouvert. Cette gestion de l'historique permet de stocker les URL des pages visitées sous la forme d'une pile : l'utilisateur peut se déplacer dans la pile grâce aux boutons Précédent et Suivant.

Le bouton Précédent permet de reculer d'une page dans la pile à partir de la position de la page courante. Cette fonctionnalité n'est pas active si la page courante est la première page visitée.

Le bouton Suivant permet d'avancer d'une page dans la pile à partir de la page courante. Cette fonctionnalité n'est pas active si la page courante est la dernière page visitée.

Par la suite, une action peut être définie comme étant :

• soit l'appel d'un programme Adélia Web par l'utilisateur lorsqu'il saisit l'URL associée dans la barre d'adresse du navigateur,

• soit le déclenchement d'un événement Adélia par l'utilisateur (clic sur un objet bouton par exemple),

• soit le déclenchement d'un événement Adélia par le programme (événement Ajax cyclique ou pseudo-événement).

En Adélia Web, chaque action provoque l'ajout d'une nouvelle entrée dans l'historique du navigateur (la page résultat du traitement de l'action). Cette entrée est toujours ajoutée au sommet de la pile. On peut voir l'historique du navigateur comme un historique des actions Adélia traitées : chaque URL appelée définit une action de manière unique.

Les boutons Précédent et Suivant doivent être vus comme des boutons Annuler et Refaire permettant de se déplacer dans l'historique des actions traitées. Un clic sur le bouton Précédent annule l'action qui a produit la page courante. Le navigateur affiche alors la page précédente qui devient la page courante.

De même, un clic sur le bouton Suivant ré-exécute l'action qui a produit la page suivant la page courante. Le navigateur affiche alors la page suivante qui devient la page courante.

Exemple : Soit un programme PGM_A qui affiche un compteur initialisé à 1 et pouvant être incrémenté lors d'un clic sur un objet bouton BTN_1 (de libellé "Incrémenter").

L'historique étant géré comme une pile linéaire, il est possible que certaines actions historisées deviennent inatteignables lorsqu'une action est déclenchée sur une page revisitée.

Exemple : Soit un programme PGM_A qui affiche un compteur initialisé à 1 et pouvant être incrémenté lors d'un clic sur un objet bouton BTN_1 (de libellé "Incrémenter").

L'action A2 est supprimée de l'historique est devient inatteignable.

↑ Haut de page

Activation du support des boutons Précédent / Suivant du navigateur

Le support de cette fonctionnalité est défini au niveau des attributs de l'environnement.

Il peut être particularisé pour chaque programme lors de la définition du programme.

Par défaut, cette fonctionnalité est désactivée pour tous les environnements existants. Lorsqu'un programme est généré sans cette fonctionnalité alors il n'est pas possible de se déplacer dans l'historique du navigateur et l'utilisation du bouton Précédent est sans effet : la page courante (c'est-à-dire la page en cours de traitement) reste inchangée (le bouton Suivant reste inactif car la page courante est toujours la dernière page visitée).

Navigateurs supportés

Cette fonctionnalité est supportée par les navigateurs suivants :

• • Firefox version 3.6 et supérieure,
  • Chrome version 17 et supérieure,
  • Internet Explorer version 8 et supérieure.

Avec Internet Explorer 8 et supérieur, il est nécessaire que toutes les pages des programmes soient interprétées avec un niveau de rendu égal à "IE=8" ou supérieur ("IE=9" ou "IE=edge").

Pour la mise en place de cette configuration, consultez la section Définir les attributs de la page de l'aide en ligne pour le bouton "Fixer les attributs de la page…" dans la barre de menu "Adélia Web Studio" de Dreamweaver.

Avec Internet Explorer 7 (et avec Internet Explorer 8 ou 9 lorsque les pages sont interprétées avec un niveau de rendu IE 7), cette fonctionnalité est désactivée : il n'est pas possible de se déplacer dans l'historique du navigateur et l'utilisation du bouton Précédent est sans effet (tous les événements Adélia sont vus comme des événements irréversibles).

Les mécanismes à mettre en place pour utiliser le support des boutons Précédent / Suivant du navigateur seront décrits ci-après.

Evénement Adélia réversible/irréversible/muet

Comme une action peut être associée à un événement Adélia, il est possible de définir des règles de déplacement dans l'historique des actions traitées en fonction de la nature de l'événement.

Ces règles sont à spécifier lors de la définition d'un événement Adélia d'un objet graphique d'une page dans le maquetteur Dreamweaver.

Evénement réversible

Un événement réversible peut être un événement Ajax ou classique (non Ajax).

Ce type d'événement est associé à une action dont le traitement peut être annulé : un clic sur le bouton Précédent permet d'annuler cette action et de revenir sur la page qui a précédé cette action.

Le bouton Suivant devient actif pour permettre à l'utilisateur de refaire l'action annulée.

Ce mode est le mode par défaut de tous les événements Adélia d'un programme lorsque le support des boutons Précédent / Suivant est activé.

Exemple : Soit un programme PGM_A qui affiche un compteur initialisé à 1 et pouvant être incrémenté lors du traitement d'un événement ONCLICK réversible sur un objet bouton BTN_1 (de libellé "Incrémenter").

Evénement irréversible

Un événement irréversible peut être un événement Ajax ou classique (non Ajax).

Ce type d'événement est associé à une action dont le traitement ne peut pas être annulé : un clic sur le bouton Précédent est sans effet et la page courante reste la page en cours de traitement.

Le bouton Suivant reste inactif car la page courante est toujours la dernière page visitée.

Les actions historisées avant exécution d'une action associée à un événement irréversible deviennent inatteignables.

Ce mode est le mode par défaut de tous les événements Adélia d'un programme lorsque le support des boutons Précédent / Suivant est désactivé.

Exemple : Soit un programme PGM_A qui affiche un compteur initialisé à 1 et pouvant être incrémenté lors du traitement d'un événement ONCLICK irréversible sur un objet bouton BTN_1 (de libellé "Incrémenter").

L'action A1 est supprimée de l'historique est devient inatteignable suite à l'ajout de A2.

Evénement muet

Un événement muet est obligatoirement un événement Ajax.

Ce type d'événement est associé à une action qui ne s'inscrit pas dans l'historique des actions traitées : la page résultat du traitement associé n'est pas atteignable par l'utilisation des boutons Précédent et Suivant.

Ce type d'événement peut être utile dans le cas d'un événement Adélia en mode Ajax et de type cyclique.

Attention : Le bloc L4G associé à un événement muet ne doit pas contenir les ordres TRAITER, TRAITER_PGM et TRAITER_URL : un événement muet doit toujours être utilisé pour rester sur la même page.

Exemple : Soit un programme PGM_A qui affiche un compteur initialisé à 1 et pouvant être incrémenté lors du traitement d'un événement ONCLICK muet sur un objet bouton BTN_1 (de libellé "Incrémenter").

La page courante devient la page précédant la page résultat du dernier événement non muet (donc la page Google).

Exemple : Soit un programme PGM_A qui affiche un compteur initialisé à 1 pouvant être incrémenté lors du traitement d'un événement ONCLICK muet sur un objet bouton BTN_1 (de libellé "Incrémenter") et pouvant être remis à 0 lors du traitement d'un événement ONCLICK irréversible sur un objet bouton BTN_2 (de libellé "RAZ").

La page courante devient la page résultat de A2 et non pas la page Google puisqu'elle est le résultat d'un événement irréversible.

↑ Haut de page

Sauvegarde d'un programme

L'historisation des actions implique la gestion d'une historisation des traitements associés qui s'appuie sur un mécanisme de sauvegarde de l'état du programme Adélia Web.

Cette sauvegarde permet de mémoriser le résultat de chaque traitement lié à une action : après chaque événement Adélia déclenché, l'état du programme résultant de l'exécution du code L4G des paragraphes "Gestion Evénement", "Init Pgm", "Retour" correspondant est sauvegardé.

Il existe ainsi une sauvegarde associée pour chaque action historisée.

Etat d'un programme

Le mécanisme de sauvegarde permet de sauvegarder l'état de chaque programme en cours d'exécution. L'état d'un programme Adélia Web est constitué par :

• • l'ensemble des variables Adélia de portée Programme (déclarées dans le paragraphe "DECL PGM"),

  • l'ensemble des données Adélia de chaque page Web définie dans le programme, c'est-à-dire :

    • l'ensemble des variables Adélia de portée Page (déclarées dans chaque paragraphe "INITIALISATION"),
    • l'ensemble des données constituant l'état de chaque objet graphique Adélia défini dans une page.

La restauration d'une sauvegarde est déclenchée lors de la demande d'annulation d'une action :

• • un clic sur le bouton Précédent restaure la sauvegarde liée à l'état du programme avant exécution de l'action ayant conduit à la page courante.

Exemple : Soit un programme PGM_A qui affiche un compteur initialisé à 1 dans un champ en sortie CHO_1. Ce compteur peut être incrémenté lors du traitement d'un événement ONCLICK réversible sur un objet bouton BTN_1 (de libellé "Incrémenter") et peut être remis à 0 lors du traitement d'un événement ONCLICK réversible sur un objet case à cocher CKB_1 (initialement décochée et de libellé "Reset").

(*1) Restauration de la sauvegarde associée à l'action A2 suite à la demande d'annulation de A3.

(*2)Ré-exécution du traitement associé à l'action A3 précédemment annulée.

Remarques :

• • •  l'état d'un programme avant exécution d'une action associée à un événement irréversible n'est jamais restauré car cette action n'est pas annulable,
    •  l'état d'un programme après exécution d'une action associée à un événement muet n'est jamais sauvegardé puisque cette action ne s'inscrit pas dans l'historique des actions traitées.

Pour des raisons de performance et de montée en charge, chaque sauvegarde de l'état d'un programme est stockée sur le système de fichiers du serveur d'application Web. Un ensemble de paramètres permettent de configurer le mécanisme de sauvegarde (voir paragraphe Paramétrage de l'historique ).

La gestion de la sauvegarde, pour un programme donné, peut se faire suivant deux modes :

Sauvegarde manuelle et paragraphe SAUVEGARDE

La sauvegarde manuelle permet d'optimiser le processus de sauvegarde en sélectionnant les données pertinentes constituant l'état du programme.

L'optimisation peut, par exemple, constituer à :

• • ne pas sauvegarder des variables temporaires ne servant qu'à une étape d'un calcul,
  • ne sauvegarder que les données de la page Web courante si le programme manipule plusieurs pages.

L'activation de ce mode se fait en créant un paragraphe SAUVEGARDE via le menu contextuel du bloc PAGE.

Il est obligatoire d'activer ce mode pour toutes les pages Web contenues dans un programme (tous les blocs PAGE doivent avoir un sous-bloc SAUVEGARDE).

Le code L4G de ce bloc est exécuté après le traitement de chaque événement Adélia réversible ou irréversible lié à la page.

Si le développeur veut affiner la sauvegarde en fonction de chaque événement traité, il peut utiliser les mots réservés *OBJ_ORIGINE et *EVT_ORIGINE. Ces mots réservés permettent respectivement de connaître le nom de l'objet ayant déclenché l'événement ainsi que le nom de l'événement qui vient d'être exécuté.

De plus, pour sauvegarder une donnée utilisée par le programme, le développeur doit utiliser l'ordre SAUVER_ETAT_PGM.

Pour désactiver le mode de sauvegarde manuelle et activer la sauvegarde automatique il faut supprimer tous les paragraphes SAUVEGARDE du programme.

↑ Haut de page

Annulation et reconstruction d'une action

La restauration de l'état d'un programme lors de la demande d'annulation d'une action via le bouton Précédent est faite de manière automatique par le système (indépendamment du mode de sauvegarde automatique ou manuel).

Cependant, lorsque le traitement de certaines actions met à jour des données hors de la portée du programme (comme les données stockées en base de données par exemple), il est possible d'annuler ces traitements pour que ces données restent dans un état cohérent.

Paragraphe ANNULATION

Le paragraphe ANNULATION est facultatif et sa création se fait via le menu contextuel du bloc PAGE.

Lors d'un clic sur le bouton Précédent du navigateur, le code L4G de ce bloc est exécuté après la restauration de la sauvegarde de l'état du programme déclenchée avant l'exécution de l'action ayant conduit à la page courante : au moment de l'exécution du paragraphe ANNULATION, le programme se trouve dans l'état qu'il avait avant l'exécution de l'action à annuler.

Pour distinguer l'action à annuler, le développeur doit utiliser les mots réservés *OBJ_ORIGINE et *EVT_ORIGINE. Ces mots réservés permettent respectivement de connaître le nom de l'objet ayant déclenché l'événement ainsi que le nom de l'événement à annuler.

Pour récupérer les valeurs des objets graphiques saisies par l'utilisateur avant le traitement de l'action à annuler, le développeur doit utiliser l'ordre RECUP_VAL_FORM.

Pour rappel, il n'est pas nécessaire dans ce bloc de traiter l'annulation de traitement lié à un événement irréversible ou muet.

Exemple : Soit un programme PGM_A qui contient deux objets champs de saisie CHS_NOM et CHS_PRENOM initialisés respectivement avec les valeurs "saisir nom" et "saisir prénom" et un bouton BTN_ADD (de libellé Ajouter) qui permet sur l'événement ONCLICK réversible d'ajouter le nom et le prénom saisis dans une table BD.

(*1) Restauration de la sauvegarde associée à l'action A1 suite à la demande d'annulation de A2.

Le clic sur le bouton Précédent provoque :

• • la restauration de la sauvegarde associée à l'action A1,
  • le déclenchement du bloc ANNULATION.

Pour annuler l'ajout en BD, le développeur doit connaître les valeurs de nom et prénom que l'utilisateur a saisi avant de déclencher l'événement sur le bouton BTN_ADD. Pour cela, le bloc ANNULATION doit contenir le traitement suivant :

* Test si l'événement à annuler est bien l'événement associé à BTN_ADD

si *OBJ_ORIGINE = 'BTN_ADD'

   * Il faut récupérer les valeurs de CHS_NOM et CHS_PRENOM au moment du déclenchement de l'événement

   * On ne peut pas utiliser directement les propriétés valeur de CHS_NOM et CHS_PRENOM car elles valent respectivement "saisir nom" et "saisir prénom"

   * Il faut utiliser pour cela l'ordre RECUP_VAL_FORM

   RECUP_VAL_FORM CHS_NOM WNOM

   RECUP_VAL_FORM CHS_PRENOM WPRENOM

   * WNOM et WPRENOM ont pour valeur "dupond" et "michel"

   * On annule l'ajout en BD

   SUPPRIMER_SQL USERS *COND(COL_NAME= :NOM et COL_FIRSTNAME= :PRENOM)  

fin

Reconstruction d'une action

Lors d'un clic sur le bouton Suivant du navigateur, l'événement précédemment annulé est refait : le bloc L4G associé à cet événement est ré-exécuté.

Les données fournies en entrée de ce traitement (c'est-à-dire les valeurs des objets graphiques du formulaire associé) sont identiques à celles fournies lors de la précédente exécution de cet événement.

Le mot réservé *ACTION_SUIVANT permet de distinguer si un traitement est exécuté de façon normale par l'utilisateur ou si cette exécution est déclenchée lors d'un clic sur le bouton Suivant du navigateur.

(*1) Restauration de la sauvegarde associée à l'action A1 suite à la demande d'annulation de A2

  (*2) Ré-exécution du traitement associé à l'action A2 suite à la demande de reconstruction de A2. Les données fournies en entrée sont celles fournies lors de la précédente exécution de A2.

↑ Haut de page

Gestion de l'historique des actions traitées

A chaque session Web (ou pseudo-session Web) utilisateur est associé un gestionnaire d'historique.

Par défaut, la taille de l'historique (c'est à dire la taille de la pile) des actions traitées est infinie.

Il est cependant possible de lui fixer une taille finie par paramétrage (voir paragraphe Paramétrage de l'historique) : dans ce cas le gestionnaire gère un intervalle d'actions historisées. Lorsque l'historique a atteint sa taille maximale alors chaque nouvelle entrée insérée entraîne la suppression de la première entrée de l'intervalle : celle-ci devient inatteignable en utilisant le bouton Précédent.

Exemple : Soit un programme PGM_A qui affiche un compteur initialisé à 1 et pouvant être incrémenté lors d'un clic sur un objet bouton BTN_1 (de libellé "Incrémenter"). On suppose que l'historique a une taille maximale de trois entrées et est initialement vide.

(*1) La taille maximale de l'historique étant atteinte lors de l'ajout de A3, l'ajout de A4 provoque la suppression de A1 de l'historique et devient inatteignable.

(*2) L'utilisateur reste sur la page résultat de A2 car A1 est inatteignable.

Purge de l'historique

Le système gère automatiquement la purge de l'historique et des fichiers de sauvegarde associés dans les cas suivants :

• • un événement Adélia irréversible est déclenché : dans ce cas, toutes les actions historisées précédemment sont supprimées de l'historique (car inatteignable) et les sauvegardes associées sont supprimées du système de fichiers,
  • un événement Adélia est déclenché à partir d'une page revisitée : dans ce cas, toutes les actions historisées suivant celle ayant mené la page courante sont supprimées de l'historique (car inatteignable) et les sauvegardes associées sont supprimées du système de fichiers,
  • lorsque l'historique a une taille finie et a atteint sa taille maximale, si l'utilisateur se trouve sur la dernière page de l'historique et si un événement Adélia est déclenché, alors la première entrée dans l'historique est supprimée (car inatteignable) et sa sauvegarde associée est supprimée du système de fichier,
  • la session HTTP devient invalide : l'historique est vidé, toutes les actions historisées sont supprimées de l'historique et les sauvegardes associées sont supprimées du système de fichiers.

Paramétrage de l'historique

Il est possible de configurer l'historisation des actions traitées à l'aide de paramètres dans le fichier CfgConfiguration.properties.

Ces paramètres sont :

↑ Haut de page